The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)

Glossary

The identifier is a name for the issue (and is unique within this document).

The type of issue is one of:

The status of the issue is one of:

The reference is an indication of where the issue was first raised.

The description is a succinct overview of the issue.

The resolution describes the specification change that resolves the issue.

Open Issues

Identifier Type / Status Reference and Description Proposed Resolution / Latest Change
edit
edit
open
julian.reschke@greenbytes.de, 2011-04-15: Umbrella issue for editorial fixes/enhancements. latest change in revision latest

Closed/Editor Issues

Identifier Type / Status Reference and Description Resolution / Latest Change
consistency
change
closed
julian.reschke@greenbytes.de, 2013-10-03: This text was written to be consistent with the other redirect definitions in the httpbis spec; back when -19 was current. It needs to be updated to be consistent with what gets approved. in revision latest:
Done.
consistency307
edit
closed
ben@nostrum.com, 2012-03-16: The 307 definition includes an explicit post about that behavior not being allowed. Section 3 of this doc does neither. in revision 07:
Import (part of the) note from status code 307 description.
missingconsiderations
change
closed
stpeter@stpeter.im, 2012-02-10: According to HTTPbis Part 2, need to explain the request conditions, interactions with response headers, and implications for caches. If certain default behavior is assumed, it would be good to make that explicit. in revision 05:
Added missing caching considerations.
refresh
edit
closed
julian.reschke@greenbytes.de, 2012-01-04: Mention "refresh" workaround. in revision 01:
Done.
respformat
change
closed
Reference: <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0041.html>

derhoermi@gmx.net, 2012-01-14: "The fallback requirement (...) strikes me as a bad idea. It's a transient problem so it should be con- ditioned and how widely supported this is, and it's only useful if you have some HTML implementation on the other end or an interactive user; a web service not meant for interactive use where you can be sure that the code is supported, because, say, you control the client, is unaffected, and if you add that as another exception you basically end up saying you can do this so your site works better with legacy clients in some situ- ations and making your site work good is probably a good idea, so I'd prefer just saying that. I don't really want to ponder whether I should send this hypertext response in response to an OPTIONS request in 2015, just because your specification says I should."

julian.reschke@greenbytes.de, 2012-01-29: See related HTTPbis issue http://trac.tools.ietf.org/wg/httpbis/trac/ticket/332 -- we should fix this in the base spec, then copy over the new text to this document. Proposal: use final text from HTTPbis.
in revision 03:
The spec has been aligned with HTTPbis, relaxing the requirement.
sniffing
edit
closed
rjsparks@nostrum.com, 2012-03-15: Would it be worth adding something to the draft explicitily discouraging UA sniffing? A reference to something that already explores why that's not a good idea perhaps? in revision 07:
Add advice not to attempt UA sniffing.
uaconfirm
change
closed
julian.reschke@greenbytes.de, 2012-02-03: The requirement about UA prompts is subject to an open HTTPbis ticket (http://trac.tools.ietf.org/wg/httpbis/trac/ticket/238), and the text should be aligned with whatever the resolution is. in revision 04:
Align with the proposed fix for the HTTPbis issue by removing the text from the status code definition (in HTTPbis, a relaxed variant is being added to the description of 3xx in general).

Progress

Version Issues
latest ||||||||
07 |||||||
06 |||||
05 |||||
04 ||||
03 |||
02 ||
01 ||
00

Last change: 2013-10-03