Internetexperts willen vier nieuwe http-statuscodes

Twee invloedrijke internetexperts, waaronder een van de auteurs van de http-specificatie, hebben een voorstel voor een aantal nieuwe http-statuscodes gepubliceerd. Een daarvan is de 'Too Many Requests'-status.

Het voorstel is ingediend bij de Network Working Group, dat van het voorstel een standaard kan maken, waarna het door makers van http-serversoftware en webbrowsers kan worden geïntegreerd. De opstellers van het voorstel zijn niet de minsten: een van hen is Roy Fielding, een van de auteurs van de http/1.1-specificatie. Hij stond tevens aan de wieg van het Apache-project. De ander is Mark Nottingham, die onder meer de specificatie voor Atom-feeds hielp bedenken.

De opstellers willen een viertal nieuwe http-statuscodes in het leven roepen. De Too Many Request-status, die code 429 mee zou moeten krijgen, laat een browser weten dat een gebruiker binnen een bepaalde tijd te veel verzoeken naar een webserver heeft gestuurd. Daarbij kan ook een tijd in seconden worden meegestuurd waarbinnen de gebruiker opnieuw verbinding mag maken met de server. Dat moet overigens wel worden gerespecteerd door de gebruikte webbrowsers: denial of service-aanvallen zal deze statuscode niet kunnen tegengaan.

De manier waarop een server controleert of iemand te veel verbindingen probeert te maken, wordt niet gedefinieerd: dat is geheel aan de server. Er zou ook geen verplichting zijn om de http-429-code te gebruiken: als een server over te weinig resources beschikt om alle http-verzoeken uit te voeren, is het beter de verbinding gewoon te verbreken, schrijven de opstellers. Als de code wordt ingevoerd, zouden webbrowsers een speciale foutmelding kunnen weergeven als te veel requests worden gedaan.

Een andere voorgestelde code is de 'Network Authentication Required'-status met nummer 511, die niet is bedoeld voor servers, maar voor proxies die aan een gebruiker willen laten weten dat ze moeten inloggen voor toegang tot het internet. De standaard zou bijvoorbeeld van pas komen bij publieke wifi-hotspots, waarbij een gebruiker vaak moet inloggen om internettoegang te krijgen. Gebruikers krijgen nu doorgaans een splashpagina te zien waarop ze moeten inloggen, maar de manier waarop een proxy aan de eindgebruiker laat weten dat er moet worden ingelogd, is nog niet gestandaardiseerd.

De nieuwe 431-statuscode zou gebruikers laten weten dat de headers die ze proberen te versturen naar de webserver te lang zijn, terwijl de 428-code tot slot aangeeft dat een precondition moet bestaan om de pagina te kunnen tonen.

Http-statuscodes worden door webservers gebruikt om informatie over de status van een webpagina en -server door te geven aan de browser. De meestgebruikte code is 200, waarmee wordt aangegeven dat een request met succes is uitgevoerd, terwijl de beroemdste waarschijnlijk de 404-'page not found'-melding is. Er zijn echter veel meer codes, waaronder zelden gebruikte zoals de 'request-uri too long'-status.

Reacties (69)

[Jaap-Jan]

Roy Fielding is ook de bedenker van REST, een software pattern om resources op een webserver te kunnen downloaden en beheren. Ook worden API's als 'RESTful' aangeduid als ze REST gebruiken voor hun web services.

Mij lijkt ook "Network Authentication Required" wel nuttig, maar op de één of andere manier kan Windows 7 ook uitvissen dat de gebruiker een wachtwoord moet invoeren. Als je bijvoorbeeld met een hotspot in de trein verbindt, verwijst WIndows je naar de browser.

[Marientjuh]

Dat doet hij door een dns request te doen naar een bekende server. Krijgt hij niets terug dan is er een verbindingsprobleem. Mocht hij een ander ip adres terugkrijgen dan word de aanvraag doorverwezen naar een mogelijk login pagina. (er zijn nog meer testen maar dit is waar je op doelt)

Het is natuurlijk veel beter als de proxy zelf kan vertellen dat er ingelogd moet worden met een verwijzing naar de login pagina. Dan zal de proxy niet hoeven rommelen met het DNS resultaat wat kan leiden tot diverse caching fouten aan de browser (client) kant.

Ik denk dat alle status codes hier vermeld goede kandidaten zijn om toegevoegd te worden omdat het praktische problemen gaat oplossen.

[Reactie gewijzigd door Marientjuh op 26 juli 2024 03:22]

[.oisyn]

Het is natuurlijk veel beter als de proxy zelf kan vertellen dat er ingelogd moet worden met een verwijzing naar de login pagina

Ja dat is beter, maar dat werkt gewoon niet, ook niet met het voorgestelde systeem. Voordat je het internet op mag moet je eerst inloggen. DNS requests voordat je hebt ingelogd zouden dus ook niet moeten werken. Maar hoe gaat de proxy dan ooit vertellen dat je moet inloggen als DNS nog niet werkt, en de browser dus geen ip-adres heeft om een HTTP request naar te doen? Er moet dus wel een al dan niet fake DNS resultaat gegeven worden.

[CyBeR]

[...]

Ja dat is beter, maar dat werkt gewoon niet, ook niet met het voorgestelde systeem. Voordat je het internet op mag moet je eerst inloggen. DNS requests voordat je hebt ingelogd zouden dus ook niet moeten werken. Maar hoe gaat de proxy dan ooit vertellen dat je moet inloggen als DNS nog niet werkt, en de browser dus geen ip-adres heeft om een HTTP request naar te doen? Er moet dus wel een al dan niet fake DNS resultaat gegeven worden.

DNS werkt om dat probleem op te lossen als enige meestal wél zonder authenticatie.

[MSalters]

Dan gebruik je toch gewoon IP-over-DNS

[elmuerte]

maar op de één of andere manier kan Windows 7 ook uitvissen dat de gebruiker een wachtwoord moet invoeren. Als je bijvoorbeeld met een hotspot in de trein verbindt, verwijst WIndows je naar de browser.

Windows (en andere OSen zoals iOS) proberen een specifieke host te resolven (meestal binnen het domein van de OS provider). Als dat niet resolved naar een van de voren gedefinieerde waarde gaan ze er vanuit dat er een login portal tussen zit. e.g. internet-probe.microsoft.com resolved naar 10.0.0.1 in plaats van 127.0.0.127; dus open de browser naar http://example.org en de login proxy redirect wel naar de correctie login pagina.

[hiekikowan]

Vooral die 429 lijkt me als ontwikkelaar handig. Dit zal een brute-force- of refresh-spam-attack tegen kunnen gaan... iets waar je tegenwoordig regelmatig last van hebt. Goed idee!

[serhat]

Ehh ja, nee, gedeeltelijk. Als je een client hebt die het honoreert wel. Je browser dus vaak. Echter als iemand echt wilt bruteforcen, forceert hij wel de verbinding via een tooltje en kan hij weer zijn gang gaan. Iemand die het echt wil misbruiken, doet het toch wel weer.

Ook qua overhead valt het mee. Het is gewoon een extraatje. Let ook op:

Er zou ook geen verplichting zijn om de http-429-code te gebruiken: als een server over te weinig resources beschikt om alle http-verzoeken uit te voeren, is het beter de verbinding gewoon te verbreken, schrijven de opstellers.

[Reactie gewijzigd door serhat op 26 juli 2024 03:22]

[robvanwijk]

Iemand die het echt wil misbruiken, doet het toch wel weer.

Maar wat je nu ziet is dat iedereen die een pagina niet geopend krijgt al snel twee of drie keer op F5 mept voordat ie concludeert dat er "echt" iets mis is. Als je meteen de eerste keer een nette melding teruggeeft (met een time-out die, naar ik aanneem, afgedwongen wordt door de browser van een eigenwijze gebruiker) dan scheelt dat een boel verbindingen.
Ook als de eerste paar KB van een pagina (met daarin alle links naar .css en .js includes, die de browser ook meteen begint te downloaden; nog meer verbindingen!) uiteindelijk wel binnendruppelt, maar de server het duidelijk niet aankan is dit fijn (er vanuit gaande dat een browser die een 429 krijgt op domein.com/bla.js zo handig is om niet eens te proberen domein.com/bla.css te requesten).

Helpt dit tegen opzettelijke DDoS'es? Nee, nauwelijks (het legitieme verkeer efficiënt blokkeren zet geen zoden aan de dijk). Maar als er ergens iets fout gaat (meerdere servers die tegelijk onderuit gaan, zodat de load balancer de resterende teveel werk moet geven) of bij een "onbedoelde DDoS" (bijvoorbeeld als een site "geslashdotted" wordt) zou het wel degelijk kunnen helpen; zowel bij het verminderen van de problemen als duidelijker aan je bezoekers laten weten wat er aan de hand is (lees: preventie van frustratie).


@naikon:
Weet ik (nou ja, ik dacht dat het vier was), maar daar gaat het niet om. Als je meerdere links naar extra files hebt, dan zal een browser die (naar mijn beste weten) uiteindelijk allemaal proberen te downloaden, ook als de eerste een foutmelding geeft. Ik hoop / verwacht dat browsers deze speciale foutmelding gaan gebruiken om het niet eens te proberen.

[Reactie gewijzigd door robvanwijk op 26 juli 2024 03:22]

[naikon]

FYI, de meeste browsers openen maar twee verbindingen maximaal met de server. Dit is een recommendation uit de HTTP/1.1 spec.

[Wim-Bart]

Daarom is een 429 status error eigenlijk wel een mooie oplossing om te integreren bij een reverse proxy of een firewall. Firewall constateerd dat er een 429 fout terug komt van de server achter de firewall en zet aanvragende IP nummer in een dynamische block list.

Downside van deze oplossing is dat je hierdoor complete bedrijven/panden achter een NAT onbedoeld kan uitschakelen zonder geldige reden. Daarnaast heb je ook een zekere vorm van DPI nodig bij afhandelen van HTTP verkeer.

[R-J_W]

1. Wat jij voorsteld is 429 te gebruiken als indicator hoe het met een server gaat, wat als die niet meer in staat is iedereen een statuscode te versturen? Het is efficienter om het verkeer en de serverbelasting te monitoren.
2. Daarbij ga je ervanuit dat deze code verstuurd wordt om specifieke overbelastende gebruikers te waarschuwen. Dit kan, maar het is een taak voor de firewall om deze verbindingen te detecteren en zo nodig te sluiten. Niet iets om ook nog eens aan je contentserver toe te voegen.
3. Dus deze 'downside' heeft niets met de foutcode te maken. Dit gebeurd wanneer de firewall of andere DoS bescherming ip-adressen blokkeert.

429 is een verzoek aan de aanvragers van data, of ze het even rustig aan willen doen en in de praktijk zal een server deze waarschuwing naar random bezoekers sturen wanneer er overbelasting optreed, in plaats van de gebruikelijke 503 service unavailable.

[hiekikowan]

Lijkt mij toch dat je dan server-side een instelling kunt gaan zetten, zogauw er ergens een 429 gedetecteerd wordt ga je blocken... Nu zal je nog altijd zelf een script moeten schrijven dus dit lijkt me vooral voor de minder ervaren programmeurs/scripters een mooie standaard optie om mee te lopen prutsen.

[RwD]

Jij stelt voor na iedere 429 bijvoorbeeld dat ip 10 seconden blokken? Klinkt mij helemaal niet zo slecht; op die manier worden accounts ook beveiligd tegen kraken dmv brute-force.

Nu ben ik niet zo bekend met de impact van het negeren van inkomende requests; je moet tesnlotte het ip adres checken of het geblocked is. Lijkt me mogelijk een service dan sowieso te d-dossen.

[Reactie gewijzigd door RwD op 26 juli 2024 03:22]

[Anoniem: 241683]

Je denkt op een ander niveau, die header stel je toch ook in op de server... Stel daar dan ook in hoe je reageert op meerdere requests binnen 60 seconden bijv.

[.oisyn]

Da's onzin, het zorgt er echt niet voor dat een webserver zich daar dan beter tegen kan beschermen. Het enige verschil is dat hij het met een dergelijke statuscode dat ook terug kan koppelen naar de gebruiker, maar dat is natuurlijk helemaal niet interessant voor daadwerkelijke spammers want die zijn niet geïnteresseerd in de statuscode.

Ik mis overigens nog een statuscode 419 Money Needed

[Reactie gewijzigd door .oisyn op 26 juli 2024 03:22]

[Remus]

Ik ben vooral een fan van HTTP status 418 (of eigenlijk HTCPCP status 418)

[MueR]

You're a teapot?

[Gepetto]

Geloof het of niet, maar ik krijg hier echt een 404 als ik op jouw link klik.

[TvdW]

402 Payment Required

[.oisyn]

Ja duh, ik weet ook dat die bestaat. Je snapt neem ik aan dat ik refereer aan de 419 Nigerian email scam?

[Reactie gewijzigd door .oisyn op 26 juli 2024 03:22]

[Remus]

Zou dat niet zijn 419 Do you want some money?

[_Peter2_]

Ik mis overigens nog een statuscode 419 Money Needed

Die bestaat al: 402 - 402 Payment Required (zie: http://en.wikipedia.org/w...us_codes#4xx_Client_Error)

[HuHu]

Dat denk ik niet. Als je zoiets doet, dan gebruik je geen normale browser die de codes zal respecteren, maar schrijf je zelf een scriptje dat die 429 gewoon negeert. Zoals ook in de tekst staat: het is aan de server om het op te lossen.

[Gamebuster]

Je geeft bij zo'n 429 ook geen content mee als je 't goed wilt doen.

Je handelt de request niet af en je geeft een 429 status code terug om te laten weten waarom. Nu zou je daar 503 Service Unavailable of 403 Forbidden voor gebruiken

[Gepetto]

Het eerste waar ik aan dacht toen ik het stuk begon te lezen was, ha eindelijk een oplossing tegen (d)dos-aanvallen op protocol niveau, maar dit blijkt dus helemaal niet het geval te zijn.

Vraag me af wat deze status dan wel voor voordelen biedt.

[arjankoole]

Vraag me af wat deze status dan wel voor voordelen biedt.

Clients die onbedoeld flooden, door bijvoorbeeld als een zot op F5 te beuken, javascripts die op hol zijn geslagen, dat soort dingen. Mini DoS'jes die onbedoeld en onschuldig zijn, zeg maar.

[Gepetto]

Of juist niet onbedoeld. Had Tweakers.net in het verleden (of nu nog) niet een auto-refresh functie op de frontpage staan?

[edit]
Ik herinner me ineens weer hoe dat zat, er waren gebruikers met een auto-refesh fuctie in hun browser om zo op een gemakkelijk manier hun karma omhoog te helpen hier. Later werden voor het openen van de fp geen karmapunten meer toegekend. Als deze status toen had bestaan had dit inderdaad een mooie oplossing geweest.

[Reactie gewijzigd door Gepetto op 26 juli 2024 03:22]

[David Mulder]

Vraag me af wat deze status dan wel voor voordelen biedt.

Denk bijvoorbeeld aan ticket registraties voor grote evenementen, op server niveau zou worden meegegeven 429, 60 seconds, waardoor de browser gewoon de volgende 60 seconden weigerd een request naar de server uit te zenden.

[R-J_W]

Er zijn maar weinig browserbouwers die dat zouden willen integreren ...

Het gebeurd nogal eens dat een site door een DDoS, technisch probleem of gewoonweg plotseling te veel bezoekers, onbereikbaar wordt.
Wanneer vervolgens al die bezoekers F5 blijven rammen (ja zoals bij ticket-systemen) heb je software nodig die die verbindingen afbreekt.
De meeste sites hebben dit niet en blijven dus onbereikbaar totdat het probleem verholpen is of de meeste bezoekers het opgeven.

Deze statuscode heeft nut omdat zo het bezoekers aandeel in de storing kan verminderen.
Een melding dat de server overbelast raakt en of je even zou willen wachten, is een stuk duidelijker dan een 503 server unavailable.


Mogelijk ook wat minder klachten zoal: "de site is traag en ik krijg steeds foutmeldingen" terwijl iedereen F5 zit te spammen.

[Reactie gewijzigd door R-J_W op 26 juli 2024 03:22]

[Anoniem: 35352]

Er zijn maar weinig browserbouwers die dat zouden willen integreren ...

Ik ben zeker dat alle grote browserbouwers dat meteen zouden implementeren, en mogelijk ook een aantal HTTP-client libraries & frameworks (inclusief libraries die rss feeds volgen e.d.).

De meeste developers willen immers gewoon een "good citizen" zijn.

[doeternietoe]

Je zou echter wel de ip's van clients die deze code negeren kunnen bijhouden en deze blacklisten op een firewall, zodat de requests helemaal niet meer bij de webserver terechtkomen. Nu zijn er dan nog steeds problemen van bijvoorbeeld requests vanachter NAT of een proxyserver(die lijken het immers ook te negeren), maar het zou wel een factor kunnen zijn in het detecteren van bonafide en malafide requests, tijdens een DOS-aanval.

Het vermindert natuurlijk ook enigszins de load, als je geen complete html pagina meer hoeft te sturen, maar alleen een statuscode, waarop de browsers zelf een pagina weergeven. Bij 404 is het nu ook zo dat als het antwoord van de server minder is dan een bepaald aantal bytes, er een foutmelding van de browser zelf verschijnt.

Je vraagt je trouwens wel af hoevaak zo'n statuscode gebruikt wordt. Een flink deel van http-statuscodes kom je vrijwel nooit in het wild tegen en zelfs 404 wordt lang niet altijd gebruikt op momenten dat dit wel zou moeten.

[Reactie gewijzigd door doeternietoe op 26 juli 2024 03:22]

[Gepetto]

Bij een 404 wordt er niet alleen een status gestuurd maar ook de bijbehorende 404.htm. (Al zal deze waarschijnlijk wat minder bytes bevatten dan de eigenlijke opgevraagde pagina).

[ari3]

Als je een 404.htm naar de client verstuurd dan moet je eigenlijk code 200 terug geven want je retourneert een correcte pagina.

404 codes hebben alleen zin als je geen display content naar de gebruiker stuurt.

[mpol]

Nee hoor. In de standaard Apache installatie staat gewoon een 404.htm geconfigureerd om terug te geven bij een 404.
Ook binnen een CMS als Wordpress wordt een 404 weergegeven met de opmaak van het template, zonder enige verdere content, hoogstens een zoek formulier.
Een 200 lijkt me nodig bij het leveren van de gevraagde inhoud. De 404 bij het niet kunnen leveren van die vraag.

[MSalters]

De 200 code is gereserveerd voor het geval dat je de pagina teruggeeft die de gebruiker opvroeg. Je mag 200 niet gebruiken omdat de pagina toevallig correcte HTML bevat.

Sowieso veronderstelt HTTP niet bij voorbaat dat je HTML serveert. Als ik een zip file opvraag, en ik krijg een "200 OK <html><body>NOT FOUND</></>", dan mag ik als broswer proberen die te unzippen (!).

[jvdmeer]

Nog makkelijker, de 429 zou al niet eens bij de server hoeven aan te komen, maar zou al door de loadbalancer, firewall of reverseproxy geantwoord kunnen worden.

Op die manier ontlast je de server van het tel- en rekenwerk en laat je die taak bij de software die daar beter voor is ingericht.

[kramerty88]

Tegen een brute force of DoS kun je met deze http code nog steeds niets, dit is een tagline die doorgestuurd wordt naar een client (als een browser). Voor een aanval is dit makkelijk te negeren.

Het is wel handig tegen hoogverbruik op drukbezochte sites, maar verder zie ik er niet heel veel nut van in.

Over de 431, de splashpagina werkt toch goed? En als je internet van de hotspot wegvalt, kom je wederom toch (99%) op de splashpagina terecht? Is dit dan alleen om aan te geven dat er een fout is bij de host en niet van het internet?

Ook iets waarvan ik niet helemaal het nut van inzie. Maar misschien ben ik wel te sceptisch t.o.v. de toevoegingen.

[arjankoole]

Over de 431, de splashpagina werkt toch goed?

Die voorkomt dat je via een standaard voor alle clients de boel kunt automatiseren. M'n iphone snapt hoe ie bij KPN en t-mobile hotspots moet inloggen omdat ie dat gelogged / gescraped heeft. Maar dat is een ineffeciente methode.

Liever via een 431, en dan een username en password mee kunnen sturen, met zo min mogelijk overhead/wachttijd.

[R-J_W]

True en zo voorkom je dat de verkeerde pagina gecached wordt.
Wanneer je inlog verlopen is/ of je nog niet ingelogd bent geeft elk adres dat je invoerd de inlog pagina.
Wanneer geen of 301 en 307 redirects gebruikt worden, worden deze inlogpagina's gecached in plaats van de eigenlijke pagina.

Een voorbeeld van een andere situatie waarin 431 (of zelfs een 503) beter zou zijn:
Ik kwam laatst een Opera gebruiker tegen die elke keer dat zijn draadloze verbinding weg viel zijn browser herstarte omdat zijn Panda antivirus software een gesponsorde zoekpagina toonde wanneer een pagina onbereikbaar was.
Vervolgens werd deze pagina door Opera gezien als de gezochte pagina ...
(F5 of de refresh-knop ververst de cache wel, maar de tab sluiten en een nieuwe openen niet)

[Glodenox]

Het probleem met die splash-pagina's is dat het semantisch incorrect is om een 301 Moved Permanently of 307 Temporary Redirect te gebruiken om mensen naar zulk een pagina te sturen. Het huidige systeem werkt ook, daar niet van, maar het is deels een soort van misbruik maken van wat er beschikbaar is.

Hoogverbruik op een bepaalde website zou bij een server die zulke codes uitstuurt nog niet altijd opgelost worden, voor de rest heb je volledig gelijk. Die code is enkel nuttig als het gaat over een gewone gebruiker die onwetend veel requests aan het sturen is naar de server via een browser. Al moet ik nog altijd het officiële document lezen, vermoed ik dat het semantisch incorrect zou zijn als deze code naar iedereen wordt uitgezonden om te vermelden dat er momenteel te veel verkeer is naar de server. Die situatie kan enkel omschreven worden als een service die niet beschikbaar is, dus met 503 Service Unavailable.

*edit: typo

[Reactie gewijzigd door Glodenox op 26 juli 2024 03:22]

[Anoniem: 231832]

Het zal de overhead ook verminderen aangezien er geen pagina met melding naar de gebruiker toe hoeft te worden gestuurd. Overigens is een door de web server gegenereerde pagina met automatische refresh time-out ook een prima oplossing.

Met deze nieuwe oplossing voorkom je echter wel dat er te veel server threads bezet worden gehouden en het debuggen van een server wordt ook iets gemakkelijker omdat je meteen ziet dat er niet genoeg threads beschikbaar zijn.

Het zou mooi zijn als een dergelijke code ook in de TCP laag ingebouwd werd.

[Reactie gewijzigd door Anoniem: 231832 op 26 juli 2024 03:22]

[MSalters]

HTTP error codes in de TCP laag? Dat is onzinnig.

En als je bedoelt dat je een TCP equivalent van 429 Too Many Requests error code wil, dat kan niet echt. TCP gebruikt 8 bits in een header om de statussen door te geven (zoals SYN/ACK), en die zijn alle 8 al gealloceerd. Als je een bit gaat hergebruiken, dan gaan duizenden switches op internet daar problemen mee hebben.

[daaan]

Zoals de rest ook al aangeeft is dit slechts een melding.

Het bestaan van een melding faciliteert servers wel weer om too many request netjes af te handelen. Het kan een tijdstip mee sturen (bijvoorbeeld 1 minuut) waarna de client opnieuw kan en mag proberen.

De server kan gedurende de aangegeven tijd alle requests van de cliënt negeren.

De eerste melding zal dus zijn:
429 (60)
Na 20 seconden
429 (40)
Etc.

Het is dus echt een server ding en geen ontwikkelaar ding.

Overigens zou ik zelf geen tijd mee sturen, dat laat immers ook de spammers weten wanneer ze weer mogen. Het mooiste zou een oplopende wachttijd zijn. De eerste keer 1 minuut, de tweede keer 3 minuten, daarna een kwartier of hoger.

[robvanwijk]

De eerste melding zal dus zijn:
429 (60)
Na 20 seconden
429 (40)
Etc.

Nee, het zou waarschijnlijk zijn:
429 (60)
Na 20 seconden
[geen reactie]

Of, nog beter:
429 (60)
[de browser blokkeert de request; het idee is immers om de server zoveel mogelijk te ontzien]

Overigens zou ik zelf geen tijd mee sturen, dat laat immers ook de spammers weten wanneer ze weer mogen.

Het is voor spammers veel makkelijker (en effectiever!) om de hele statuscode vrolijk te negeren en op volle snelheid door te spammen (zelfs als verbindingen meteen verbroken worden, dat kost wel een beetje resources; klein beetje resources * heel veel requests = hoge load). Deze statuscode is puur en alleen bedoeld om je legitieme gebruikers op een nette manier (en met zo min mogelijk load, het serveren van een mooie melding kost teveel resources!) te laten weten wat er aan de hand is.

[Wolfos]

Ook als gebruiker is het handig. Ik kom steeds vaker op sites die down gaan omdat hun advertenties ietsje te succesvol waren, en dan krijg je een 404.
Bestaat dan de pagina nou echt niet of is het gewoon down vanwege teveel bezoekers?

[L-project]

Ah, maar dat zou dan dus een 503 Service unavailable zijn. De 429 gaat er specifiek om dat een unieke bezoeker teveel verzoeken verzend.

[Bartjeh]

Dit is een errorcode die de server teruggeeft, het lost dus niet je probleem op Je vertelt de gebruiker alleen waarom je hem weigert.

En momenteel 503

[Zoijar]

Je gaat er helemaal niks mee tegen; het is alleen een iets nettere manier om je gebruiker te vertellen wat er aan de hand is. Als je wordt aangevallen verbreek je de verbinding gewoon, dan ga je niet nog eens extra data terug sturen. (zoals de opstellers ook schrijven)

[Reactie gewijzigd door Zoijar op 26 juli 2024 03:22]

[mcDavid]

Dat kan ook wel zonder HTTP-foutmelding. Het voordeel is alleen voor de client, aangezien die met zo'n foutmelding ook weet waarom hij de website niet te zien krijgt.

[Chaos101]

En dan? Als je echt een brute-force attack ondergaat, gaan ze echt niet naar je luisteren als je zegt dat het je te veel wordt. Misschien dat browsers er naar luisteren, als dat zo is werkt het wel tegen f5-spam.

[Anoniem: 241683]

Hoezo? Een goede brute-force tool negeert deze header toch gewoon... Er zal hierin niets veranderen, dit is gewoon een header niets meer niets minder. Om brute-force tegen te gaan zijn andere oplossingen.

[ASS-Ware]

Vooral die 429 lijkt me als ontwikkelaar handig. Dit zal een brute-force- of refresh-spam-attack tegen kunnen gaan... iets waar je tegenwoordig regelmatig last van hebt. Goed idee!

Helaas, in het verhaal staat toch duidelijk over die 429 :
Dat moet overigens wel worden gerespecteerd door de gebruikte webbrowsers: denial of service-aanvallen zal deze statuscode niet kunnen tegengaan.

[Upquark]

terwijl de 428-code tot slot aangeeft dat een precondition moet bestaan om de pagina te kunnen tonen.

Kan iemand dat eens uitleggen? Heb de Wikipedia-pagina gelezen, maar zie het verband niet zo?

[CyBeR]

[...]


Kan iemand dat eens uitleggen? Heb de Wikipedia-pagina gelezen, maar zie het verband niet zo?

De uitleg in de RFC is aangaande het tegelijkertijd bewerken van eenzelfde document met WEBDAV. Om te zorgen dat je niet over elkaars wijzigingen gaat zitten plakken zonder het door te hebben, kan de server in dat geval vereisen dat je een If-Match header meestuurt (waarin de md5-sum van het originele bestand staat) zodat de server kan verifieren dat het document dat je probeert te wijzigen, niet in de tussentijd door iemand anders aangepast is. Als je die niet meestuurt, 428 terug.

[jroz2001]

Kan op meerdere manieren gebruikt worden. Voorbeeld:
Het Refomatorisch Dagblad die zondag dicht is kan die melding geven. 'Precondition' is dan bijvoorbeeld dat de pagina alleen te zien is als de servertijd op maandag 0:00 t/m zaterdag 23:59 is.

[den_dolf]

Die 511 code lijkt me er echt te moeten komen. Wanneer iemand dan op een publieke hotspot zit hoeven alle programma's zoals e-mail, messenger, ... niet te klagen dat er 'iets' mis is met de verbinding maar kan er gekeken worden waarom de verbinding niet lukt. minder verwaring bij de gebruiker. doorvoeren die handel!

[mpol]

Ik hoop dat je begrijpt dat dit over het HTTP protocol gaat? E-mail en MSN zijn andere protocollen. Die gebruiken geen HTTP headers.

[MSalters]

Het blijft evengoed het geval. Een email programma wat geen verbinding kan maken met de SMTP server op poort 25 kan dan een snelle poging doen op poort 80. Als dan HTTP 511 error code terugkomt, even de webbrowser opstarten om in te loggen op de proxy.

[Keeper of the Keys]

Om eerlijk te zijn snap ik het nut van 511 niet, we hebben toch allang 407 - Proxy Auth Required, wat is er duidelijker dan dat?

Als je nu een squid machine hebt draaien die authenticatie vereist stuurt die doodleuk een 407 terug met het type (NTLM/Kerberos/Basic/etc) en dan krijgt de gebruiker of een user/pass dialoog te zien of de authenticatie wordt op de achtergrond afgehandeld, en als de gebruiker geen authenticatie invoert dan krijgt hij/zij een "cache access denied" pagina te zien waar staat dat aanmelden een vereiste is...

[HikariMisako]

Wat natuurlijk ook in het artikel had moeten staan is dat de leukste code 418 is
418 'I'm a teapot (RFC 2324)' met als error: 'The HTCPCP server is a teapot; the responding entity may be short and stout.'

[Keypunchie]

Die twee toegelichte statuscodes lijken me zeer nuttig. Vooral die voor wifi-proxies. Maar voordat die dan is doorgevoerd... Heel WiFi-toegangspunten worden slecht onderhouden.

De code voor te lange headers lijkt me iets dat je alleen voor troubleshooting wil aanzetten. Waarom een hacker vertellen dat je zijn pogingen tot manipulatie met lange headers blokkeert?

[Daco]

die 2 lijken me wel handig, maar de vraag is of ze wel effectief gebruikt gaan worden... uiteindelijk zijn er al zo veel die nooit gebruikt worden

[Anoniem: 260928]

Of 420, time to hit the bong!

[Anoniem: 364557]

"als een server over te weinig resources beschikt om alle http-verzoeken uit te voeren, is het beter de verbinding gewoon te verbreken, schrijven de opstellers"
Hoe wil je een verbinding verbreken, terwijl http connectionless is????

[Keypunchie]

Wat bedoel je met "connectionless"? Voor http zet je gewoon een TCP-sessie op:

http://en.wikipedia.org/wiki/Http#HTTP_session

En sinds HTTP/1.1 heb je ook persistente connecties. Dus dat je niet voor ieder request een nieuwe sessie begint: http://en.wikipedia.org/wiki/HTTP_persistent_connection

[Reactie gewijzigd door Keypunchie op 26 juli 2024 03:22]

[Anoniem: 364557]

http://en.wikipedia.org/wiki/Connectionless_protocol
Ik had het wellicht beter stateless kunnen noemen:
"In computing, a stateless protocol is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of requests and responses. A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests.
An example of a stateless protocol is the Hypertext Transfer Protocol (HTTP) which is the foundation of data communication for the World Wide Web."
Zie http://en.wikipedia.org/wiki/Stateless_server

[Reactie gewijzigd door Anoniem: 364557 op 26 juli 2024 03:22]

[Mayco]

Stateless is iets helemaal anders als connectionless. Je kan een HTTP connectie prima afbreken, het blijft TCP.

[Anoniem: 241683]

Een webserver reageert vaak op de header keep-alive. Hiervoor worden resources vrijgehouden voor volgende requests, bijv css/javascript files die geinclude worden in een html bestand.

De verbinding verbreken houdt in mijn ogen in dat de resource niet wordt vrijgemaakt