Skip to content

Latest commit

 

History

History
110 lines (90 loc) · 4.23 KB

2014-06-06-http-11-updated.md

File metadata and controls

110 lines (90 loc) · 4.23 KB
Raw
date layout title tags geo location
2014-06-07 03:17:48 UTC
post
HTTP/1.1 just got a major update.
http
ietf
rfc
featured
43.64103
-79.416103
King St West, Toronto, ON, CA

The IETF just published several new RFCs that update HTTP/1.1:

These documents make the original specification for HTTP/1.1 obsolete. As a HTTP geek, this is a big deal.

RFC 2616, which was written more than 15 years ago, was the specification everybody has implemented, and I suspect many of you occassionally have used as a reference.

Since then, the HTTPBis group has worked from what I can tell, at least 7 years on updating these specs. You can imagine that for a protocol as widespread as HTTP, there will be many stakeholders and opinions to satisfy.

HTTP/2.0, which is still under development, will also reference these rfcs and essentially just link to them, as opposed to re-define all the definitions from scratch.

I've been using the drafts of these new standards documents for years, as it did not take long for them to be much references than the original.

What's new?

The biggest difference compared to the old spec, is that there is simply a lot more text. A lot of things are easier to understand and read, and parts where there were ambiguity has been resolved.

A second change is that the core specification has now been split up over 6 separate specs, whereas before there was just RFC 2616 for HTTP, and RFC 2617 for Basic and Digest authentication.

Just for those reasons alone it may make a lot of sense for API authors to read the specs from end-to-end. Guarenteed you'll learn and get inspired into doing better HTTP api design.

Furthermore the 308 status code is now standard, which provides a 4th redirect status. 308 is a permanent redirect. Clients that receive a 308 are expected to follow the redirect and execute the exact same request again. This, as opposed to the 301, where clients usually change the method into a GET.

RFC 7239 standardizes a Forwarded header, which is supposed to replace headers such as X-Forwarded-For and X-Forwarded-Proto.

A far from complete list of interesting things that have changed.

  • Clarifications around dealing with unexpected whitespace, which should fix response splitting vulnerabilities.
  • The limit of two connections per server has been removed.
  • HTTP/0.9 support has been dropped.
  • Default charset of ISO-8859-1 has been removed.
  • Servers are no longer required to handle all Content-* header fields.
  • Content-Range has been explicitly banned in PUT requests.
  • It's now suggested to use the about:blank uri in the Referer header when no referer exists, to distinguish between "there was no referrer" and "I don't want to send a referrer".
  • The 204, 404, 405, 414 and 501 status codes are now cachable.
  • The status codes 301 and 302 have been changed to allow user agents to rewrite the method from POST to GET. This is a good example of a case where everybody has been (incorrectly) already doing this, and the spec now reflects the real world implementation.
  • The Location header can now contain relative uri's as well as fragment identifiers.
  • Content-MD5 has been removed.

Anything else I missed?

References