idnits 2.17.1 draft-reschke-http-status-308-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2012) is 4412 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Reschke 3 Internet-Draft greenbytes 4 Intended status: Experimental March 26, 2012 5 Expires: September 27, 2012 7 The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent 8 Redirect) 9 draft-reschke-http-status-308-07 11 Abstract 13 This document specifies the additional HyperText Transfer Protocol 14 (HTTP) Status Code 308 (Permanent Redirect). 16 Editorial Note (To be removed by RFC Editor before publication) 18 Distribution of this document is unlimited. Although this is not a 19 work item of the HTTPbis Working Group, comments should be sent to 20 the Hypertext Transfer Protocol (HTTP) mailing list at 21 ietf-http-wg@w3.org [1], which may be joined by sending a message 22 with subject "subscribe" to ietf-http-wg-request@w3.org [2]. 24 Discussions of the HTTPbis Working Group are archived at 25 . 27 XML versions, latest edits, and the issues list for this document are 28 available from 29 . 31 Test cases related to redirection in general and the status code 308 32 in particular can be found at 33 . 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/