11–20 of 44 posts
Earlier quoted context omitted.
Tell the author. This is an aggregator.
The OP might be the author and thus will see this comment. In any case, it can be useful for other people.
Earlier quoted context omitted.
Both the font size and colour scheme on that page hurt my eyes.
On the plus side, it gave you something to complain about.
I think the issue here is that 301 and 302 were originally intended to preserve the HTTP method but they became permanent and temporary versions of "issue a new request with a GET". So to try and fix that they provided 307 (and now 308) as temporary and permanent versions of "this resource changed location, so reissue this request at the new URL".
I actually wrote a post about this a couple of days before RFC 2616 got marked for official deprecation: https://aprescott.com/posts/http-redirects
I plan on updating that with more information once a proper RFC deprecates 2616 and 308 makes its way into something other than a referenced alternative, as it is in the current draft last time I checked.
Also, for fun, try pointing curl at a server returning various response codes and see what it does with `-X [method]` and compare it with the latest Chrome and Firefox.
I think the author of this blogpost has a few things off: - HTTP2 != httpbis. Both work is being done by the same working group "httpbis". http://datatracker.ietf.org/wg/httpbis/charter/ covers this. httpbis ( http://stackoverflow.com/questions/9105639/httpbis-what-does... ) was originally chartered to revise HTTP/1.1 (RFC2616) The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., referenc…
For the rest of us, the language from OP sure sounds like it's saying, "yeah do whatevs with 301, we give up".
People often read RFCs in a hurry. Wouldn't this be a great place to use the a "SHOULD NOT" (change the request method)?
If you're saying "MUST NOT" would be bad because the horse is out of the barn, I understand. But the draft language now sure sounds like "MAY", and the OP has a good point that it's likely to encourage more wrong behavior, not less.
At least IMHO. Again, I am not a standards lawyer, so please take this feedback accordingly.
Can anyone here provide any explanation of how the changes in HTTP2 might not be idiotic? The changes discussed in the post just seem dumb to me, but I assume there has to be some reasoning behind them.
People use HTTP for two things these days:
1. Its originally-stated purpose--an application-layer protocol that allows web browsers to retrive hypermedia documents from web servers. In this usage, HTTP replaced Gopher+FTP.
2. A transport-layer protocol, with features such as identified sub-flows (requests in a pipelined keepalive connection, websockets, etc.), several usefully-different varieties of caching, protocol feature autonegotiation, presentation-layer autonegotiation (Accept headers), automatic redirection semantics, optional encryption (TLS+HSTS+CORS = probably the most well-thought-out security-boundary semantics of any protocol we've got), etc. In this usage, HTTP basically supercedes TCP.
There's a vicious circle here: as HTTP gains traction in sense #2, businesses become increasingly unwilling to allow anything other than HTTP-in-sense-#2 through their firewalls. Eventually, HTTP may be the only transport-layer protocol.
And, given that, on a stance of complete pragmatism where we can't prevent this from happening, only try to make the best of the situation... we need an HTTP-in-sense-#2 that can actually support being used as a universal transport-layer protocol for all of the Internet's traffic.
What does that mean? Well, it means, for one thing, making HTTP lower-overhead (i.e. binary.) It means making HTTP not only work in situations we'd previously have used TCP (e.g. websockets), but also situations where we'd have used UDP (e.g. VoIP streaming.) It means, well, doing pretty much everything HTTP2 does.
Note, though, that HTTP in sense #1 will likely always be around. Nobody who uses HTTP to transfer hypermedia documents between web browsers and web servers needs to switch to HTTP2. HTTP2 can do that, but it isn't for that. (Though, practically, doing HTTP-type stuff over HTTP2 will likely be both faster and more secure.)
While browsers can probably "do anything" with a 301 or 302, I think in practice it's simpler. I think the issue here is that 301 and 302 were originally intended to preserve the HTTP method but they became permanent and temporary versions of "issue a new request with a GET". So to try and fix that they provided 307 (and now 308) as temporary and permanent versions of "this resource changed location, so reissue this…
While browsers can probably "do anything" with a 301 or 302, I think in practice it's simpler. I think the issue here is that 301 and 302 were originally intended to preserve the HTTP method but they became permanent and temporary versions of "issue a new request with a GET". So to try and fix that they provided 307 (and now 308) as temporary and permanent versions of "this resource changed location, so reissue this…
I thought OP said the situation with 301, while not perfect, is much much better than 302. Even if clean-slate 307 and 308 codes is a great idea, I think OP is concerned that redefining 301 to be excessively permissive will make things worse not better -- in that 301 will go from fairly reliable to being as bad as 302.
One quibble: in re "So now you can use a new status code which older browsers won't know what to do with", I feel pretty confident in saying that "older browsers" won't be talking HTTP2...
I also feel pretty confident in saying that it will be the browsers that will be perceived to be "in the wrong" when they reject or ignore such responses, even though it's solely the fault of bad web apps. (See how browsers today need to accept and try to correctly handle totally broken and incorrect markup, for instance.)