The httpbis working group of the IETF has release RFC7230 (HTTP/1.1) which obsoletes the long serving RFC2616 (HTTP/1.1), which itself obsoleted the ill fated RFC2068 (HTTP/1.1), which had attempted to replace RFC1945 (HTTP/1.0). So with the 4th version of a HTTP/1.x specification, some might argue that we really should be talking about HTTP/1.3 rather than 3 versions on HTTP/1.1!
So what is going on? Why a new specification for an existing protocol, specially when the same working group is also deep into considerations of http2!
The new RFC (and several companion RFCs) are not trying specifying a new protocol or even a new version of the HTTP protocol. It is essentially a clarification exercise to write down a specification that captures the best recommended practises for how HTTP/1.1 has actually been implemented. Specifically the httpbis charter was to:
- Incorporate errata and updates (e.g., references, IANA registries, ABNF)
- Fix editorial problems which have led to misunderstandings of the specification
- Clarify conformance requirements
- Remove known ambiguities where they affect interoperability
- Clarify existing methods of extensibility
- Remove or deprecate those features that are not widely implemented and also unduly affect interoperability
- Where necessary, add implementation advice
- Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications
The reason this was necessary, is that no spec is perfect and RFC2616 did have a number of ambiguities, failed features and security problems. This has made it very difficult for a well written server because of the sage advice of being strict in what you generate but forgiving in what you parse. A forgiving HTTP Server written against RFC2616 has to cope with a wide range of requests and can often be tricked into seeing requests where there are none.
RFC7230 gives a server permission and advice to be a little bit less forgiving, thus allowing simple/faster code with less edge cases and thus less bugs and/or security exploits. You can see a good summary of these changes in the Changes from RFC2616 section. Jetty will be following 7230 advice from releases 9.3 and/or 10.0 and I’m very pleased to have already removed support for 0.9, continuation headers and arbitrary white space in headers.
But why is this needed if HTTP/2 is soon to arrive? Well HTTP/1 is not going away any time soon. It has taken more than 20 years to remove HTTP/0.9 support and I expect at least a similar time before HTTP/1 is relegated. Actually given the current complexity of HTTP/2, HTTP/1 may need another protocol to be standardised before it is replaced in some environments. But also HTTP2 is only defining a new transport for HTTP semantics, so RFC7230 will still be relevant and required in a HTTP/2 environment.
The authors and contributors to RFC7230 have done a great job and the Jetty team has already started work on both RFC7230 as well as HTTP/2. You can see the progress in the jetty-http2 branch, which is currently labelled 10.0.0-SNAPSHOT, but may become 9.3.0.
0 Comments