subscribe

HTTP/1.1 just got a major update.

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

Web mentions

Comments

  • Michael •

    "has not been split up over 6 separate specs" -> "has _now_ been split up over 6 separate specs"

    • Evert

      Evert •

      I always do that, thanks!

  • Michael •

    It might be obfious to those that are in the know, but why call it 1.1? why not 1.2? seams weird to make the old version obsolete and not increment the version numbers.

    • Lukasaoz •

      This doesn't obsolete HTTP/1.1, it updates the specification. Basically, RFC 2616 got clarified and updated to reflect real-world practice. It's still HTTP/1.1. There should be no problems with interop.

      EDIT: To clarify, RFC 2616 is obsoleted, HTTP/1.1 is not.

      • Frederik Erectus •

        How can you say that it's still "HTTP/1.1" when there are compatibility-breaking changes?

        My god, man, they are in your list! The very list you just posted!

        These are the most blatant of the ones you have listed:

        - Default charset of ISO-8859-1 has been removed.
        - Content-Range has been explicitly banned in PUT requests.
        - Servers are no longer required to handle all Content-* header fields.
        - The 204, 404, 405, 414 and 501 status codes are now cachable.
        - The Location header can now contain relative uri's as well as fragment
        identifiers.
        - Content-MD5 has been removed.

        How can compatibility be retained when functionality is removed, or the expectations that decades of existing software built upon are no longer guaranteed to hold true?

        My god, man! My god! This is a huge debacle in the making.

        What we have here is not HTTP/1.1! It is a bastardization of HTTP/1.1; an imitation of it. It clearly cannot be HTTP/1.1 because it is not compatible with HTTP/1.1!

        This should have been called HTTP/1.2. There is no way justify calling this HTTP/1.1, when complete compatibility is not retained.

        This isn't just fixing the formatting of the RFC document, for crying out loud. This introduces changes to a very well established protocol! My god, man! My god! Do you people not see the global implications of this very poor decision?

        The time is not too late, though. Please, the Internet community begs of you, reconsider the naming of this. Call it HTTP/1.2. Call it anything but HTTP/1.1! For it is not HTTP/1.1. It is not!

        • Evert

          Evert •

          Once you get a hold of yourself and read through those changes in depth, you may find that the actual reality is that more people are compatible with _this_ version of HTTP/1.1 than RFC2616.

        • Lukasaoz •

          Firstly, this isn't my article. =)

          Secondly, the changes to the RFC codify behaviour that was already happening. Taking your points in order:

          - The default charset was never respected. Python's requests library followed it and we got so many bug reports for that behaviour. New RFCs correctly say that HTML does not meaningfully have a default encoding (in practice it's usually UTF-8).
          - PUT means 'here is the entire entity', store this at the chosen request URI. That is semantically incompatible with 'I am sending you these bytes of the entity'. PATCH should be used here. All this change does is spell out the inconsistency.
          - I honestly have no clue about what this point is talking about, seemed unclear to me.
          - Caches were already caching these response codes: for example, Squid and Traffic Server, some of the widest-deployed caches already did this. In fact, the spec treaded a middle ground in the hope that these caches would stop caching some other dangerous responses (like 500).
          - Relative URIs in Location headers were already being used A LOT. All modern user-agents can handle them.
          - I'll turn straight to RFC 7231 for this: "The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses."

          The global implications here are very minor. No-one was following RFC 2616 to the letter: you cannot operate on the modern web if you do that. This specification change brought HTTP/1.1 up to date with how it's actually used on the web, while attempting to rein in some of the biggest excesses.

          HTTP/1.1, before today, was not the protocol written in RFC 2616. It's much more like the protocol written in RFC 723[0-5]. Better to have some RFCs that actually reflect how the protocol truly is than some idealised notion of a protocol that does not exist. At least that's my view.

        • lala •

          Just to add my five cents:
          Incompatibility exists even among implementation conforming to the same old RFC 2616 because it wasn't strict enough that implementations would agree on its interpretation.

      • Michael •

        Thanks everyone for the heated responses. I can see that its a passionate subject. Minor increment numbers not used in this setup HTTP/1.1.6 then.

    • StoneCypher •

      Because this is still HTTP/1.1 . There's already a 1.2.

      This is almost identical to 1.1. There's no significant changes here. There's no new features. All this does is clarify how things are supposed to work, resolve some outstanding questions, and codify some common practice as official.

      This is nothing like a point release.

      Why would you suggest that this should be a point release? Do you understand what goes into an RFC point release? It's well defined. In an RFC.

      • Fred •

        It should be called HTTP/1.2 or HTTP/1.1c (clarified) or HTTP/1.1.1

        This is much easier to understand in technical meetings with a bunch of PHBs
        than saying: HTTP1.1-rfc7230s*

        As for the Google SPDY protocol, it should be called HTTP/2.0
        or just keep it SPDY and make it official.

        • StoneCypher •

          1.1c is a pretty good idea.

          1.2 is already taken, and can't be used.

  • Nilesh Trivedi •

    > to distinguish between "there was no referrer" and
    "I don't want to send a referrer".

    Why is this a good idea? This distinction creates another bit of information to track users.

    • Frosty •

      You are trackable anyways. I dont get whats the sense of disabling web features to gain more privacy, when you login regulary somewhere with your realname?

      • gorhill •

        I think he means this add one more bit to fingerprinting information.

    • Amal Krishnan •

      The 'referer' header leaks everything in the url to a third-party. The url might contain sensitive parameters or sometimes the url might itself be sensitive. The HTTP specification only disallows sending the 'referer' header from an HTTPS site to an HTTP site. This makes the assumption that all sites running over HTTPS trust each other.

  • Daniel •

    A couple of corrections:
    1. HTTP/1.1 isn't obsolete, RFC2616 is.
    2. 308 is not Standard, nor even Proposed Standard, but Experimental.

    • Evert

      Evert •

      I clarified your first point, thnx.

  • Frederik Erectus •

    10 RFCs?! My god, man! Why are there so many?

    HTTP/1.1 is supposed to be a simple protocol. RFC2616 was a very moderately sized document. But now we have to deal with 10 separate spec documents! My god, man!

    My god, man! The bureaucracy is maddening! In the days of yore, I had only to tell an aspiring HTTPist to "Read RFC2616". Now I will need to tell aspiring HTTPists to "Read RFC 7230 and RFC 7231 and RFC 7232 and RFC 7233 and RFC 7234 and RFC 7235 and RFC 7236 and RFC 7237 and RFC 7238 and RFC 7239"!

    My god, man, do you not see how stupid this is now?

    • Evert

      Evert •

      The reality is that HTTP/1.1 is not simple. Just reading RFC2616 may give you a good idea of the original design 15 years ago, but not what you actually need to do to implement a client that meets today's expectations.

      You'll also find that the new documents, while having a higher pagecount, are actually much easier to understand for any newcomers.

      If you want to have a discussion about this, please hold off with the hyperbole and reduce the amount of emotion in your comments. This is not a Fox News discussion panel.

      • John Doe •

        He's just trolling.

        • StoneCypher •

          Actually, you are. He had a point he wanted to make.

  • cwh •

    Would be helpful if you linked to where in the RFCs your bullet points come from

  • disqus_gJy6FYV58g •

    Good discussion about the reasoning behind the name, and I am glad this has been debated. I was wondering why the number wasn’t incremented either since — as someone pointed out — things have been changed. But as another poster noted, it is probably more compliant with how 1.1 is working in the real world now because of the considerations of what has become de-facto implementation as well as removing obscurity of the original specs.

    So, call it whatever you want, IMO, as long as the person you are talking to about it understands that you are talking about HTTP1.1 clarified via RFC723x. I might start referring to it as “HTTP1.1 Clarified” or ”HTTP1.1-rfc7230s*” {“*seventy-two thirties”} or something that makes it clear what I am talking about. That way it will remove any ambiguity about what I am talking about.

    Leaving the debate about the appropriateness of the name chosen aside, these are good, helpful documents (what I have read thus far). So, rather than debate the name of the collection, I would rather hear comments about them (as is inherent in the name “RFC”), so those of us newer to them can all learn from those that have been wading in these waters longer than others. thanks.

  • joão dias •

    RFC 7231 changed 403, makes it almost the same as 401. that's stupid.