Internet Engineering Task Force (IETF) J. Reschke
-Request for Comments: 7238 greenbytes
-Category: Experimental June 2014
+Request for Comments: 7538 greenbytes
+Obsoletes: 7238 April 2015
+Category: Standards Track
ISSN: 2070-1721
Status of This Memo
- This document is not an Internet Standards Track specification; it is
- published for examination, experimental implementation, and
- evaluation.
+ This is an Internet Standards Track document.
- This document defines an Experimental Protocol for the Internet
- community. This document is a product of the Internet Engineering
- Task Force (IETF). It represents the consensus of the IETF
- community. It has received public review and has been approved for
- publication by the Internet Engineering Steering Group (IESG). Not
- all documents approved by the IESG are a candidate for any level of
- Internet Standard; see Section 2 of RFC 5741.
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
- http://www.rfc-editor.org/info/rfc7238.
+ http://www.rfc-editor.org/info/rfc7538.
Copyright Notice
- Copyright (c) 2014 IETF Trust and the persons identified as the
+ Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
-Reschke Experimental [Page 1]
+
+
+
+Reschke Standards Track [Page 1]
\f
-RFC 7238 HTTP Status Code 308 June 2014
+RFC 7538 HTTP Status Code 308 April 2015
Table of Contents
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 2
- 3. 308 Permanent Redirect . . . . . . . . . . . . . . . . . . . . 2
- 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 3
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
- 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2
+ 3. 308 Permanent Redirect . . . . . . . . . . . . . . . . . . . 3
+ 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 3
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
+ 7.2. Informative References . . . . . . . . . . . . . . . . . 5
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
| method from POST to GET | | |
+-------------------------------------------+-----------+-----------+
- Section 6.4.7 of [RFC7231] states that HTTP does not define a
- permanent variant of status code 307; this specification adds the
- status code 308, defining this missing variant (Section 3).
+ Section 6.4.7 of [RFC7231] states that it does not define a permanent
+ variant of status code 307; this specification adds the status code
+ 308, defining this missing variant (Section 3).
+
+ This specification contains no technical changes from the
+ Experimental RFC 7238, which it obsoletes.
2. Notational Conventions
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
-3. 308 Permanent Redirect
- The 308 (Permanent Redirect) status code indicates that the target
- resource has been assigned a new permanent URI and any future
- references to this resource ought to use one of the enclosed URIs.
-Reschke Experimental [Page 2]
+Reschke Standards Track [Page 2]
\f
-RFC 7238 HTTP Status Code 308 June 2014
+RFC 7538 HTTP Status Code 308 April 2015
+
+3. 308 Permanent Redirect
+ The 308 (Permanent Redirect) status code indicates that the target
+ resource has been assigned a new permanent URI and any future
+ references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link
references to the effective request URI (Section 5.5 of [RFC7230]) to
one or more of the new references sent by the server, where possible.
4. Deployment Considerations
Section 6 of [RFC7231] requires recipients to treat unknown 3xx
- status codes the same way as status code 300 Multiple Choices
+ status codes the same way as status code 300 (Multiple Choices)
([RFC7231], Section 6.4.1). Thus, servers will not be able to rely
on automatic redirection happening similar to status codes 301, 302,
or 307.
- Therefore, initial use of status code 308 will be restricted to cases
- where the server has sufficient confidence in the client's
- understanding the new code or when a fallback to the semantics of
- status code 300 is not problematic. Server implementers are advised
- not to vary the status code based on characteristics of the request,
- such as the User-Agent header field ("User-Agent Sniffing") -- doing
- so usually results in code that is both hard to maintain and hard to
- debug and would also require special attention to caching (i.e.,
- setting a "Vary" response header field, as defined in Section 7.1.4
- of [RFC7231]).
+ Therefore, the use of status code 308 is restricted to cases where
+ the server has sufficient confidence in the client's understanding
+ the new code or when a fallback to the semantics of status code 300
+ is not problematic. Server implementers are advised not to vary the
+ status code based on characteristics of the request, such as the
+ User-Agent header field ("User-Agent Sniffing") -- doing so usually
+ results in code that is both hard to maintain and hard to debug and
+ would also require special attention to caching (i.e., setting a
+ "Vary" response header field, as defined in Section 7.1.4 of
+ [RFC7231]).
- Note that many existing HTML-based user agents will emulate a refresh
- when encountering an HTML <meta> refresh directive ([HTML]). This
- can be used as another fallback. For example:
- Client request:
- GET / HTTP/1.1
- Host: example.com
-Reschke Experimental [Page 3]
+
+Reschke Standards Track [Page 3]
\f
-RFC 7238 HTTP Status Code 308 June 2014
+RFC 7538 HTTP Status Code 308 April 2015
+
+
+ Note that many existing HTML-based user agents will emulate a refresh
+ when encountering an HTML <meta> refresh directive ([HTML],
+ Section 4.2.5.3). This can be used as another fallback. For
+ example:
+
+ Client request:
+
+ GET / HTTP/1.1
+ Host: example.com
Server response:
HTTP/1.1 308 Permanent Redirect
Content-Type: text/html; charset=UTF-8
Location: http://example.com/new
- Content-Length: 454
+ Content-Length: 356
- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
+ <!DOCTYPE HTML>
<html>
<head>
<title>Permanent Redirect</title>
All security considerations that apply to HTTP redirects apply to the
308 status code as well (see Section 9 of [RFC7231]).
-6. IANA Considerations
-
- The registration below has been added to the "Hypertext Transfer
- Protocol (HTTP) Status Code Registry" (defined in Section 8.2 of
- [RFC7231] and located at
- <http://www.iana.org/assignments/http-status-codes>):
-
- +-------+--------------------+---------------------------------+
- | Value | Description | Reference |
- +-------+--------------------+---------------------------------+
- | 308 | Permanent Redirect | Section 3 of this specification |
- +-------+--------------------+---------------------------------+
-
+ Unsecured communication over the Internet is subject to man-in-the-
+ middle modification of messages, including changing status codes or
+ redirect targets. Use of Transport Layer Security (TLS) is one way
+ to mitigate those attacks. See Section 9 of [RFC7230] for related
+ attacks on authority and message integrity.
-
-
-Reschke Experimental [Page 4]
+Reschke Standards Track [Page 4]
\f
-RFC 7238 HTTP Status Code 308 June 2014
+RFC 7538 HTTP Status Code 308 April 2015
-7. Acknowledgements
+6. IANA Considerations
- The definition for the new status code 308 reuses text from the
- HTTP/1.1 definitions of status codes 301 and 307.
+ The "Hypertext Transfer Protocol (HTTP) Status Code Registry"
+ (defined in Section 8.2 of [RFC7231] and located at
+ <http://www.iana.org/assignments/http-status-codes>) has been updated
+ to reference this specification.
- Furthermore, thanks to Ben Campbell, Cyrus Daboo, Eran Hammer-Lahav,
- Bjoern Hoehrmann, Subramanian Moonesamy, Peter Saint-Andre, and
- Robert Sparks for feedback on this document.
+ +-------+--------------------+----------------------------------+
+ | Value | Description | Reference |
+ +-------+--------------------+----------------------------------+
+ | 308 | Permanent Redirect | Section 3 of this specification |
+ +-------+--------------------+----------------------------------+
-8. References
+7. References
-8.1. Normative References
+7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
+ Requirement Levels", BCP 14, RFC 2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, January 2005.
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005,
+ <http://www.rfc-editor.org/info/rfc3986>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
- Protocol (HTTP/1.1): Message Syntax and Routing",
- RFC 7230, June 2014.
+ Protocol (HTTP/1.1): Message Syntax and Routing", RFC
+ 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
- June 2014.
+ June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
- RFC 7234, June 2014.
-
-8.2. Informative References
-
- [HTML] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
- Specification", W3C Recommendation REC-html401-19991224,
- December 1999,
- <http://www.w3.org/TR/1999/REC-html401-19991224>.
-
- Latest version available at
- <http://www.w3.org/TR/html401>.
+ RFC 7234, June 2014,
+ <http://www.rfc-editor.org/info/rfc7234>.
+7.2. Informative References
+ [HTML] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle
+ Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
+ Recommendation REC-html5-20141028, October 2014,
+ <http://www.w3.org/TR/2014/REC-html5-20141028/>.
+ Latest version available at <http://www.w3.org/TR/html5/>.
+Reschke Standards Track [Page 5]
+\f
+RFC 7538 HTTP Status Code 308 April 2015
+Acknowledgements
-Reschke Experimental [Page 5]
-\f
-RFC 7238 HTTP Status Code 308 June 2014
+ The definition for the new status code 308 reuses text from the
+ HTTP/1.1 definitions of status codes 301 and 307.
+ Furthermore, thanks to Ben Campbell, Cyrus Daboo, Adrian Farrell,
+ Eran Hammer-Lahav, Bjoern Hoehrmann, Barry Leiba, Subramanian
+ Moonesamy, Kathleen Moriarty, Peter Saint-Andre, Robert Sparks, and
+ Roy Fielding for feedback on this document.
Author's Address
-
-
-
-
-
-
-
-
-
-
-Reschke Experimental [Page 6]
+Reschke Standards Track [Page 6]
\f
projects / thirdparty / squid.git / commitdiff
