
HTTP/1.1 just got a major update - treve
http://evertpot.com/http-11-updated/
======
0x0
Why is it not called HTTP/1.2? Or, how will clients (or servers) tell the
difference between a peer implementing RFC 2616 (HTTP/1.1 old version) and RFC
723x (HTTP/1.1 new version)?

Could it be that there is so much software hardcoded to look for "HTTP/1.1"
that a "HTTP/1.2" string would break them all?

~~~
masklinn
Because it does not really change the protocol. It clarifies details and
implements spec fixes (e.g. matches the spec better to actual real-world use).

~~~
0x0
Can you send a 308 permanent redirect to existing software and get the
expected behavior?

~~~
shawnz
Try it out: [http://webdbg.com/test/308/](http://webdbg.com/test/308/)

I get failures in Chrome and IE. Firefox passes if I click OK in a funny
dialog.

~~~
charonn0
> Firefox passes if I click OK in a funny dialog.

308 preserves the HTTP verb[1], and the form on that page uses POST. POST is
not idempotent[2], which means using it more than once with the same
parameters may not yield the same output. For example, POSTing this comment
form twice would _append_ to the resource _twice_ ; as opposed to GETing twice
which just returns the resource unmodified both times.

Firefox correctly (under the old RFC for a 301 redirect[3]) asks for
confirmation before automatically repeating a request that is not guaranteed
to be safe to repeat. Some implementations will instead convert the request
into a GET, which is why 308 was needed in the first place.

[1]:
[http://tools.ietf.org/html/rfc7238#section-3](http://tools.ietf.org/html/rfc7238#section-3)

[2]:
[http://tools.ietf.org/html/rfc2616#section-9.1.2](http://tools.ietf.org/html/rfc2616#section-9.1.2)

[3]:
[http://tools.ietf.org/html/rfc2616#section-10.3.2](http://tools.ietf.org/html/rfc2616#section-10.3.2)

Edit: links

~~~
colanderman
No, idempotency doesn't matter because the action is not applied when a 3xx is
returned. Proof: permanent 3xx replies are cacheable.

The reason confirmation is asked is because the user might not wish to apply
the action to the new URI. (Codified as "safety" in the new 1.1.)

Sources: your links and
[http://tools.ietf.org/html/rfc7231#section-4.2.1](http://tools.ietf.org/html/rfc7231#section-4.2.1)

~~~
charonn0
Responses to POST requests are only cacheable when they include explicit
freshness information[1], which is not the case with the linked test page.

[1]:
[http://tools.ietf.org/html/rfc7231#section-4.3.3](http://tools.ietf.org/html/rfc7231#section-4.3.3)

------
cyphunk
Great writeup. One issue...

    
    
       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".
    

For the sake of privacy would it not be better if there was no such
distinction. Basically now any privacy conscious services need to add
'about:blank' as the referrer when users do not want to have their behaviour
categorised and fingerprinted?

~~~
robryk
If a user doesn't want to send the referrer when there is no referrer, no
referrer should be sent. This then allows sites to distinguish between direct
traffic from users that don't block referrers and traffic with blocked
referrers. I wouldn't expect this to be a significant concern, because the
volume of actual direct traffic is not very large.

~~~
gorhill
> This then allows sites to distinguish between direct traffic from users that
> don't block referrers and traffic with blocked referrers

Any example of benefits for servers to distinguish direct traffic vs. blocked
referrers?

~~~
sergiosgc
When analyzing traffic sources for your site, you could use this to remove
noise created by privacy conscious users. For example, if you wish to evaluate
the efficiency of a magazine add, today you can't distinguish between ad
conversions and privacy conscious users.

It'll take a while for clients to be compliant, if they'll ever be, though.

~~~
gorhill
> if you wish to evaluate the efficiency of a magazine ad

Sorry I still don't get it. No referrer or about:blank are both "noise" in
such case, I still don't see how the distinction is useful to the server to
evaluate efficiency of a particular ad.

~~~
cheald
"about:blank" usually means "was opened from an external program, such as an
IM client".

"No referrer" means "A referrer may have existed, but inclusion of that
information was explicitly declined as a part of the request".

Both are useful.

------
gamegoblin
And I _just_ finished implementing 2616 in a toy server of mine. Sigh. C'est
la vie.

I'm glad this new spec apparently resolves a lot of ambiguities. I _hated_
reading 2616 and some specs it depended on (email, URI, etc).

~~~
profil
Is your toy server open source? I would love to see the source.

~~~
perbu
Are you lacking OSS HTTP/1.1 servers to study? There are tons.

------
userbinator
I don't think splitting it up like that is such a good idea; now, instead of
searching through one file, I have to remember that there are several and look
through them all, just for _one_ conceptual protocol. (TCP has a similar
issue, although most of it is still in 793.)

As for the extra verbosity, I'm not sure what to think; while some things may
be specified more precisely, standards should also attempt to be concise and
to-the-point. Some of the sentences in the new RFCs seem almost parenthetical
(e.g. look at the description of GET.)

~~~
masklinn
OTOH, that means I don't have to dive through the minutiae of response message
format when I'm just looking for the basic header stuff. All the important
concerns (core, caching, conditional requests, auth and forwarding) get their
own RFC and are thus easier to skim and search through. Although 308 and Range
(and Prefer) _also_ getting their RFCs is a bit weird. Likewise, syntax and
routing get RFC 3270 so if you're implementing a client or server the reading
experience should be much tighter,

------
__david__
Finally, the spec is crystal clear that message bodies on GET requests are not
illegal.

~~~
colanderman
Pardon my ignorance but how are GET payloads useful? Does that not violate
REST principles?

~~~
saryant
Elasticsearch: it accepts JSON bodies in GET requests to define the parameters
of a search. These can get quite large so it's preferable to encoding
everything in the query string. The operation is read-only, so an argument can
be made that a GET makes more sense than a POST.

That said, I POST my search params to Elasticsearch anyways.

~~~
robryk
Aren't message bodies on GET supposed not to impact the returned result at
all?

~~~
colanderman
Yes: [http://stackoverflow.com/a/983458](http://stackoverflow.com/a/983458)

------
purephase
Forwarded and a permanent re-direct are nice changes. This is a welcome
change.

It will likely be awhile before widespread adoption, but to see a standard
move forward in such a seemingly small, but considerable way is great.

Kudos to those involved. I can't imagine it was an easy feat.

------
lloeki
The clarifications are very welcome but I wish it included embedded unit-less
progress information on chunk encoding without having to rely on a side
channel [0] (shameless plug, but any progress — ha ha — on this front would be
fine)

[0]: [https://github.com/lloeki/http-chunked-
progress/blob/master/...](https://github.com/lloeki/http-chunked-
progress/blob/master/draft-lnageleisen-http-chunked-progress-00)

------
mjs
The thing I'm most surprised by is the change in the default cacheability of
404 responses from uncacheable to cacheable. Though I guess since defaulting
to cacheable doesn't mean that responses must be cached, so you can still be
compliant with RFC7231 by never caching 404s.

RFC2616:

[http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.4)

"A response received with [a status code other than 200, 203, 206, 300, 301 or
410] MUST NOT be returned in a reply to a subsequent request unless there are
cache-control directives or another header(s) that explicitly allow it."

RFC7231:

[http://tools.ietf.org/html/rfc7231#section-6.5.4](http://tools.ietf.org/html/rfc7231#section-6.5.4)

"A 404 response is cacheable by default"

------
derengel
As someone new to HTTP, what would be the most pragmatic way to read through
this RFCs in the context of building web applications or HTTP APIs but not to
the level of wanting to implement a http server or http client? for example:
order of reading, what can be avoided, what is not widely use or implemented,
the basics of the protocol, etc...

~~~
muaddirac
HTTP methods, status codes, and headers are all you need to understand for
developing at the level of HTTP APIs.

~~~
masklinn
The problem being that it's been spread all over the specs.

The essentials would be:

* 7231 which covers core methods, statuses and basic headers. It looks like the spec authors have also added security considerations sections

* 7232 is probably a good read as it covers conditional requests (304 and 412 statuses)

* 7234 covers caching and cache controls, don't skip it. Even if you don't want your response to be cached, you need to know how caching works, which actors are involved and how to disable it

* 7238 is the 308 redirection, understanding it and the background for its introduction is a good idea _and_ will help with understanding other redirection statuses (301, 302 and 307)

"Various others" would be

* 7233 is Range requests, can probably be skipped unless you have big media payloads. On one hand it's underused, on the other hand it has limited general applicability

* 7235 is Authentication, can be useful for API (the user experience being terrible for browsers) but can probably be skipped unless absolutely necessary

* 7239 is forwarding, to understand what happens when your HTTP endpoint is behind a proxy. Although I'd guess proxies don't implement it yet the ideas already existed as non-standard extensions and reading this is a good idea for "real-world" concerns. Not completely necessary, but useful

* 7240 is the Prefer header. It's a fairly recent and quite advanced addition, probably useful but not utterly necessary

You can ignore

* 7230 is about req/resp format. The only interesting parts are the URI and Host parts which your HTTP library probably handles for you

* 7236 complements 7235 with auth scheme registration for standard auth types. Only read it if you've read 7235

* 7237 is a registry of additional (wrt 7231) methods, mostly from WebDAV

------
BorisMelnik
I wonder what Googlebot will make of this. There is a lot of debate already
amongst search engine developers on which type of redirect to use.

~~~
treve
A crawler like that should typically only do GET requests. The 308 is really
mainly useful for HTTP clients doing for example a PUT or POST request on some
url, and the server wants the client to repeat that exact request on for
example a different server.

------
fafner
RFC7238 is still marked as experimental.

------
mrottenkolber
I am still happily speaking HTTP/1.0 [1] :)

[1] [http://mr.gy/software/httpd0/](http://mr.gy/software/httpd0/)

