21–30 of 44 posts
Earlier quoted context omitted.
On the plus side, it gave you something to complain about.
Pointing out flaws is a perfectly valid and useful activity, especially when there is significant room for improvement, like in this case.
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.
Alright, think of it this way. 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-differen…
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…
It sounds like you're well-marinated in standards bodies, and that's a good thing -- it's tough, often thankless work that someone needs to do. 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 bec…
Now, as far as "SHOULD NOT", that's a reasonable thought for people not aware of what popular user agents currently do. The thing is, the majority of major browsers rewrite POST to GET on a 301. Here's my browser's code for it: https://code.google.com/p/chromium/codesearch#chromium/src/n.... Here's Firefox's code for it: http://mxr.mozilla.org/mozilla-central/source/netwerk/protoc.... To my knowledge, all browsers implement this behavior. We basically copied IE's behavior, because, IE did it and websites expected all user agents to do what IE did. Story of the web, sound familiar? :P
So, as you can see, Julian was merely acknowledging the pragmatic reality of the situation when he updated the httpbis specs to reflect this behavior: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1428. And this reasoning behind it is covered in the introduction to the relevant section in the httpbis docs: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2....
"SHOULD NOT" implies that our implementations are behaving badly. Now, it's true, our implementations may not be behaving ideally from a spec cleanliness point of view, but interop trumps spec cleanliness, at least from the perspective of anyone who actually deploys real software on the internet. So it's probably best for the spec to acknowledge this and officially allow this. Specs that don't mirror reality are...probably not just useless, but actively harmful.
I hope that explains things, cheers.
Earlier quoted context omitted.
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.
302 is already bad, and 301 is already wrongly implement as RFC 2616 itself notes. Ultimately I doubt either is going to see a "fixed" implementation from a buggy one that's lasted as long as it has.
Earlier quoted context omitted.
302 is already bad, and 301 is already wrongly implement as RFC 2616 itself notes. Ultimately I doubt either is going to see a "fixed" implementation from a buggy one that's lasted as long as it has.
That doesn't answer the question, namely, "will loosening the definition for 301 make things worse than not changing it?". In this thread I've not seen a solid argument that it won't make things worse, only long redirections (ha!) from the point. Are you saying that 301 is so widely, badly implemented as to be a lost cause, as the author concedes 302 is?
Earlier quoted context omitted.
It sounds like you're well-marinated in standards bodies, and that's a good thing -- it's tough, often thankless work that someone needs to do. 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 bec…
I guess I should out myself as a Chromium HTTP stack maintainer (since 2009, so this behavior predates me). One might consider me a domain expert here. I participate in IETF HTTPbis for the HTTP/2 work as the primary Chromium representative. I am not involved with the RFC 2616 revision work as that's tough, thankless work, that thank god we have Julian Reschke and Roy Fielding working on. As far as I'm concerned, I o…
Earlier quoted context omitted.
That doesn't answer the question, namely, "will loosening the definition for 301 make things worse than not changing it?". In this thread I've not seen a solid argument that it won't make things worse, only long redirections (ha!) from the point. Are you saying that 301 is so widely, badly implemented as to be a lost cause, as the author concedes 302 is?
I don't know enough about client implementations to say whether it is unsaveable, but let's say it is: why would 308 exist? That suggests the HTTP spec folks believe it's fundamentally changed meaning. With new-301, new-302/303, 307 and 308, we'd cover each of the 4 cases. Seems to strongly suggested that's necessary.
Meanwhile, hobohacker got around to answering the real question.
Earlier quoted context omitted.
It sounds like you're well-marinated in standards bodies, and that's a good thing -- it's tough, often thankless work that someone needs to do. 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 bec…
I guess I should out myself as a Chromium HTTP stack maintainer (since 2009, so this behavior predates me). One might consider me a domain expert here. I participate in IETF HTTPbis for the HTTP/2 work as the primary Chromium representative. I am not involved with the RFC 2616 revision work as that's tough, thankless work, that thank god we have Julian Reschke and Roy Fielding working on. As far as I'm concerned, I o…
> existing practice today is that 301, 303, and 307 are used correctly pretty much everywhere
is flat out wrong. I guess that's a nicer and more probable resolution than "standards people suck!".
(It is possible to override this behavior in the client with a bit of code, but I was trying to make this work with software that had already shipped.)
Earlier quoted context omitted.
Alright, think of it this way. 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-differen…
None of that explains the changes to redirect codes, which are the main point of the article. Those are what sound truly brain dead.
Would you trust this unstable "pragmatic" house of card to deliver its promises of being "working"?