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?
> Default charset of ISO-8859-1 has been removed
> 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
I get failures in Chrome and IE. Firefox passes if I click OK in a funny dialog.
308 preserves the HTTP verb, and the form on that page uses POST. POST is not idempotent, 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) 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.
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
So, this new "HTTP/1.1" feature broke my existing (old-)HTTP/1.1 chrome browser!
If they had called it HTTP/1.2 they could send a non-308 redirect to HTTP/1.1 clients and 308 to HTTP/1.2.
Instead, we now have servers and clients both speaking "HTTP/1.1" (whatever that is this week) not able to interoperate.
Section 6 of [RFC7231] requires recipients to treat unknown 3xx
status codes the same way as status code 300 Multiple Choices
([RFC7231], Section 6.4.1). Thus, servers will not be able to rely
on automatic redirection happening similar to status codes 301, 302,
Therefore, initial use of status code 308 will be restricted to cases
where the server has sufficient confidence in the client's
understanding the new code or when a fallback to the semantics of
status code 300 is not problematic.
We'll see how well that goes.
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".
Any example of benefits for servers to distinguish direct traffic vs. blocked referrers?
It'll take a while for clients to be compliant, if they'll ever be, though.
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.
"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.
If the target URI was obtained from a source that does not have its
own URI (e.g., input from the user keyboard, or an entry within the
user's bookmarks/favorites), the user agent MUST either exclude the
Referer field or send it with a value of "about:blank".
Yet another way to fingerprint.
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).
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.)
That said, I POST my search params to Elasticsearch anyways.
The reason I can think of for sending a payload in a GET is if the data you wanted to send in a query string is too large.
It also defeats caching and any other reasons why you would want to use GET over some other http requests.
I would argue that the only reason left why you would use GET for that, is because it's aesthetically pleasing.
Not all systems support practically unlimited URI payloads. In the past, this forced either contorsion (gzipping URI payload) or piping everything through POST.
For instance, let's say you've built a music identification system, people can send in files and get information about the file's data. This is a purely readonly request, the backend just uses its information to identify the file and fetch whatever data and metadata on the file's content it has. But historically there was no choice but to route it via a semantically unsuitable POST.
 Apache defaults to 8190 bytes, IIS to 16384, Safari and Firefox support >100k but MSIE is limited to 2048
It does not break caching.
Instead of just using the URL as the caching key, use URL+body. Same URL and same body = same response.
Well, except that since the body isn't defined as having semantics that determine the response, an cache based on the HTTP protocol spec has no reason to do that.
> Does that not violate REST principles?
Most attempts to impose semantics on GET bodies would violate REST principles as well as breaking HTTP (given that GET responses are cacheable and the body is treated as not relevant to the response.)
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.
"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."
"A 404 response is cacheable by default"
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
You can certainly skip most of "Message Syntax and Routing". That's the stuff that concerns server and client implementers that just have tcp sockets to work with.
I would absolutely read "Semantics and Content". It's a really good idea to be aware of "Conditional Requests", and you only really have to read "Caching", "Range requests" and "Authentication" if you need to know about those features.