.
35 Status of This Memo
37 This Internet-Draft is submitted in full conformance with the
38 provisions of BCP 78 and BCP 79.
40 Internet-Drafts are working documents of the Internet Engineering
41 Task Force (IETF). Note that other groups may also distribute
42 working documents as Internet-Drafts. The list of current Internet-
43 Drafts is at http://datatracker.ietf.org/drafts/current/.
45 Internet-Drafts are draft documents valid for a maximum of six months
46 and may be updated, replaced, or obsoleted by other documents at any
47 time. It is inappropriate to use Internet-Drafts as reference
48 material or to cite them other than as "work in progress."
49 This Internet-Draft will expire on September 27, 2012.
51 Copyright Notice
53 Copyright (c) 2012 IETF Trust and the persons identified as the
54 document authors. All rights reserved.
56 This document is subject to BCP 78 and the IETF Trust's Legal
57 Provisions Relating to IETF Documents
58 (http://trustee.ietf.org/license-info) in effect on the date of
59 publication of this document. Please review these documents
60 carefully, as they describe your rights and restrictions with respect
61 to this document. Code Components extracted from this document must
62 include Simplified BSD License text as described in Section 4.e of
63 the Trust Legal Provisions and are provided without warranty as
64 described in the Simplified BSD License.
66 Table of Contents
68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
69 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
70 3. 308 Permanent Redirect . . . . . . . . . . . . . . . . . . . . 3
71 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
77 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
78 Appendix A. Implementations (to be removed by RFC Editor
79 before publication) . . . . . . . . . . . . . . . . . 7
80 Appendix B. Change Log (to be removed by RFC Editor before
81 publication) . . . . . . . . . . . . . . . . . . . . . 7
82 B.1. Since draft-reschke-http-status-308-00 . . . . . . . . . . 7
83 B.2. Since draft-reschke-http-status-308-01 . . . . . . . . . . 7
84 B.3. Since draft-reschke-http-status-308-02 . . . . . . . . . . 7
85 B.4. Since draft-reschke-http-status-308-03 . . . . . . . . . . 7
86 B.5. Since draft-reschke-http-status-308-04 . . . . . . . . . . 7
87 B.6. Since draft-reschke-http-status-308-05 . . . . . . . . . . 8
88 B.7. Since draft-reschke-http-status-308-06 . . . . . . . . . . 8
89 Appendix C. Resolved issues (to be removed by RFC Editor
90 before publication) . . . . . . . . . . . . . . . . . 8
91 C.1. consistency307 . . . . . . . . . . . . . . . . . . . . . . 8
92 C.2. sniffing . . . . . . . . . . . . . . . . . . . . . . . . . 8
93 Appendix D. Open issues (to be removed by RFC Editor prior to
94 publication) . . . . . . . . . . . . . . . . . . . . . 8
95 D.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
97 1. Introduction
99 HTTP defines a set of status codes for the purpose of redirecting a
100 request to a different URI ([RFC3986]). The history of these status
101 codes is summarized in Section 7.3 of
102 [draft-ietf-httpbis-p2-semantics], which also classifies the existing
103 status codes into four categories.
105 The first of these categories contains the status codes 301 (Moved
106 Permanently), 302 (Found), and 307 (Temporary Redirect), which can be
107 classified as below:
109 +-------------------------------------------+-----------+-----------+
110 | | Permanent | Temporary |
111 +-------------------------------------------+-----------+-----------+
112 | Allows changing the request method from | 301 | 302 |
113 | POST to GET | | |
114 | Does not allow changing the request | - | 307 |
115 | method from POST to GET | | |
116 +-------------------------------------------+-----------+-----------+
118 Section 7.3.7 of [draft-ietf-httpbis-p2-semantics] states that HTTP
119 does not define a permanent variant of status code 307; this
120 specification adds the status code 308, defining this missing variant
121 (Section 3).
123 2. Notational Conventions
125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
127 document are to be interpreted as described in [RFC2119].
129 3. 308 Permanent Redirect
131 The target resource has been assigned a new permanent URI and any
132 future references to this resource SHOULD use one of the returned
133 URIs. Clients with link editing capabilities ought to automatically
134 re-link references to the effective request URI (Section 5.5 of
135 [draft-ietf-httpbis-p1-messaging]) to one or more of the new
136 references returned by the server, where possible.
138 Caches MAY use a heuristic (see [draft-ietf-httpbis-p6-cache],
139 Section 2.3.1.1) to determine freshness for 308 responses.
141 The new permanent URI SHOULD be given by the Location field in the
142 response ([draft-ietf-httpbis-p2-semantics], Section 10.5). A
143 response payload can contain a short hypertext note with a hyperlink
144 to the new URI(s).
146 Note: This status code is similar to 301 Moved Permanently
147 (Section 7.3.2 of [draft-ietf-httpbis-p2-semantics]), except that
148 it does not allow rewriting the request method from POST to GET.
150 4. Deployment Considerations
152 Section 4 of [draft-ietf-httpbis-p2-semantics] requires recipients to
153 treat unknown 3xx status codes the same way as status code 300
154 Multiple Choices ([draft-ietf-httpbis-p2-semantics], Section 7.3.1).
155 Thus, servers will not be able to rely on automatic redirection
156 happening similar to status codes 301, 302, or 307.
158 Therefore, initial use of status code 308 will be restricted to cases
159 where the server has sufficient confidence in the clients
160 understanding the new code, or when a fallback to the semantics of
161 status code 300 is not problematic. Server implementers are advised
162 not to vary the status code based on characteristics of the request,
163 such as the User-Agent header field ("User-Agent Sniffing") -- doing
164 so usually results in both hard to maintain and hard to debug code
165 and would also require special attention to caching (i.e., setting a
166 "Vary" response header field, as defined in Section 3.5 of
167 [draft-ietf-httpbis-p6-cache]).
169 Note that many existing HTML-based user agents will emulate a refresh
170 when encountering an HTML refresh directive ([HTML]). This
171 can be used as another fallback. For example:
173 Client request:
175 GET / HTTP/1.1
176 Host: example.com
178 Server response:
180 HTTP/1.1 308 Permanent Redirect
181 Content-Type: text/html; charset=UTF-8
182 Location: http://example.com/new
183 Content-Length: 454
185
187
188
189 Permanent Redirect
190
192
193
194
195 The document has been moved to
196 http://example.com/new.
198
199
200
202 5. Security Considerations
204 All security considerations that apply to HTTP redirects apply to the
205 308 status code as well (see Section 12 of
206 [draft-ietf-httpbis-p2-semantics]).
208 6. IANA Considerations
210 The registration below shall be added to the HTTP Status Code
211 Registry (defined in Section 4.2 of [draft-ietf-httpbis-p2-semantics]
212 and located at ):
214 +-------+--------------------+---------------------------------+
215 | Value | Description | Reference |
216 +-------+--------------------+---------------------------------+
217 | 308 | Permanent Redirect | Section 3 of this specification |
218 +-------+--------------------+---------------------------------+
220 7. Acknowledgements
222 The definition for the new status code 308 re-uses text from the
223 HTTP/1.1 definitions of status codes 301 and 307.
225 Furthermore, thanks to Ben Campbell, Cyrus Daboo, Eran Hammer-Lahav,
226 Bjoern Hoehrmann, Subramanian Moonesamy, Peter Saint-Andre, and
227 Robert Sparks for feedback on this document.
229 8. References
231 8.1. Normative References
233 [RFC2119] Bradner, S., "Key words for use in
234 RFCs to Indicate Requirement
235 Levels", BCP 14, RFC 2119,
236 March 1997.
238 [RFC3986] Berners-Lee, T., Fielding, R., and
239 L. Masinter, "Uniform Resource
240 Identifier (URI): Generic Syntax",
241 STD 66, RFC 3986, January 2005.
243 [draft-ietf-httpbis-p1-messaging] Fielding, R., Ed., Lafon, Y., Ed.,
244 and J. Reschke, Ed., "HTTP/1.1,
245 part 1: URIs, Connections, and
246 Message Parsing",
247 draft-ietf-httpbis-p1-messaging-19
248 (work in progress), March 2012.
250 [draft-ietf-httpbis-p2-semantics] Fielding, R., Ed., Lafon, Y., Ed.,
251 and J. Reschke, Ed., "HTTP/1.1,
252 part 2: Message Semantics",
253 draft-ietf-httpbis-p2-semantics-19
254 (work in progress), March 2012.
256 [draft-ietf-httpbis-p6-cache] Fielding, R., Ed., Lafon, Y., Ed.,
257 Nottingham, M., Ed., and J.
258 Reschke, Ed., "HTTP/1.1, part 6:
259 Caching",
260 draft-ietf-httpbis-p6-cache-19
261 (work in progress), March 2012.
263 8.2. Informative References
265 [HTML] Raggett, D., Le Hors, A., and I.
266 Jacobs, "HTML 4.01 Specification",
267 W3C Recommendation REC-html401-
268 19991224, December 1999, .
272 Latest version available at
273 .
275 URIs
277 [1]
279 [2]
281 Appendix A. Implementations (to be removed by RFC Editor before
282 publication)
284 Chrome: Feature requested in Chromium Issue 109012
285 ().
287 Curl (the library): no change was needed (test case:
288 ).
290 Firefox: now in "nightly" builds, scheduled for release in Firefox 14
291 (see ).
293 Safari: automatically redirects 3xx status codes when a Location
294 header field is present, but does not preserve the request method.
296 Appendix B. Change Log (to be removed by RFC Editor before publication)
298 B.1. Since draft-reschke-http-status-308-00
300 Updated HTTPbis reference. Added Appendix A. Added and resolved
301 issue "refresh".
303 B.2. Since draft-reschke-http-status-308-01
305 Added URI spec reference.
307 B.3. Since draft-reschke-http-status-308-02
309 Tune HTML example. Expand "Implementations" section. Added and
310 resolved issue "respformat" (align with new proposed text for 307 in
311 HTTPbis P2).
313 B.4. Since draft-reschke-http-status-308-03
315 Added and resolved issue "uaconfirm".
317 B.5. Since draft-reschke-http-status-308-04
319 Added and resolved issue "missingconsiderations". Added request
320 message to example. Updated the Safari implementation note.
322 B.6. Since draft-reschke-http-status-308-05
324 Add informative HTML reference. Update HTTPbis references.
326 B.7. Since draft-reschke-http-status-308-06
328 Added and resolved issues "consistency307" and "sniffing". Updated
329 Firefox implementation status.
331 Appendix C. Resolved issues (to be removed by RFC Editor before
332 publication)
334 Issues that were either rejected or resolved in this version of this
335 document.
337 C.1. consistency307
339 In Section 3:
341 Type: edit
343 ben@nostrum.com (2012-03-16): The 307 definition includes an explicit
344 post about that behavior not being allowed. Section 3 of this doc
345 does neither.
347 Resolution: Import (part of the) note from status code 307
348 description.
350 C.2. sniffing
352 In Section 4:
354 Type: edit
356 rjsparks@nostrum.com (2012-03-15): Would it be worth adding something
357 to the draft explicitily discouraging UA sniffing? A reference to
358 something that already explores why that's not a good idea perhaps?
360 Resolution: Add advice not to attempt UA sniffing.
362 Appendix D. Open issues (to be removed by RFC Editor prior to
363 publication)
365 D.1. edit
367 Type: edit
369 julian.reschke@greenbytes.de (2011-04-15): Umbrella issue for
370 editorial fixes/enhancements.
372 Author's Address
374 Julian F. Reschke
375 greenbytes GmbH
376 Hafenweg 16
377 Muenster, NW 48155
378 Germany
380 EMail: julian.reschke@greenbytes.de
381 URI: http://greenbytes.de/tech/webdav/