This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec has specific requirements for HTTP status codes 301, 302, and 307. Status code 308 should be added here. Approved IETF spec: <https://datatracker.ietf.org/doc/draft-reschke-http-status-308/> IANA registry: <http://www.iana.org/assignments/http-status-codes/http-status-codes.xml> Related mozilla bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=758973>
So now each time we talk about redirects we have to reference two documents? Is there not some better way?
(In reply to comment #1) > So now each time we talk about redirects we have to reference two documents? Is > there not some better way? In theory you could just talk about the semantics of the status code (does it really have "redirection semantics" as per category 1 in <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#status.3xx>), and point the reader to the IANA registry for status codes. The bigger issue here is that, optimally, HTTPbis would answer this question for unknown 3xx codes as well (because, after all, introducing 308 shouldn't require special support from browsers). But then, with the addition of 308, the set of "real" redirect codes should be complete anyway.
https://github.com/whatwg/xhr/commit/9911e0e70b4685605a2feb4cbb49c6373ea42813 Leaving open to see if the HTTP issue gets resolved somehow.
(In reply to comment #3) > https://github.com/whatwg/xhr/commit/9911e0e70b4685605a2feb4cbb49c6373ea42813 > > Leaving open to see if the HTTP issue gets resolved somehow. I don't believe that the HTTPbis specs are going to change with respect to this. HTTPbis is close to WGLC, so if you believe it *should* say more here it would be good to send feedback to the WG mailing list.
Also fixed this in CORS btw: https://github.com/whatwg/fetch/commit/1bc9976cc455da53cc907204e23736dd49cb6dcd (You'll be added to the acknowledgments next commit, forgot.)
As long as HTTP does not say anything I guess browsers will treat the others as not redirecting either so resolving this as fixed. Further changes to redirect handling are probably best discussed separately.