IETF werkt http 1.1-standaard na zeven jaar bij

De Internet Engineering Task Force heeft de http 1.1-specificaties bijgewerkt. De wijzigingen zouden vooral de specificaties van het protocol moeten verduidelijken en daarnaast ook enkele beschrijvingen moeten aanscherpen.

Het belangrijkste is dat RFC2616, een document met protocolomschrijvingen dat sinds 1999 als basis diende voor http 1.1, is vervangen. De reden daarvoor is dat ontwikkelaars http gingen gebruiken voor meer zaken dan alleen browsen. Om verwarring te voorkomen en het een en ander te verduidelijken werkte de Internet Engineering Task Force aan een verbetering van RFC2616.

RFC2616 omvatte 176 pagina's met uitleg over definities, zoals de get-request en het beheer van tcp-connecties. De specificaties zijn nu verdeeld in zes onderdelen, zodat het makkelijker is te lezen en logischer is opgedeeld, schrijft voorzitter Mark Nottingham van de taskforce.

In totaal werden sinds 2007 met onder meer technici van opensource-organisaties en van bedrijven als Google, Microsoft en Apple 550 vraagstukken opnieuw onder de loep genomen. Alle zogeheten requests for comments, documenten waarin nieuwe aanpassingen worden behandeld, hebben nu een sectie gekregen waarin de veranderingen vanaf RFC2616 staan.

Overigens zijn niet alleen alle documenten taalkundig opgeschoond, maar zijn er ook definities met betrekking tot beveiligingsproblemen verder aangescherpt. Zo is het folden van een header over meerdere regels nu verouderd, om zo http-response-splitting tegen te gaan.

Voorzitter Nottingham laat in zijn blogpost tenslotte weten dat het http 2.0 bijna af is en dat de Internet Engineering Task Force daarover binnenkort meer bekendmaakt. Die versie zal deels gebruik maken van de nieuwe specificaties van 1.1 en zal verder vrijwel zeker standaard encryptie geactiveerd hebben, werd eind vorig jaar duidelijk.

Reacties (41)

Als RFC2616 nu vervangen is, wat is dan het nieuwe document? Lijkt me wel zo informatief om daar in het artikel naar te verwijzen

Voor de duidelijkheid, dat zijn de volgende RFC's:

RFC7230 - HTTP/1.1: Message Syntax and Routing - low-level message parsing and connection management
RFC7231 - HTTP/1.1: Semantics and Content - methods, status codes and headers
RFC7232 - HTTP/1.1: Conditional Requests - e.g., If-Modified-Since
RFC7233 - HTTP/1.1: Range Requests - getting partial content
RFC7234 - HTTP/1.1: Caching - browser and intermediary caches
RFC7235 - HTTP/1.1: Authentication - a framework for HTTP authentication

Wat bedoelen ze met "Zo is het folden van header over meerdere lijnen nu verouderd"???
Als nerd weet ik dat een spatie, een <cr> een <lf> en een <tab> (en zo nog een paar karakters) als <blank> worden geïnterpreteerd maar in hun typografische functie worden afgebeeld. Daarbij zorgen de <blank>s samen voor 'leesbaarheid'.

Of is 'folden' iets anders dan het op 76 karakters breed houden van de code? (76 is voor smtp, http kan een andere waarde hebben, dat weet ik niet uit mijn hoofd.)

"Of is 'folden' iets anders dan het op 76 karakters breed houden van de code? "

Ja, wat jij noemt is de body/content. Daar zijn geen afspraken over aangezien je geen idee hebt wat de content zou moeten representeren.
Een header mag je in de meeste protocollen op meerdere regels zetten:

X-Foo: bla\r\n
\tbla\r\n

is gelijk aan

X-Foo: bla bla\r\n

omdat je een regel in de headers die begint met een whitespace dient te zien als een continuation van de vorige regel. Zie bv rfc 822 :

3.1.1. LONG HEADER FIELDS
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called "folding". The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted.

[Reactie gewijzigd door Dorank op 7 juni 2014 20:19]

Okeee..... bijna goed maar toch iets anders... Toch nog even naar email vertaald: het gaat om de header-fields niet om de body. Bij de headers is een regel einde ( <cr> of <cr><lf> ...) het einde van het header-field. Behalve daar waar de volgende regel met een <blank> (<tab>, <spatie> oid) begint.

Dat is dus anders dan in een taal als c, waar de <cr> en <lf> ascii codes gewoon onderdeel zijn van de <blank>s. Daar is de ; het einde van een statement, maar dat is iets heel anders.

Dorank, Jammer dat ik jou score niet kan bijwerken..... +1 of +2 is wel op zijn plaats.

[Reactie gewijzigd door beerse op 7 juni 2014 21:17]

Vraagje aan de gemiddelde Tweaker: waarom 1.1 bijwerken als 2.0 bijna af is en dus ook binnen enkele jaren zal worden geintergreerd in innovatieve browsers als Chrome?

innovatieve browsers als Chrome?

Moest dat nu echt? Er is echt niks innovatiefs aan het integreren van een protocol zo basaal als HTTP. Dit klinkt als het ophemelen van een browser omdat die webpagina's kan tonen.

Vraagje aan de gemiddelde Tweaker: waarom 1.1 bijwerken als 2.0 bijna af is en dus ook binnen enkele jaren zal worden geintergreerd

Anyway, het is volledig logisch om huidige versies bij te werken, dat gaat even goed op voor protocollen als software. Microsoft werkt het 7 jaar oude Vista ook nog steeds bij. Daarbij komt er al uit verschillende bronnen kritiek voor HTTP2, waarom weet ik niet zo van buiten, maar er zijn wel al vele die vragen om een snelle ontwikkeling van HTTP3.

Chrome is innovatief vanwege ondersteuning voor bijvoorbeeld SPDY en andere moderne snufjes Niet door de standaard functionaliteit die je inderdaad in elke browser ziet.

je beseft dat je naar een pagina linkt waar staat dat zo goed als alle brouwsers SPDY ondersteunen?

Dat bevestigd toch dat het een innovatieve functie was?
Google heeft het protocol ontwikkeld, en die vernieuwing is ondertussen door de meeste andere browsers overgenomen, en zelfs de specificatie voor http 2.0 is er op gebaseerd.

Het nooit verkeerd zaken te updaten als het nieuwe nog niet klaar is. De vrijgifte van nieuwe versies kan nog vertraging oplopen of gewoon weg nog even duren voor dat die er zal zijn.

Inderdaad. Dit is heel normaal in de 'enterprise' wereld. Een goed voorbeeld hiervan is DNS software BIND. BIND 10 is al een tijdje af, maar het team achter BIND heeft BIND 10 aan de community overgedragen. BIND 9 daarintegen blijven ze updaten. BIND 9 wordt veel meer gebruikt dan BIND 10, en system admins hebben geen zin / willen niet / kunnen het niks schelen om te upgraden naar BIND 10 als dat inhoud dat ze alle configs moeten herschrijven, dependancies moeten installeren en misschien zelfs de kernel moeten upgraden.

Een ander voorbeeld is Microsoft. Microsoft brengt "nog steeds" updates uit voor Windows 7, al is upgraden naar een nieuw OS natuurlijk niet gratis. Canonical doet dit ook, Ubuntu 14.04 (paar maanden geleden uitgegeven) krijgt voor een lange tijd updates, ook als nieuwere versies zijn uitgebracht. Ubuntu 14.04 is een zogenaamde LTS uitgave (Long Term Support), en bij Ubuntu zijn upgrades naar nieuwere versies wél gratis.

Daarnaast nog een case-specific reden die ik zo kan bedenken: Bij HTTP 2.0 gaat alles via SSL. Niet iedereen kan/wil die ~$10 voor een SSL certificaat betalen, of heeft een krachtig genoege server die al die encryptie kan doen. HTTP 1.1 zal dus nog wel een tijdje blijven, naast HTTP 2.0. Geen reden om het dan niet te updaten .

Laatste alinea is een non-reden.
Een basis SSL certificate is gratis, degene die meer nodig hebben dan een basis, zijn grote bedrijven en die hebben er wel geld voor over (en sowieso: het kost je $50 eenmalig voor een lifetime).
Krachtige server: ook een non-reden: SSL kan je perfect serven met een server van 10-15 jaar oud.
Bij zo'n server zal het aantal clients meer de bottleneck spelen dan het gebruik van SSL, maar vanaf je veel clients nodig hebt, heb je ook nood aan een nieuw servertje...

Persoonlijk vind ik SSL ook onnodig voor alle verkeer. Ik hoef tweakers.net niet zonodig te lezen via HTTPS. Daar komt nog bij dat het hele CA gebeuren ook nogal leunt op vertrouwen, in grootendeels allemaal Amerikaanse bedrijven. Dus je mag je best afvragen of dit misschien niet een stuk schijnveiligheid is. Als je dan gaat kijken hoeveel extra resources het gaat kosten wereldwijd om alle webdiensten die niet perse HTTPS nodig hebben wel met HTTPS te gaan serveren lijkt het mij nogal verspilling, zowel van geld als van energie.

Denk ook dat HTTP 1.1 nog lang blijften dan vooral voor simpele webinterfaces van hardware.

Omdat versie 2.0 door bouwt op 1.1, en in laatstgenoemde nog wat vage dingen zaten die nu zijn verduidelijkt. Zo is er een solide basis

Inderdaad. Dit is voornamelijk gedaan zodat niet alles opnieuw gedefinieerd hoefde te worden in HTTP 2.0, zoals ook in het originele artikel staat.
Door het op te splitsen kunnen de relevante dingen worden hergebruikt.

[Reactie gewijzigd door dtech op 7 juni 2014 15:13]

Waarom uberhaupt het versienummer 1.1 blijven hanteren als je een update plaatst? Waarom dan niet 1.1rev1 of iets dergelijks ervan maken?

Waarom nog een service pack uitbrengen voor XP als windows 7 al uit is?

Tweakers-antwoord: omdat het kan

Waarom bugs in versie x oplossen als versie y volgens jaar uitkomt? Allemaal maar raar he?! Malle jongens daar bij het IETF


(Ik weet dat het HIER niet om bugs gaat. Reactie is sarcastisch bedoeld)

[Reactie gewijzigd door LarBor op 7 juni 2014 14:23]

Ik ook niet, want wat je zegt is gewoon goed. Als iedereen op die manier zou denken, zouden we nu allemaal nog met hearthbleeds rondlopen ect ect. Maarja.

Juist. Documentatie valt daar net zo goed onder.
Je ziet het ook met boeken: 1e druk, 2e druk. Kleine correcties of aanvullingen.

Is het dan zo dat je bij http 2 geen certificaat meer hoeft aan te schaffen voor een versleutelde verbinding? Aangezien http 2 encryptie standaard aan heeft staan?

Encryptie = Standaard (geen certificaat voor nodig, vergelijkbaar met selfsigned cert. op dit moment)
Authenticatie = Niet standaard (certificaat voor nodig)

En in dit geval dus, authenticatie in de zin van een website die bewijst de website te zijn die hij zegt te zijn, door middel van een gesigned certificaat door een vertrouwde CA.

Voor de mensen die afvragen wat het verschil is, zonder authenticatie is encryptie niet veilig tegen zogenaamde Man-in-the-middle aanvallen.

Door encryptie is simpel afsluiteren niet meer mogelijk, maar je kunt nog steeds "tussen" de 2 servers in gaan zitten en een beveiligde verbinding met beide opbouwen en het verkeer doorsluizen zodat je het nog wel kunt afsluiteren.

Dit is de reden waarom lang veel mensen zeiden dat encryptie zonder authenticatie zinloos was, maar inmiddels zijn de meeste mensen daarop teruggekomen en daarom zit encryptie ook standaard in HTTP 2, zelfs zonder certificaat/authenticatie.

Bedankt voor de uitleg! Maar zou je nog kunnen vertellen waarom ze er terug op zijn gekomen om toch wel encryptie toe te voegen? Als er nog steeds man-in-the-middle aanvallen mogelijk heeft het toch weinig nut? Het enige is dat er iets meer tijd overheen gaat voor de aanvaller om de data te encrypten, maar dat is denk ik niet zo moeilijk. Hierdoor liggen inloggegevens die verstuurd zijn met http 2 uiteindelijk toch nog op straat.

Zonder naar de http2.0 rfcs te hebben gekeken denk ik dat ze ervan uitgaan dat er andere standaarden gebruikt worden voor authenticatie (zonder CA chain) van certificaten tegen MitM:
DANE/TSLA rfc6698
wat weer afhankelijk is van DNSSEC (rfc4033/4044/4045).

Hiermee kan je gewoon een fingerprint van een certificaar per dnsnaam/protocol/poort publiceren op trusted manier zonder afhankelijk te moeten zijn van de CAs• . Je heb slechts een zinnige DNS provider nodig en resolvers die dnssec validatie doen (naast dat de tld dnssec geimplementeerd dient te hebben).

*: die niet een trackrecord hebben van 100% betrouwbaarheid.

Een mitm aanval is lastiger dan simpelweg afsluiteren, dus encryptie zonder authenticatie heeft zeker wel een waarde.

Bij bijv. wifi heb je zonder RADIUS geen authenticatie, en toch verklaart iedereen je voor gek als je je netwerk open zet.

HttP 2.0 > Yeey, bijna alles en iedereen SPDY (http://caniuse.com/#feat=spdy)

Misschien dat flash nog verdwijnt, dan ben ik helemaal happy.

Flash is al rap aan het uitsterven hoor. HTML5 video word meer en meer mainstream.

Fijn dat HTTP2.0 eraan komt, maar ik heb zo'n idee dat dit veel te laat gaat zijn. De markt is al redelijk aan het verzadigen qua noodzaak voor smartphones (ik denk dat velen gewoon hun toestel blijven behouden) net als pc's en daardoor is het dan maar de vraag of mensen hun systeem kunnen updaten om deze versie te kunnen ondersteunen. Het heeft imo weinig zin als dit pas in 2025 kan worden gebruikt als er dan voldoende ondersteuning is via de vele devices. Of het zal in ieder geval weinig impact hebben als het uitkomt.

Is dat niet gewoon een browser update? En kunnen websites niet beiden ondersteunen?

Beide ondersteunen kan natuurlijk wel, maar telkens die legacy inbouwen is gewoon niet handig. Dan heb je weinig aan de voordelen omdat je ze niet echt kunt benutten. En het is inderdaad een browser(engine)-update, maar die komen alleen met OS-updates mee.

Die versie zal deels gebruik maken van de nieuwe specificaties van 1.1 en zal verder vrijwel zeker standaard encryptie geactiveerd hebben, werd eind vorig jaar duidelijk.

Ze zeiden dat internet verkeer versleutelen een groot deel van 'het probleem' rondom dat NSA/pricacy gedoe zou oplossen. Als het al eind vorig jaar helder was dat alles versleutelt gaat worden in de toekomst, dan was dat Reset The Net ge-rel ook een storm in een glas water.

HTTPS gebruiken != zware encryptie.

Misschien een vreemde vraag, maar als er vanaf 2.0 standaard encriptie is, dan zou de standaard toch eigenlijk HTTPS 2.0 moeten gaan heten?

Waarom zou elke website / pagina encryptie moeten hebben, een plaatje heeft dat toch ook niet

Dat is niet mijn punt. Mijn punt is als het wel verplicht wordt (dus los van jouw vraag). Waarom heet het dan niet HTTPS 2.0 ipv HTTP 2.0

Komt verwarrend over, aangezien HTTP 2.0 zal worden geassocieerd met de encryptie-loze variant (http), wat natuurlijk niet handig is als encryptie verplicht wordt (de https variant).