On 2012-01-13 22:19, Brian Smith wrote:
See https://bugzilla.mozilla.org/show_bug.cgi?id=714302
and http://tools.ietf.org/html/draft-reschke-http-status-308-01.
Basically, it is a new kind of redirect that doesn't cause any problems,
doesn't have any benefits to us (AFAICT), and isn't standardized yet. If we add
support for it, we are basically endorsing this as an addition to the HTTP
protocol.
That is correct, but let me add a few thoughts.
In HTTP/1.1 as defined per RFC 2616, rewriting of methods upon redirects
was not allowed for status codes 301 and 302. The status code for what
most web sites do on form POSTs should be *303*.
For historic reasons, UAs did not follow, and we ended up with the spec
and reality disagreeing.
See summary in
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#status.3xx>.
RFC 2616 also added status code 307 as a "I mean it" variant of 302. All
UAs get this right nowadays (but it took some time for Safari to get there).
In HTTPbis, we decided to allow browsers to do what they do for 301 and
302 for redirected POSTs. After all, there was zero chance that this
would ever change.
So what's now missing is a "permanent" variant of 307 (which should have
been 302), and that's why I'm working on defining 308.
It would be good for our team to provide feedback on it. Julian has already
written a patch to add support for it in Firefox. The Firefox patch (AFAICT)
treats 308 exactly like a 307. We should give him a response one way or the
other.
Yes, please :-)
Note that 308 works like 307 mainly because 301 works like 302. If
Firefox ever is going to treat them differently (permanent vs
temporary), then of course the same distinction should apply to 308 vs 307.
I don't think it is very important, and I am generally opposed to making minor new
features to HTTP like this unless they have a major benefit, because they end up creating
compatibility problems because there will always be products that take forever to support
the addition. So, I am leaning towards saying "nope, do not want."
Which is an argument for never making changes :-)
The compatibility/deployment issues are discussed over here:
<http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-01.html#rfc.section.4>.
Also, I can see the point of a permanent redirect for some cases (e.g. telling a search
engine that it should start preferring something else), but I have a hard time seeing why
we need a permanent redirect for non-GET requests in the real world and especially in
browsers. In the real world, if you need to permanently change where something gets
POSTed to, you change the thing that makes the POST request. That kind of permanent
change usually (AFAICT) shouldn't be done automatically for security reasons, so in some
sense the requirement for manual intervention makes sense. And, status code 307 already
has the same semantics without the idea of the redirect being "permanent."
Apache mod_dav for instance redirects requests to WebDAV collections if
the URI doesn't have a trailing "/" (to the preferred URI with the "/").
Right now that happens with a 301, as far as I recall.
If you use POST from XHR you definitively don't want that to be silently
rewritten to GET. (Right now Firefox even rewrites PROPFIND to GET, but
we have a separate bug for that).
In general, 301/302/307/308 are for the case where the URI has changed.
The request method doesn't matter in this case.
303 is for "thanks for the data, GET *this* for a result". 301 and 302
are commonly abused for the second case, but there's no way to change that.
All that said, it is a relatively benign change.
It is.
Let me add a few words about process.
Many new HTTP status codes have been defined without any impact on
browsers, because their default behavior is sufficient (like any new
type of 4xx or 5xx).
308 is slightly different as Firefox by default doesn't redirect
(Safari, for instance does).
308 could be used today already as long as the sender adds workarounds
to the payload (like a meta refresh with the new URI), or the recipient
(for instance JS calling XHR) follows the redirect itself. As such it
can be used in an experimental way already.
So the Internet Draft could proceed to LC and publication without any
implementation in browsers. On the other hand, it would be bad if we
defined something and then later find out that UAs *can't* implement it.
Thus the proposed patch.
I do not expect Firefox to go ahead and say "yes, this is a great idea",
and implement it in the -12 time frame. But what would be useful is to
get feedback of the kind "this is harmless, and we'll put it in once the
IESG has approved the spec", or "OMG, this can't be implemented,
because...", or something in between.
Best regards, Julian
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
