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.
| 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 07 |
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| 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). |
| Version | Issues |
|---|---|
| latest | ||||||| |
| 07 | ||||||| |
| 06 | ||||| |
| 05 | ||||| |
| 04 | |||| |
| 03 | ||| |
| 02 | || |
| 01 | || |
| 00 |
Last change: 2012-03-16