p2-semantics.unpg.txt   rfc7231-to-be.unpg.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7231 Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 J. Reschke, Ed.
Updates: 2817 (if approved) greenbytes Updates: 2817 greenbytes
Intended status: Standards Track May 6, 2014 Category: Standards Track May 2014
Expires: November 7, 2014 ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP/1.1 messages, systems. This document defines the semantics of HTTP/1.1 messages,
as expressed by request methods, request header fields, response as expressed by request methods, request header fields, response
status codes, and response header fields, along with the payload of status codes, and response header fields, along with the payload of
messages (metadata and body content) and mechanisms for content messages (metadata and body content) and mechanisms for content
negotiation. negotiation.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on November 7, 2014. 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/rfc7231.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 21 skipping to change at page 4, line 51
9.3. Disclosure of Personal Information . . . . . . . . . . . . 83 9.3. Disclosure of Personal Information . . . . . . . . . . . . 83
9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83
9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83
9.6. Disclosure of Product Information . . . . . . . . . . . . 84 9.6. Disclosure of Product Information . . . . . . . . . . . . 84
9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . . 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . . 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 90 A.6. MHTML and Line-Length Limitations . . . . . . . . . . . . 90
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
Each Hypertext Transfer Protocol (HTTP) message is either a request Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request, or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in parses each message received, interprets the message semantics in
skipping to change at page 7, line 11 skipping to change at page 7, line 11
repetition). Appendix C describes rules imported from other repetition). Appendix C describes rules imported from other
documents. Appendix D shows the collected grammar with all list documents. Appendix D shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
2. Resources 2. Resources
The target of an HTTP request is called a resource. HTTP does not The target of an HTTP request is called a "resource". HTTP does not
limit the nature of a resource; it merely defines an interface that limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Each resource is might be used to interact with resources. Each resource is
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 2.7 of [RFC7230]. Section 2.7 of [RFC7230].
When a client constructs an HTTP/1.1 request message, it sends the When a client constructs an HTTP/1.1 request message, it sends the
target URI in one of various forms, as defined in (Section 5.3 of target URI in one of various forms, as defined in (Section 5.3 of
[RFC7230]). When a request is received, the server reconstructs an [RFC7230]). When a request is received, the server reconstructs an
effective request URI for the target resource (Section 5.5 of effective request URI for the target resource (Section 5.5 of
[RFC7230]). [RFC7230]).
skipping to change at page 8, line 32 skipping to change at page 8, line 32
| Content-Type | Section 3.1.1.5 | | Content-Type | Section 3.1.1.5 |
| Content-Encoding | Section 3.1.2.2 | | Content-Encoding | Section 3.1.2.2 |
| Content-Language | Section 3.1.3.2 | | Content-Language | Section 3.1.3.2 |
| Content-Location | Section 3.1.4.2 | | Content-Location | Section 3.1.4.2 |
+-------------------+-----------------+ +-------------------+-----------------+
3.1.1. Processing Representation Data 3.1.1. Processing Representation Data
3.1.1.1. Media Type 3.1.1.1. Media Type
HTTP uses Internet Media Types [RFC2046] in the Content-Type HTTP uses Internet media types [RFC2046] in the Content-Type
(Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
to provide open and extensible data typing and type negotiation. to provide open and extensible data typing and type negotiation.
Media types define both a data format and various processing models: Media types define both a data format and various processing models:
how to process that data in accordance with each context in which it how to process that data in accordance with each context in which it
is received. is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
The type/subtype MAY be followed by parameters in the form of The type/subtype MAY be followed by parameters in the form of
name=value pairs. name=value pairs.
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
The type, subtype, and parameter name tokens are case-insensitive. The type, subtype, and parameter name tokens are case insensitive.
Parameter values might or might not be case-sensitive, depending on Parameter values might or might not be case sensitive, depending on
the semantics of the parameter name. The presence or absence of a the semantics of the parameter name. The presence or absence of a
parameter might be significant to the processing of a media-type, parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry. depending on its definition within the media type registry.
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted either as a token or within a quoted-string. The quoted transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. For example, the following and unquoted values are equivalent. For example, the following
examples are all equivalent, but the first is preferred for examples are all equivalent, but the first is preferred for
consistency: consistency:
skipping to change at page 9, line 32 skipping to change at page 9, line 32
around the "=" character. around the "=" character.
3.1.1.2. Charset 3.1.1.2. Charset
HTTP uses charset names to indicate or negotiate the character HTTP uses charset names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in the IANA Character Set Charset names ought to be registered in the IANA "Character Sets"
registry (<http://www.iana.org/assignments/character-sets>) according registry <http://www.iana.org/assignments/character-sets> according
to the procedures defined in [RFC2978]. to the procedures defined in [RFC2978].
3.1.1.3. Canonicalization and Text Defaults 3.1.1.3. Canonicalization and Text Defaults
Internet media types are registered with a canonical form in order to Internet media types are registered with a canonical form in order to
be interoperable among systems with varying native encoding formats. be interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in Representations selected or transferred via HTTP ought to be in
canonical form, for many of the same reasons described by the canonical form, for many of the same reasons described by the
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the
performance characteristics of email deployments (i.e., store and performance characteristics of email deployments (i.e., store and
forward messages to peers) are significantly different from those forward messages to peers) are significantly different from those
common to HTTP and the Web (server-based information services). common to HTTP and the Web (server-based information services).
Furthermore, MIME's constraints for the sake of compatibility with Furthermore, MIME's constraints for the sake of compatibility with
older mail transfer protocols do not apply to HTTP (see Appendix A). older mail transfer protocols do not apply to HTTP (see Appendix A).
MIME's canonical form requires that media subtypes of the "text" type MIME's canonical form requires that media subtypes of the "text" type
use CRLF as the text line break. HTTP allows the transfer of text use CRLF as the text line break. HTTP allows the transfer of text
media with plain CR or LF alone representing a line break, when such media with plain carriage return (CR) or line feed (LF) alone
line breaks are consistent for an entire representation. An HTTP representing a line break, when such line breaks are consistent for
sender MAY generate, and a recipient MUST be able to parse, line an entire representation. An HTTP sender MAY generate, and a
breaks in text media that consist of CRLF, bare CR, or bare LF. In recipient MUST be able to parse, line breaks in text media that
addition, text media in HTTP is not limited to charsets that use consist of CRLF, bare CR, or bare LF. In addition, text media in
octets 13 and 10 for CR and LF, respectively. This flexibility HTTP is not limited to charsets that use octets 13 and 10 for CR and
regarding line breaks applies only to text within a representation LF, respectively. This flexibility regarding line breaks applies
that has been assigned a "text" media type; it does not apply to only to text within a representation that has been assigned a "text"
"multipart" types or HTTP elements outside the payload body (e.g., media type; it does not apply to "multipart" types or HTTP elements
header fields). outside the payload body (e.g., header fields).
If a representation is encoded with a content-coding, the underlying If a representation is encoded with a content-coding, the underlying
data ought to be in a form defined above prior to being encoded. data ought to be in a form defined above prior to being encoded.
3.1.1.4. Multipart Types 3.1.1.4. Multipart Types
MIME provides for a number of "multipart" types -- encapsulations of MIME provides for a number of "multipart" types -- encapsulations of
one or more representations within a single message body. All one or more representations within a single message body. All
multipart types share a common syntax, as defined in Section 5.1.1 of multipart types share a common syntax, as defined in Section 5.1.1 of
[RFC2046], and include a boundary parameter as part of the media type [RFC2046], and include a boundary parameter as part of the media type
skipping to change at page 11, line 35 skipping to change at page 11, line 35
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
been or can be applied to a representation. Content codings are been or can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or primarily used to allow a representation to be compressed or
otherwise usefully transformed without losing the identity of its otherwise usefully transformed without losing the identity of its
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
content-coding = token content-coding = token
All content-coding values are case-insensitive and ought to be All content-coding values are case insensitive and ought to be
registered within the HTTP Content Coding registry, as defined in registered within the "HTTP Content Coding Registry", as defined in
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) Section 8.4. They are used in the Accept-Encoding (Section 5.3.4)
and Content-Encoding (Section 3.1.2.2) header fields. and Content-Encoding (Section 3.1.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
compress (and x-compress): See Section 4.2.1 of [RFC7230]. compress (and x-compress): See Section 4.2.1 of [RFC7230].
deflate: See Section 4.2.2 of [RFC7230]. deflate: See Section 4.2.2 of [RFC7230].
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Content-Language is to allow a user to identify and differentiate Content-Language is to allow a user to identify and differentiate
representations according to the users' own preferred language. representations according to the users' own preferred language.
Thus, if the content is intended only for a Danish-literate audience, Thus, if the content is intended only for a Danish-literate audience,
the appropriate field is the appropriate field is
Content-Language: da Content-Language: da
If no Content-Language is specified, the default is that the content If no Content-Language is specified, the default is that the content
is intended for all language audiences. This might mean that the is intended for all language audiences. This might mean that the
sender does not consider it to be specific to any natural language, sender does not consider it to be specific to any natural language,
or that the sender does not know for which language it is intended. or that the sender does not know which language is being used.
Multiple languages MAY be listed for content that is intended for Multiple languages MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of multiple audiences. For example, a rendition of the "Treaty of
Waitangi", presented simultaneously in the original Maori and English Waitangi", presented simultaneously in the original Maori and English
versions, would call for versions, would call for
Content-Language: mi, en Content-Language: mi, en
However, just because multiple languages are present within a However, just because multiple languages are present within a
representation does not mean that it is intended for multiple representation does not mean that it is intended for multiple
skipping to change at page 19, line 21 skipping to change at page 19, line 21
representations for a response (the dimensions over which it might representations for a response (the dimensions over which it might
vary, such as language, content-coding, etc.) compared to various vary, such as language, content-coding, etc.) compared to various
information supplied in the request, including both the explicit information supplied in the request, including both the explicit
negotiation fields of Section 5.3 and implicit characteristics, such negotiation fields of Section 5.3 and implicit characteristics, such
as the client's network address or parts of the User-Agent field. as the client's network address or parts of the User-Agent field.
Proactive negotiation is advantageous when the algorithm for Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to selecting from among the available representations is difficult to
describe to a user agent, or when the server desires to send its describe to a user agent, or when the server desires to send its
"best guess" to the user agent along with the first response (hoping "best guess" to the user agent along with the first response (hoping
to avoid the round trip delay of a subsequent request if the "best to avoid the round-trip delay of a subsequent request if the "best
guess" is good enough for the user). In order to improve the guess" is good enough for the user). In order to improve the
server's guess, a user agent MAY send request header fields that server's guess, a user agent MAY send request header fields that
describe its preferences. describe its preferences.
Proactive negotiation has serious disadvantages: Proactive negotiation has serious disadvantages:
o It is impossible for the server to accurately determine what might o It is impossible for the server to accurately determine what might
be "best" for any given user, since that would require complete be "best" for any given user, since that would require complete
knowledge of both the capabilities of the user agent and the knowledge of both the capabilities of the user agent and the
intended use for the response (e.g., does the user want to view it intended use for the response (e.g., does the user want to view it
skipping to change at page 20, line 37 skipping to change at page 20, line 37
A server might choose not to send an initial representation, other A server might choose not to send an initial representation, other
than the list of alternatives, and thereby indicate that reactive than the list of alternatives, and thereby indicate that reactive
negotiation by the user agent is preferred. For example, the negotiation by the user agent is preferred. For example, the
alternatives listed in responses with the 300 (Multiple Choices) and alternatives listed in responses with the 300 (Multiple Choices) and
406 (Not Acceptable) status codes include information about the 406 (Not Acceptable) status codes include information about the
available representations so that the user or user agent can react by available representations so that the user or user agent can react by
making a selection. making a selection.
Reactive negotiation is advantageous when the response would vary Reactive negotiation is advantageous when the response would vary
over commonly-used dimensions (such as type, language, or encoding), over commonly used dimensions (such as type, language, or encoding),
when the origin server is unable to determine a user agent's when the origin server is unable to determine a user agent's
capabilities from examining the request, and generally when public capabilities from examining the request, and generally when public
caches are used to distribute server load and reduce network usage. caches are used to distribute server load and reduce network usage.
Reactive negotiation suffers from the disadvantages of transmitting a Reactive negotiation suffers from the disadvantages of transmitting a
list of alternatives to the user agent, which degrades user-perceived list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second latency if transmitted in the header section, and needing a second
request to obtain an alternate representation. Furthermore, this request to obtain an alternate representation. Furthermore, this
specification does not define a mechanism for supporting automatic specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being selection, though it does not prevent such a mechanism from being
skipping to change at page 21, line 26 skipping to change at page 21, line 26
example, a client can send conditional request header fields example, a client can send conditional request header fields
(Section 5.2) to make the requested action conditional on the current (Section 5.2) to make the requested action conditional on the current
state of the target resource ([RFC7232]). state of the target resource ([RFC7232]).
method = token method = token
HTTP was originally designed to be usable as an interface to HTTP was originally designed to be usable as an interface to
distributed object systems. The request method was envisioned as distributed object systems. The request method was envisioned as
applying semantics to a target resource in much the same way as applying semantics to a target resource in much the same way as
invoking a defined method on an identified object would apply invoking a defined method on an identified object would apply
semantics. The method token is case-sensitive because it might be semantics. The method token is case sensitive because it might be
used as a gateway to object-based systems with case-sensitive method used as a gateway to object-based systems with case-sensitive method
names. names.
Unlike distributed objects, the standardized request methods in HTTP Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for are not resource specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. By commonly used in HTTP, as outlined by the following table. By
convention, standardized methods are defined in all-uppercase ASCII convention, standardized methods are defined in all-uppercase ASCII
letters. letters.
skipping to change at page 22, line 31 skipping to change at page 22, line 31
| | target resource. | | | | target resource. | |
| TRACE | Perform a message loop-back test along the path | 4.3.8 | | TRACE | Perform a message loop-back test along the path | 4.3.8 |
| | to the target resource. | | | | to the target resource. | |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
All general-purpose servers MUST support the methods GET and HEAD. All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL. All other methods are OPTIONAL.
Additional methods, outside the scope of this specification, have Additional methods, outside the scope of this specification, have
been standardized for use in HTTP. All such methods ought to be been standardized for use in HTTP. All such methods ought to be
registered within the HTTP Method Registry maintained by IANA, as registered within the "Hypertext Transfer Protocol (HTTP) Method"
defined in Section 8.1. registry maintained by IANA, as defined in Section 8.1.
The set of methods allowed by a target resource can be listed in an The set of methods allowed by a target resource can be listed in an
Allow header field (Section 7.4.1). However, the set of allowed Allow header field (Section 7.4.1). However, the set of allowed
methods can change dynamically. When a request method is received methods can change dynamically. When a request method is received
that is unrecognized or not implemented by an origin server, the that is unrecognized or not implemented by an origin server, the
origin server SHOULD respond with the 501 (Not Implemented) status origin server SHOULD respond with the 501 (Not Implemented) status
code. When a request method is received that is known by an origin code. When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server server but not allowed for the target resource, the origin server
SHOULD respond with the 405 (Method Not Allowed) status code. SHOULD respond with the 405 (Method Not Allowed) status code.
skipping to change at page 23, line 5 skipping to change at page 23, line 5
4.2.1. Safe Methods 4.2.1. Safe Methods
Request methods are considered "safe" if their defined semantics are Request methods are considered "safe" if their defined semantics are
essentially read-only; i.e., the client does not request, and does essentially read-only; i.e., the client does not request, and does
not expect, any state change on the origin server as a result of not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
This definition of safe methods does not prevent an implementation This definition of safe method does not prevent an implementation
from including behavior that is potentially harmful, not entirely from including behavior that is potentially harmful, that is not
read-only, or which causes side-effects while invoking a safe method. entirely read-only, or that causes side effects while invoking a safe
What is important, however, is that the client did not request that method. What is important, however, is that the client did not
additional behavior and cannot be held accountable for it. For request that additional behavior and cannot be held accountable for
example, most servers append request information to access log files it. For example, most servers append request information to access
at the completion of every response, regardless of the method, and log files at the completion of every response, regardless of the
that is considered safe even though the log storage might become full method, and that is considered safe even though the log storage might
and crash the server. Likewise, a safe request initiated by become full and crash the server. Likewise, a safe request initiated
selecting an advertisement on the Web will often have the side-effect by selecting an advertisement on the Web will often have the side
of charging an advertising account. effect of charging an advertising account.
Of the request methods defined by this specification, the GET, HEAD, Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe. OPTIONS, and TRACE methods are defined to be safe.
The purpose of distinguishing between safe and unsafe methods is to The purpose of distinguishing between safe and unsafe methods is to
allow automated retrieval processes (spiders) and cache performance allow automated retrieval processes (spiders) and cache performance
optimization (pre-fetching) to work without fear of causing harm. In optimization (pre-fetching) to work without fear of causing harm. In
addition, it allows a user agent to apply appropriate constraints on addition, it allows a user agent to apply appropriate constraints on
the automated use of unsafe methods when processing potentially the automated use of unsafe methods when processing potentially
untrusted content. untrusted content.
skipping to change at page 23, line 39 skipping to change at page 23, line 39
made aware of an unsafe action before it is requested. made aware of an unsafe action before it is requested.
When a resource is constructed such that parameters within the When a resource is constructed such that parameters within the
effective request URI have the effect of selecting an action, it is effective request URI have the effect of selecting an action, it is
the resource owner's responsibility to ensure that the action is the resource owner's responsibility to ensure that the action is
consistent with the request method semantics. For example, it is consistent with the request method semantics. For example, it is
common for Web-based content editing software to use actions within common for Web-based content editing software to use actions within
query parameters, such as "page?do=delete". If the purpose of such a query parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side- request method. Failure to do so will result in unfortunate side
effects when automated processes perform a GET on every URI reference effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search for the sake of link maintenance, pre-fetching, building a search
index, etc. index, etc.
4.2.2. Idempotent Methods 4.2.2. Idempotent Methods
A request method is considered "idempotent" if the intended effect on A request method is considered "idempotent" if the intended effect on
the server of multiple identical requests with that method is the the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods defined by this specification, PUT, DELETE, and safe request methods
are idempotent. are idempotent.
Like the definition of safe, the idempotent property only applies to Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement request separately, retain a revision control history, or implement
other non-idempotent side-effects for each idempotent request. other non-idempotent side effects for each idempotent request.
Idempotent methods are distinguished because the request can be Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the repeated automatically if a communication failure occurs before the
client is able to read the server's response. For example, if a client is able to read the server's response. For example, if a
client sends a PUT request and the underlying connection is closed client sends a PUT request and the underlying connection is closed
before any response is received, then the client can establish a new before any response is received, then the client can establish a new
connection and retry the idempotent request. It knows that repeating connection and retry the idempotent request. It knows that repeating
the request will have the same intended effect, even if the original the request will have the same intended effect, even if the original
request succeeded, though the response might differ. request succeeded, though the response might differ.
skipping to change at page 26, line 14 skipping to change at page 26, line 14
o Creating a new resource that has yet to be identified by the o Creating a new resource that has yet to be identified by the
origin server; and origin server; and
o Appending data to a resource's existing representation(s). o Appending data to a resource's existing representation(s).
An origin server indicates response semantics by choosing an An origin server indicates response semantics by choosing an
appropriate status code depending on the result of processing the appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this POST request; almost all of the status codes defined by this
specification might be received in a response to POST (the exceptions specification might be received in a response to POST (the exceptions
being 206, 304, and 416). being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
Satisfiable)).
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 7.1.2) and a representation that describes the status of the (Section 7.1.2) and a representation that describes the status of the
request while referring to the new resource(s). request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [RFC7234]). explicit freshness information (see Section 4.2.1 of [RFC7234]).
skipping to change at page 28, line 43 skipping to change at page 28, line 44
knows which target resource is desired. A service that selects a knows which target resource is desired. A service that selects a
proper URI on behalf of the client, after receiving a state-changing proper URI on behalf of the client, after receiving a state-changing
request, SHOULD be implemented using the POST method rather than PUT. request, SHOULD be implemented using the POST method rather than PUT.
If the origin server will not make the requested PUT state change to If the origin server will not make the requested PUT state change to
the target resource and instead wishes to have it applied to a the target resource and instead wishes to have it applied to a
different resource, such as when the resource has been moved to a different resource, such as when the resource has been moved to a
different URI, then the origin server MUST send an appropriate 3xx different URI, then the origin server MUST send an appropriate 3xx
(Redirection) response; the user agent MAY then make its own decision (Redirection) response; the user agent MAY then make its own decision
regarding whether or not to redirect the request. regarding whether or not to redirect the request.
A PUT request applied to the target resource can have side-effects on A PUT request applied to the target resource can have side effects on
other resources. For example, an article might have a URI for other resources. For example, an article might have a URI for
identifying "the current version" (a resource) that is separate from identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources the URIs identifying each particular version (different resources
that at one point shared the same state as the current version that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be the state of the target resource, and might also cause links to be
added between the related resources. added between the related resources.
An origin server that allows PUT on a given target resource MUST send An origin server that allows PUT on a given target resource MUST send
skipping to change at page 30, line 31 skipping to change at page 30, line 33
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target and, the destination origin server identified by the request-target and,
if successful, thereafter restrict its behavior to blind forwarding if successful, thereafter restrict its behavior to blind forwarding
of packets, in both directions, until the tunnel is closed. Tunnels of packets, in both directions, until the tunnel is closed. Tunnels
are commonly used to create an end-to-end virtual connection, through are commonly used to create an end-to-end virtual connection, through
one or more proxies, which can then be secured using TLS (Transport one or more proxies, which can then be secured using TLS (Transport
Layer Security, [RFC5246]). Layer Security, [RFC5246]).
CONNECT is intended only for use in requests to a proxy. An origin CONNECT is intended only for use in requests to a proxy. An origin
server that receives a CONNECT request for itself MAY respond with a server that receives a CONNECT request for itself MAY respond with a
2xx status code to indicate that a connection is established. 2xx (Successful) status code to indicate that a connection is
However, most origin servers do not implement CONNECT. established. However, most origin servers do not implement CONNECT.
A client sending a CONNECT request MUST send the authority form of A client sending a CONNECT request MUST send the authority form of
request-target (Section 5.3 of [RFC7230]); i.e., the request-target request-target (Section 5.3 of [RFC7230]); i.e., the request-target
consists of only the host name and port number of the tunnel consists of only the host name and port number of the tunnel
destination, separated by a colon. For example, destination, separated by a colon. For example,
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80 Host: server.example.com:80
The recipient proxy can establish a tunnel either by directly The recipient proxy can establish a tunnel either by directly
skipping to change at page 34, line 14 skipping to change at page 34, line 14
5.1.1. Expect 5.1.1. Expect
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation order to properly handle this request. The only such expectation
defined by this specification is 100-continue. defined by this specification is 100-continue.
Expect = "100-continue" Expect = "100-continue"
The Expect field-value is case-insensitive. The Expect field-value is case insensitive.
A server that receives an Expect field-value other than 100-continue A server that receives an Expect field-value other than 100-continue
MAY respond with a 417 (Expectation Failed) status code to indicate MAY respond with a 417 (Expectation Failed) status code to indicate
that the unexpected expectation cannot be met. that the unexpected expectation cannot be met.
A 100-continue expectation informs recipients that the client is A 100-continue expectation informs recipients that the client is
about to send a (presumably large) message body in this request and about to send a (presumably large) message body in this request and
wishes to receive a 100 (Continue) interim response if the request- wishes to receive a 100 (Continue) interim response if the request-
line and header fields are not sufficient to cause an immediate line and header fields are not sufficient to cause an immediate
success, redirect, or error response. This allows the client to wait success, redirect, or error response. This allows the client to wait
skipping to change at page 36, line 12 skipping to change at page 36, line 12
determined by examining just the request-line and header fields, or determined by examining just the request-line and header fields, or
begin forwarding the request toward the origin server by sending a begin forwarding the request toward the origin server by sending a
corresponding request-line and header section to the next inbound corresponding request-line and header section to the next inbound
server. If the proxy believes (from configuration or past server. If the proxy believes (from configuration or past
interaction) that the next inbound server only supports HTTP/1.0, the interaction) that the next inbound server only supports HTTP/1.0, the
proxy MAY generate an immediate 100 (Continue) response to encourage proxy MAY generate an immediate 100 (Continue) response to encourage
the client to begin sending the message body. the client to begin sending the message body.
Note: The Expect header field was added after the original Note: The Expect header field was added after the original
publication of HTTP/1.1 [RFC2068] as both the means to request an publication of HTTP/1.1 [RFC2068] as both the means to request an
interim 100 response and the general mechanism for indicating interim 100 (Continue) response and the general mechanism for
must-understand extensions. However, the extension mechanism has indicating must-understand extensions. However, the extension
not been used by clients and the must-understand requirements have mechanism has not been used by clients and the must-understand
not been implemented by many servers, rendering the extension requirements have not been implemented by many servers, rendering
mechanism useless. This specification has removed the extension the extension mechanism useless. This specification has removed
mechanism in order to simplify the definition and processing of the extension mechanism in order to simplify the definition and
100-continue. processing of 100-continue.
5.1.2. Max-Forwards 5.1.2. Max-Forwards
The "Max-Forwards" header field provides a mechanism with the TRACE The "Max-Forwards" header field provides a mechanism with the TRACE
(Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit
the number of times that the request is forwarded by proxies. This the number of times that the request is forwarded by proxies. This
can be useful when the client is attempting to trace a request that can be useful when the client is attempting to trace a request that
appears to be failing or looping mid-chain. appears to be failing or looping mid-chain.
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
skipping to change at page 39, line 12 skipping to change at page 39, line 12
to be unlikely given the lack of any "q" parameters in the IANA to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type media type registry and the rare usage of any media type
parameters in Accept. Future media types are discouraged from parameters in Accept. Future media types are discouraged from
registering any parameter named "q". registering any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% mark-down in quality". if it is the best available after an 80% markdown in quality".
A request without any Accept header field implies that the user agent A request without any Accept header field implies that the user agent
will accept any media type in response. If the header field is will accept any media type in response. If the header field is
present in a request and none of the available representations for present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the the response have a media type that is listed as acceptable, the
origin server can either honor the header field by sending a 406 (Not origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation. response as if it is not subject to content negotiation.
A more elaborate example is A more elaborate example is
skipping to change at page 44, line 30 skipping to change at page 44, line 30
+-------------------+---------------+ +-------------------+---------------+
| From | Section 5.5.1 | | From | Section 5.5.1 |
| Referer | Section 5.5.2 | | Referer | Section 5.5.2 |
| User-Agent | Section 5.5.3 | | User-Agent | Section 5.5.3 |
+-------------------+---------------+ +-------------------+---------------+
5.5.1. From 5.5.1. From
The "From" header field contains an Internet email address for a The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
An example is: An example is:
From: webmaster@example.org From: webmaster@example.org
skipping to change at page 45, line 31 skipping to change at page 45, line 31
denying links from other sites (so-called "deep linking") or denying links from other sites (so-called "deep linking") or
restricting cross-site request forgery (CSRF), but not all requests restricting cross-site request forgery (CSRF), but not all requests
contain it. contain it.
Example: Example:
Referer: http://www.example.org/hypertext/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the target URI was obtained from a source that does not have its If the target URI was obtained from a source that does not have its
own URI (e.g., input from the user keyboard, or an entry within the own URI (e.g., input from the user keyboard, or an entry within the
user's bookmarks/favorites), the user agent MUST either exclude user's bookmarks/favorites), the user agent MUST either exclude the
Referer or send it with a value of "about:blank". Referer or send it with a value of "about:blank".
The Referer field has the potential to reveal information about the The Referer field has the potential to reveal information about the
request context or browsing history of the user, which is a privacy request context or browsing history of the user, which is a privacy
concern if the referring resource's identifier reveals personal concern if the referring resource's identifier reveals personal
information (such as an account name) or a resource that is supposed information (such as an account name) or a resource that is supposed
to be confidential (such as behind a firewall or internal to a to be confidential (such as behind a firewall or internal to a
secured service). Most general-purpose user agents do not send the secured service). Most general-purpose user agents do not send the
Referer header field when the referring resource is a local "file" or Referer header field when the referring resource is a local "file" or
"data" URI. A user agent MUST NOT send a Referer header field in an "data" URI. A user agent MUST NOT send a Referer header field in an
unsecured HTTP request if the referring page was received with a unsecured HTTP request if the referring page was received with a
secure protocol. See Section 9.4 for additional security secure protocol. See Section 9.4 for additional security
considerations. considerations.
Some intermediaries have been known to indiscriminately remove Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the Referer header fields from outgoing requests. This has the
unfortunate side-effect of interfering with protection against CSRF unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users. attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An pseudonyms or truncating the query and/or path components. An
intermediary SHOULD NOT modify or delete the Referer header field intermediary SHOULD NOT modify or delete the Referer header field
when the field value shares the same scheme and host as the request when the field value shares the same scheme and host as the request
target. target.
5.5.3. User-Agent 5.5.3. User-Agent
The "User-Agent" header field contains information about the user The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help agent originating the request, which is often used by servers to help
identify the scope of reported interoperability problems, to work identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent around or tailor responses to avoid particular user-agent
limitations, and for analytics regarding browser or operating system limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so. unless specifically configured not to do so.
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
The User-Agent field-value consists of one or more product The User-Agent field-value consists of one or more product
identifiers, each followed by zero or more comments (Section 3.2 of identifiers, each followed by zero or more comments (Section 3.2 of
[RFC7230]), which together identify the user agent software and its [RFC7230]), which together identify the user-agent software and its
significant subproducts. By convention, the product identifiers are significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the listed in decreasing order of their significance for identifying the
user agent software. Each product identifier consists of a name and user-agent software. Each product identifier consists of a name and
optional version. optional version.
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
A sender SHOULD limit generated product identifiers to what is A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate necessary to identify the product; a sender MUST NOT generate
advertising or other non-essential information within the product advertising or other nonessential information within the product
identifier. A sender SHOULD NOT generate information in product- identifier. A sender SHOULD NOT generate information in product-
version that is not a version identifier (i.e., successive versions version that is not a version identifier (i.e., successive versions
of the same product name ought only to differ in the product-version of the same product name ought only to differ in the product-version
portion of the product identifier). portion of the product identifier).
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent field containing A user agent SHOULD NOT generate a User-Agent field containing
skipping to change at page 47, line 9 skipping to change at page 47, line 9
subproducts by third parties. Overly long and detailed User-Agent subproducts by third parties. Overly long and detailed User-Agent
field values increase request latency and the risk of a user being field values increase request latency and the risk of a user being
identified against their wishes ("fingerprinting"). identified against their wishes ("fingerprinting").
Likewise, implementations are encouraged not to use the product Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a user with them, as this circumvents the purpose of the field. If a user
agent masquerades as a different user agent, recipients can assume agent masquerades as a different user agent, recipients can assume
that the user intentionally desires to see responses tailored for that the user intentionally desires to see responses tailored for
that identified user agent, even if they might not work as well for that identified user agent, even if they might not work as well for
the actual user agent being used. the actual user agent being implemented.
6. Response Status Codes 6. Response Status Codes
The status-code element is a three-digit integer code giving the The status-code element is a three-digit integer code giving the
result of the attempt to understand and satisfy the request. result of the attempt to understand and satisfy the request.
HTTP status codes are extensible. HTTP clients are not required to HTTP status codes are extensible. HTTP clients are not required to
understand the meaning of all registered status codes, though such understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code. recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 status request and treat the response as if it had received a 400 (Bad
code. The response message will usually contain a representation Request) status code. The response message will usually contain a
that explains the status. representation that explains the status.
The first digit of the status-code defines the class of response. The first digit of the status-code defines the class of response.
The last two digits do not have any categorization role. There are The last two digits do not have any categorization role. There are
five values for the first digit: five values for the first digit:
o 1xx (Informational): The request was received, continuing process o 1xx (Informational): The request was received, continuing process
o 2xx (Successful): The request was successfully received, o 2xx (Successful): The request was successfully received,
understood, and accepted understood, and accepted
skipping to change at page 48, line 14 skipping to change at page 48, line 14
6.1. Overview of Status Codes 6.1. Overview of Status Codes
The status codes listed below are defined in this specification, The status codes listed below are defined in this specification,
Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of
[RFC7235]. The reason phrases listed here are only recommendations [RFC7235]. The reason phrases listed here are only recommendations
-- they can be replaced by local equivalents without affecting the -- they can be replaced by local equivalents without affecting the
protocol. protocol.
Responses with status codes that are defined as cacheable by default Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
specification) can be reused by a cache with heuristic expiration this specification) can be reused by a cache with heuristic
unless otherwise indicated by the method definition or explicit cache expiration unless otherwise indicated by the method definition or
controls [RFC7234]; all other status codes are not cacheable by explicit cache controls [RFC7234]; all other status codes are not
default. cacheable by default.
+------+-------------------------------+--------------------------+ +------+-------------------------------+--------------------------+
| Code | Reason-Phrase | Defined in... | | Code | Reason-Phrase | Defined in... |
+------+-------------------------------+--------------------------+ +------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 | | 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 | | 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 | | 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 | | 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 | | 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 | | 203 | Non-Authoritative Information | Section 6.3.4 |
skipping to change at page 52, line 27 skipping to change at page 52, line 27
6.3.3. 202 Accepted 6.3.3. 202 Accepted
The 202 (Accepted) status code indicates that the request has been The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
operation. operation.
The 202 response is intentionally non-committal. Its purpose is to The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
6.3.4. 203 Non-Authoritative Information 6.3.4. 203 Non-Authoritative Information
skipping to change at page 56, line 6 skipping to change at page 56, line 6
this specification because HTTP tries to remain orthogonal to the this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format. negotiation, or in some commonly accepted hypertext format.
A 300 response is cacheable by default; i.e., unless otherwise A 300 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [RFC7234]).
Note: The original proposal for 300 defined the URI header field Note: The original proposal for the 300 response defined the URI
as providing a list of alternative representations, such that it header field as providing a list of alternative representations,
would be usable for 200, 300, and 406 responses and be transferred such that it would be usable for 200, 300, and 406 responses and
in responses to the HEAD method. However, lack of deployment and be transferred in responses to the HEAD method. However, lack of
disagreement over syntax led to both URI and Alternates (a deployment and disagreement over syntax led to both URI and
subsequent proposal) being dropped from this specification. It is Alternates (a subsequent proposal) being dropped from this
possible to communicate the list using a set of Link header fields specification. It is possible to communicate the list using a set
[RFC5988], each with a relationship of "alternate", though of Link header fields [RFC5988], each with a relationship of
deployment is a chicken-and-egg problem. "alternate", though deployment is a chicken-and-egg problem.
6.4.2. 301 Moved Permanently 6.4.2. 301 Moved Permanently
The 301 (Moved Permanently) status code indicates that the target The 301 (Moved Permanently) status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new references to the effective request URI to one or more of the new
references sent by the server, where possible. references sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
Note: For historical reasons, a user agent MAY change the request Note: For historical reasons, a user agent MAY change the request
skipping to change at page 58, line 23 skipping to change at page 58, line 23
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a response payload usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
Note: This status code is similar to 302 (Found), except that it Note: This status code is similar to 302 (Found), except that it
does not allow changing the request method from POST to GET. This does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved specification defines no equivalent counterpart for 301 (Moved
Permanently) ([RFC7238], however, defines the status code 308 Permanently) ([RFC7238]; however, it defines the status code 308
(Permanent Redirect) for this purpose). (Permanent Redirect) for this purpose).
6.5. Client Error 4xx 6.5. Client Error 4xx
The 4xx (Client Error) class of status code indicates that the client The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method. condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user. User agents SHOULD display any included representation to the user.
skipping to change at page 66, line 9 skipping to change at page 66, line 9
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC. A sender that generates HTTP-date values from a local
clock ought to use NTP ([RFC5905]) or some similar protocol to clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format ; fixed length/zone/capitalization subset of the format
; defined in Section 3.3 of [RFC5322] ; defined in Section 3.3 of [RFC5322]
day-name = %x4D.6F.6E ; "Mon", case-sensitive day-name = %x4D.6F.6E ; "Mon", case sensitive
/ %x54.75.65 ; "Tue", case-sensitive / %x54.75.65 ; "Tue", case sensitive
/ %x57.65.64 ; "Wed", case-sensitive / %x57.65.64 ; "Wed", case sensitive
/ %x54.68.75 ; "Thu", case-sensitive / %x54.68.75 ; "Thu", case sensitive
/ %x46.72.69 ; "Fri", case-sensitive / %x46.72.69 ; "Fri", case sensitive
/ %x53.61.74 ; "Sat", case-sensitive / %x53.61.74 ; "Sat", case sensitive
/ %x53.75.6E ; "Sun", case-sensitive / %x53.75.6E ; "Sun", case sensitive
date1 = day SP month SP year date1 = day SP month SP year
; e.g., 02 Jun 1982 ; e.g., 02 Jun 1982
day = 2DIGIT day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive month = %x4A.61.6E ; "Jan", case sensitive
/ %x46.65.62 ; "Feb", case-sensitive / %x46.65.62 ; "Feb", case sensitive
/ %x4D.61.72 ; "Mar", case-sensitive / %x4D.61.72 ; "Mar", case sensitive
/ %x41.70.72 ; "Apr", case-sensitive / %x41.70.72 ; "Apr", case sensitive
/ %x4D.61.79 ; "May", case-sensitive / %x4D.61.79 ; "May", case sensitive
/ %x4A.75.6E ; "Jun", case-sensitive / %x4A.75.6E ; "Jun", case sensitive
/ %x4A.75.6C ; "Jul", case-sensitive / %x4A.75.6C ; "Jul", case sensitive
/ %x41.75.67 ; "Aug", case-sensitive / %x41.75.67 ; "Aug", case sensitive
/ %x53.65.70 ; "Sep", case-sensitive / %x53.65.70 ; "Sep", case sensitive
/ %x4F.63.74 ; "Oct", case-sensitive / %x4F.63.74 ; "Oct", case sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive / %x4E.6F.76 ; "Nov", case sensitive
/ %x44.65.63 ; "Dec", case-sensitive / %x44.65.63 ; "Dec", case sensitive
year = 4DIGIT year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive GMT = %x47.4D.54 ; "GMT", case sensitive
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second) ; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
Obsolete formats: Obsolete formats:
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
; e.g., 02-Jun-82 ; e.g., 02-Jun-82
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive / %x54.75.65.73.64.61.79 ; "Tuesday", case sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive / %x54.68.75.72.73.64.61.79 ; "Thursday", case sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive / %x46.72.69.64.61.79 ; "Friday", case sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive / %x53.61.74.75.72.64.61.79 ; "Saturday", case sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive / %x53.75.6E.64.61.79 ; "Sunday", case sensitive
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2 ; e.g., Jun 2
HTTP-date is case sensitive. A sender MUST NOT generate additional HTTP-date is case sensitive. A sender MUST NOT generate additional
whitespace in an HTTP-date beyond that specifically included as SP in whitespace in an HTTP-date beyond that specifically included as SP in
the grammar. The semantics of day-name, day, month, year, and time- the grammar. The semantics of day-name, day, month, year, and time-
of-day are the same as those defined for the Internet Message Format of-day are the same as those defined for the Internet Message Format
constructs with the corresponding name ([RFC5322], Section 3.3). constructs with the corresponding name ([RFC5322], Section 3.3).
skipping to change at page 70, line 30 skipping to change at page 70, line 30
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
7.1.4. Vary 7.1.4. Vary
The "Vary" header field in a response describes what parts of a The "Vary" header field in a response describes what parts of a
request message, aside from the method, Host header field, and request message, aside from the method, Host header field, and
request target, might influence the origin server's process for request target, might influence the origin server's process for
selecting and representing this response. The value consists of selecting and representing this response. The value consists of
either a single asterisk ("*") or a list of header field names (case- either a single asterisk ("*") or a list of header field names (case
insensitive). insensitive).
Vary = "*" / 1#field-name Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request A Vary field value of "*" signals that anything about the request
might play a role in selecting the response representation, possibly might play a role in selecting the response representation, possibly
including elements outside the message syntax (e.g., the client's including elements outside the message syntax (e.g., the client's
network address). A recipient will not be able to determine whether network address). A recipient will not be able to determine whether
this response is appropriate for a later request without forwarding this response is appropriate for a later request without forwarding
the request to the origin server. A proxy MUST NOT generate a Vary the request to the origin server. A proxy MUST NOT generate a Vary
skipping to change at page 71, line 22 skipping to change at page 71, line 22
An origin server might send Vary with a list of fields for two An origin server might send Vary with a list of fields for two
purposes: purposes:
1. To inform cache recipients that they MUST NOT use this response 1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same to satisfy a later request unless the later request has the same
values for the listed fields as the original request (Section 4.1 values for the listed fields as the original request (Section 4.1
of [RFC7234]). In other words, Vary expands the cache key of [RFC7234]). In other words, Vary expands the cache key
required to match a new request to the stored cache entry. required to match a new request to the stored cache entry.
2. To inform user agent recipients that this response is subject to 2. To inform user-agent recipients that this response is subject to
content negotiation (Section 5.3) and that a different content negotiation (Section 5.3) and that a different
representation might be sent in a subsequent request if representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields additional parameters are provided in the listed header fields
(proactive negotiation). (proactive negotiation).
An origin server SHOULD send a Vary header field when its algorithm An origin server SHOULD send a Vary header field when its algorithm
for selecting a representation varies based on aspects of the request for selecting a representation varies based on aspects of the request
message other than the method and request target, unless the variance message other than the method and request target, unless the variance
cannot be crossed or the origin server has been deliberately cannot be crossed or the origin server has been deliberately
configured to prevent cache transparency. For example, there is no configured to prevent cache transparency. For example, there is no
skipping to change at page 72, line 5 skipping to change at page 72, line 5
fields describe the selected representation chosen by the origin fields describe the selected representation chosen by the origin
server while handling the response. Note that, depending on the server while handling the response. Note that, depending on the
status code semantics, the selected representation for a given status code semantics, the selected representation for a given
response is not necessarily the same as the representation enclosed response is not necessarily the same as the representation enclosed
as response payload. as response payload.
In a successful response to a state-changing request, validator In a successful response to a state-changing request, validator
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
For example, an ETag header field in a 201 response communicates the For example, an ETag header field in a 201 (Created) response
entity-tag of the newly created resource's representation, so that it communicates the entity-tag of the newly created resource's
can be used in later conditional requests to prevent the "lost representation, so that it can be used in later conditional requests
update" problem [RFC7232]. to prevent the "lost update" problem [RFC7232].
+-------------------+--------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+--------------------------+
| ETag | Section 2.3 of [RFC7232] | | ETag | Section 2.3 of [RFC7232] |
| Last-Modified | Section 2.2 of [RFC7232] | | Last-Modified | Section 2.2 of [RFC7232] |
+-------------------+--------------------------+ +-------------------+--------------------------+
7.3. Authentication Challenges 7.3. Authentication Challenges
skipping to change at page 74, line 6 skipping to change at page 74, line 6
An origin server SHOULD NOT generate a Server field containing An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed Server field subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes. attackers to find and exploit known security holes.
8. IANA Considerations 8. IANA Considerations
8.1. Method Registry 8.1. Method Registry
The HTTP Method Registry defines the name space for the request The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
method token (Section 4). The method registry will be created and namespace for the request method token (Section 4). The "HTTP Method
maintained at (the suggested URI) Registry" has been created and is now maintained at
<http://www.iana.org/assignments/http-methods>. <http://www.iana.org/assignments/http-methods>.
8.1.1. Procedure 8.1.1. Procedure
HTTP method registrations MUST include the following fields: HTTP method registrations MUST include the following fields:
o Method Name (see Section 4) o Method Name (see Section 4)
o Safe ("yes" or "no", see Section 4.2.1) o Safe ("yes" or "no", see Section 4.2.1)
o Idempotent ("yes" or "no", see Section 4.2.2) o Idempotent ("yes" or "no", see Section 4.2.2)
o Pointer to specification text o Pointer to specification text
Values to be added to this name space require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC5226], Section 4.1). [RFC5226], Section 4.1).
8.1.2. Considerations for New Methods 8.1.2. Considerations for New Methods
Standardized methods are generic; that is, they are potentially Standardized methods are generic; that is, they are potentially
applicable to any resource, not just one particular media type, kind applicable to any resource, not just one particular media type, kind
of resource, or application. As such, it is preferred that new of resource, or application. As such, it is preferred that new
methods be registered in a document that isn't specific to a single methods be registered in a document that isn't specific to a single
application or data format, since orthogonal technologies deserve application or data format, since orthogonal technologies deserve
orthogonal specification. orthogonal specification.
Since message parsing (Section 3.3 of [RFC7230]) needs to be Since message parsing (Section 3.3 of [RFC7230]) needs to be
independent of method semantics (aside from responses to HEAD), independent of method semantics (aside from responses to HEAD),
definitions of new methods cannot change the parsing algorithm or definitions of new methods cannot change the parsing algorithm or
prohibit the presence of a message body on either the request or the prohibit the presence of a message body on either the request or the
response message. Definitions of new methods can specify that only a response message. Definitions of new methods can specify that only a
zero-length message body is allowed by requiring a Content-Length zero-length message body is allowed by requiring a Content-Length
header field with a value of "0". header field with a value of "0".
A new method definition needs to indicate whether it is safe A new method definition needs to indicate whether it is safe
(Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
(Section 4.2.3), what semantics are to be associated with the payload (Section 4.2.3). It needs to indicate what semantics are to be
body if any is present in the request, and what refinements the associated with the payload body if any is present in the request and
method makes to header field or status code semantics. If the new what refinements the method makes to header field or status code
method is cacheable, its definition ought to describe how, and under semantics. If the new method is cacheable, its definition ought to
what conditions, a cache can store a response and use it to satisfy a describe how, and under what conditions, a cache can store a response
subsequent request. The new method ought to describe whether it can and use it to satisfy a subsequent request. The new method ought to
be made conditional (Section 5.2) and, if so, how a server responds describe whether it can be made conditional (Section 5.2) and, if so,
when the condition is false. Likewise, if the new method might have how a server responds when the condition is false. Likewise, if the
some use for partial response semantics ([RFC7233]), it ought to new method might have some use for partial response semantics
document this, too. ([RFC7233]), it ought to document this, too.
Note: Avoid defining a method name that starts with "M-", since Note: Avoid defining a method name that starts with "M-", since
that prefix might be misinterpreted as having the semantics that prefix might be misinterpreted as having the semantics
assigned to it by [RFC2774]. assigned to it by [RFC2774].
8.1.3. Registrations 8.1.3. Registrations
The HTTP Method Registry shall be populated with the registrations The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
below: populated with the registrations below:
+---------+------+------------+---------------+ +---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference | | Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+ +---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 | | CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 | | DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 | | GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 | | HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 | | OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 | | POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 | | PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 | | TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+ +---------+------+------------+---------------+
8.2. Status Code Registry 8.2. Status Code Registry
The HTTP Status Code Registry defines the name space for the response The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
status-code token (Section 6). The status code registry is the namespace for the response status-code token (Section 6). The
maintained at <http://www.iana.org/assignments/http-status-codes>. "HTTP Status Codes" registry is maintained at
<http://www.iana.org/assignments/http-status-codes>.
This section replaces the registration procedure for HTTP Status This section replaces the registration procedure for HTTP Status
Codes previously defined in Section 7.1 of [RFC2817]. Codes previously defined in Section 7.1 of [RFC2817].
8.2.1. Procedure 8.2.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Status Code (3 digits) o Status Code (3 digits)
o Short Description o Short Description
o Pointer to specification text o Pointer to specification text
Values to be added to the HTTP status code name space require IETF Values to be added to the HTTP status code namespace require IETF
Review (see [RFC5226], Section 4.1). Review (see [RFC5226], Section 4.1).
8.2.2. Considerations for New Status Codes 8.2.2. Considerations for New Status Codes
When it is necessary to express semantics for a response that are not When it is necessary to express semantics for a response that are not
defined by current status codes, a new status code can be registered. defined by current status codes, a new status code can be registered.
Status codes are generic; they are potentially applicable to any Status codes are generic; they are potentially applicable to any
resource, not just one particular media type, kind of resource, or resource, not just one particular media type, kind of resource, or
application of HTTP. As such, it is preferred that new status codes application of HTTP. As such, it is preferred that new status codes
be registered in a document that isn't specific to a single be registered in a document that isn't specific to a single
skipping to change at page 76, line 49 skipping to change at page 76, line 49
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
behavior. See [RFC7234] for more information. behavior. See [RFC7234] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the payload has any implied association with an identified whether the payload has any implied association with an identified
resource (Section 3.1.4.1). resource (Section 3.1.4.1).
8.2.3. Registrations 8.2.3. Registrations
The HTTP Status Code Registry shall be updated with the registrations The "HTTP Status Codes" registry has been updated with the
below: registrations below:
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
| 100 | Continue | Section 6.2.1 | | 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 | | 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 | | 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 | | 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 | | 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 | | 203 | Non-Authoritative Information | Section 6.3.4 |
skipping to change at page 77, line 48 skipping to change at page 77, line 48
| 500 | Internal Server Error | Section 6.6.1 | | 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 | | 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 | | 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 | | 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 | | 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 | | 505 | HTTP Version Not Supported | Section 6.6.6 |
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
8.3. Header Field Registry 8.3. Header Field Registry
HTTP header fields are registered within the Message Header Field HTTP header fields are registered within the "Message Headers"
Registry located at <http://www.iana.org/assignments/message-headers/ registry located at <http://www.iana.org/assignments/message-headers>
message-header-index.html>, as defined by [BCP90]. as defined by [BCP90].
8.3.1. Considerations for New Header Fields 8.3.1. Considerations for New Header Fields
Header fields are key:value pairs that can be used to communicate Header fields are key:value pairs that can be used to communicate
data about the message, its payload, the target resource, or the data about the message, its payload, the target resource, or the
connection (i.e., control data). See Section 3.2 of [RFC7230] for a connection (i.e., control data). See Section 3.2 of [RFC7230] for a
general definition of header field syntax in HTTP messages. general definition of header field syntax in HTTP messages.
The requirements for header field names are defined in [BCP90]. The requirements for header field names are defined in [BCP90].
Authors of specifications defining new fields are advised to keep the Authors of specifications defining new fields are advised to keep the
name as short as practical and not to prefix the name with "X-" name as short as practical and not to prefix the name with "X-"
unless the header field will never be used on the Internet. (The unless the header field will never be used on the Internet. (The
"X-" prefix idiom has been extensively misused in practice; it was "X-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered would ensure that private names never collide with a newly registered
Internet name; see [BCP178] for further information). Internet name; see [BCP178] for further information).
New header field values typically have their syntax defined using New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 7 of ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
[RFC7230] as necessary, and are usually constrained to the range of [RFC7230] as necessary), and they are usually constrained to the
ASCII characters. Header fields needing a greater range of range of ASCII characters. Header fields needing a greater range of
characters can use an encoding such as the one defined in [RFC5987]. characters can use an encoding such as the one defined in [RFC5987].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 3.2.4 of [RFC7230]). Field definitions where field parsing (Section 3.2.4 of [RFC7230]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string (Section 3.2.6 of use a container syntax such as quoted-string (Section 3.2.6 of
[RFC7230]). [RFC7230]).
Because commas (",") are used as a generic delimiter between field- Because commas (",") are used as a generic delimiter between field-
values, they need to be treated with care if they are allowed in the values, they need to be treated with care if they are allowed in the
skipping to change at page 80, line 15 skipping to change at page 80, line 15
o Whether the header field is useful or allowable in trailers (see o Whether the header field is useful or allowable in trailers (see
Section 4.1 of [RFC7230]). Section 4.1 of [RFC7230]).
o Whether the header field ought to be preserved across redirects. o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
8.3.2. Registrations 8.3.2. Registrations
The Message Header Field Registry shall be updated with the following The "Message Headers" registry has been updated with the following
permanent registrations: permanent registrations:
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 | | Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 | | Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 | | Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 | | Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 | | Allow | http | standard | Section 7.4.1 |
skipping to change at page 80, line 48 skipping to change at page 80, line 48
| Server | http | standard | Section 7.4.2 | | Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 | | User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 | | Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
The change controller for the above registrations is: "IETF The change controller for the above registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
8.4. Content Coding Registry 8.4. Content Coding Registry
The HTTP Content Coding Registry defines the name space for content The "HTTP Content Coding Registry" defines the namespace for content
coding names (Section 4.2 of [RFC7230]). The content coding registry coding names (Section 4.2 of [RFC7230]). The "HTTP Content Coding
is maintained at <http://www.iana.org/assignments/http-parameters>. Registry" is maintained at
<http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure 8.4.1. Procedure
Content Coding registrations MUST include the following fields: Content coding registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 4 of [RFC7230]), unless the encoding transformation codings (Section 4 of [RFC7230]), unless the encoding transformation
is identical (as is the case for the compression codings defined in is identical (as is the case for the compression codings defined in
Section 4.2 of [RFC7230]). Section 4.2 of [RFC7230]).
Values to be added to this name space require IETF Review (see Values to be added to this namespace require IETF Review (see Section
Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 4.1 of [RFC5226]) and MUST conform to the purpose of content coding
coding defined in this section. defined in this section.
8.4.2. Registrations 8.4.2. Registrations
The HTTP Content Codings Registry shall be updated with the The "HTTP Content Codings Registry" has been updated with the
registrations below: registrations below:
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | Accept-Encoding) | | | | Accept-Encoding) | |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to message syntax, parsing, and routing are Considerations related to message syntax, parsing, and routing are
discussed in Section 9 of [RFC7230]. discussed in Section 9 of [RFC7230].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface) or securing user-agent
processing of payloads received via HTTP, or secure use of the processing of payloads received via HTTP. Secure use of the Internet
Internet in general, rather than security of the protocol. Various in general, rather than security of the protocol, might also be
organizations maintain topical information and links to current related. Various organizations maintain topical information and
research on Web application security (e.g., [OWASP]). links to current research on Web application security (e.g.,
[OWASP]).
9.1. Attacks Based on File and Path Names 9.1. Attacks Based on File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
manage the mapping from effective request URI to resource manage the mapping from effective request URI to resource
representations. Implementers need to be aware that most file representations. Implementers need to be aware that most file
systems are not designed to protect against malicious file or path systems are not designed to protect against malicious file or path
names and, thus, depend on the origin server to avoid mapping to file names and, thus, depend on the origin server to avoid mapping to file
names, folders, or directories that have special significance to the names, folders, or directories that have special significance to the
system. system.
skipping to change at page 82, line 25 skipping to change at page 82, line 25
For example, UNIX, Microsoft Windows, and other operating systems use For example, UNIX, Microsoft Windows, and other operating systems use
".." as a path component to indicate a directory level above the ".." as a path component to indicate a directory level above the
current one, and they use specially named paths or file names to send current one, and they use specially named paths or file names to send
data to system devices. Similar naming conventions might exist data to system devices. Similar naming conventions might exist
within other types of storage systems. Likewise, local storage within other types of storage systems. Likewise, local storage
systems have an annoying tendency to prefer user-friendliness over systems have an annoying tendency to prefer user-friendliness over
security when handling invalid or unexpected characters, security when handling invalid or unexpected characters,
recomposition of decomposed characters, and case-normalization of recomposition of decomposed characters, and case-normalization of
case-insensitive names. case-insensitive names.
Attacks based on such special names tend to focus on either denial- Attacks based on such special names tend to focus on either denial of
of-service (e.g., telling the server to read from a COM port) or service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
9.2. Attacks Based on Command, Code, or Query Injection 9.2. Attacks Based on Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data trusted. An attacker could construct any of the request data
elements (method, request-target, header fields, or body) to contain elements (method, request-target, header fields, or body) to contain
skipping to change at page 83, line 41 skipping to change at page 83, line 41
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the request-
target. Many existing servers, proxies, and user agents log or target. Many existing servers, proxies, and user agents log or
display the request-target in places where it might be visible to display the request-target in places where it might be visible to
third parties. Such services ought to use POST-based form submission third parties. Such services ought to use POST-based form submission
instead. instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on Referer are described in Section 5.5.2 to URI. Limitations on the Referer header field are described in
address some of its security considerations. Section 5.5.2 to address some of its security considerations.
9.5. Disclosure of Fragment after Redirects 9.5. Disclosure of Fragment after Redirects
Although fragment identifiers used within URI references are not sent Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 7.1.2), this might have the effect of reference in Location (Section 7.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
skipping to change at page 86, line 15 skipping to change at page 86, line 15
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. September 2011.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-latest (work in progress), RFC 7230, May 2014.
May 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
draft-ietf-httpbis-p4-conditional-latest (work in May 2014.
progress), May 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-latest (work in progress), RFC 7233, May 2014.
May 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress), RFC 7234, May 2014.
May 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
draft-ietf-httpbis-p7-auth-latest (work in progress),
May 2014.
11.2. Informative References 11.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, June 2012.
skipping to change at page 88, line 32 skipping to change at page 88, line 26
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
June 2011. June 2011.
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Status Code 308 (Permanent Redirect)", Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
draft-reschke-http-status-308-07 (work in progress),
March 2012.
Appendix A. Differences between HTTP and MIME Appendix A. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open [RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields. variety of representations and with extensible header fields.
However, RFC 2045 is focused only on email; applications of HTTP have However, RFC 2045 is focused only on email; applications of HTTP have
many characteristics that differ from email; hence, HTTP has features many characteristics that differ from email; hence, HTTP has features
that differ from MIME. These differences were carefully chosen to that differ from MIME. These differences were carefully chosen to
skipping to change at page 90, line 27 skipping to change at page 90, line 20
message to an HTTP client. message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format responsible for ensuring that the message is in the correct format
and encoding for safe transport on that protocol, where "safe and encoding for safe transport on that protocol, where "safe
transport" is defined by the limitations of the protocol being used. transport" is defined by the limitations of the protocol being used.
Such a proxy or gateway ought to transform and label the data with an Such a proxy or gateway ought to transform and label the data with an
appropriate Content-Transfer-Encoding if doing so will improve the appropriate Content-Transfer-Encoding if doing so will improve the
likelihood of safe transport over the destination protocol. likelihood of safe transport over the destination protocol.
A.6. MHTML and Line Length Limitations A.6. MHTML and Line-Length Limitations
HTTP implementations that share code with MHTML [RFC2557] HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line-length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line-length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type (Appendix A payload and, aside from the "multipart/byteranges" type (Appendix A
of [RFC7233]), does not interpret the content or any MIME header of [RFC7233]), does not interpret the content or any MIME header
lines that might be contained therein. lines that might be contained therein.
Appendix B. Changes from RFC 2616 Appendix B. Changes from RFC 2616
The primary changes in this revision have been editorial in nature: The primary changes in this revision have been editorial in nature:
extracting the messaging syntax and partitioning HTTP semantics into extracting the messaging syntax and partitioning HTTP semantics into
separate documents for the core features, conditional requests, separate documents for the core features, conditional requests,
partial requests, caching, and authentication. The conformance partial requests, caching, and authentication. The conformance
language has been revised to clearly target requirements and the language has been revised to clearly target requirements and the
terminology has been improved to distinguish payload from terminology has been improved to distinguish payload from
representations and representations from resources. representations and representations from resources.
A new requirement has been added that semantics embedded in a URI A new requirement has been added that semantics embedded in a URI be
should be disabled when those semantics are inconsistent with the disabled when those semantics are inconsistent with the request
request method, since this is a common cause of interoperability method, since this is a common cause of interoperability failure
failure. (Section 2) (Section 2).
An algorithm has been added for determining if a payload is An algorithm has been added for determining if a payload is
associated with a specific identifier. (Section 3.1.4.1) associated with a specific identifier (Section 3.1.4.1).
The default charset of ISO-8859-1 for text media types has been The default charset of ISO-8859-1 for text media types has been
removed; the default is now whatever the media type definition says. removed; the default is now whatever the media type definition says.
Likewise, special treatment of ISO-8859-1 has been removed from the Likewise, special treatment of ISO-8859-1 has been removed from the
Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3) Accept-Charset header field. (Sections 3.1.1.3 and 5.3.3.)
The definition of Content-Location has been changed to no longer The definition of Content-Location has been changed to no longer
affect the base URI for resolving relative URI references, due to affect the base URI for resolving relative URI references, due to
poor implementation support and the undesirable effect of potentially poor implementation support and the undesirable effect of potentially
breaking relative links in content-negotiated resources. breaking relative links in content-negotiated resources
(Section 3.1.4.2) (Section 3.1.4.2).
To be consistent with the method-neutral parsing algorithm of To be consistent with the method-neutral parsing algorithm of
[RFC7230], the definition of GET has been relaxed so that requests [RFC7230], the definition of GET has been relaxed so that requests
can have a body, even though a body has no meaning for GET. can have a body, even though a body has no meaning for GET
(Section 4.3.1) (Section 4.3.1).
Servers are no longer required to handle all Content-* header fields Servers are no longer required to handle all Content-* header fields
and use of Content-Range has been explicitly banned in PUT requests. and use of Content-Range has been explicitly banned in PUT requests
(Section 4.3.4) (Section 4.3.4).
Definition of the CONNECT method has been moved from [RFC2817] to Definition of the CONNECT method has been moved from [RFC2817] to
this specification. (Section 4.3.6) this specification (Section 4.3.6).
The OPTIONS and TRACE request methods have been defined as being The OPTIONS and TRACE request methods have been defined as being safe
safe. (Section 4.3.7 and Section 4.3.8) (Section 4.3.7 and Section 4.3.8).
The Expect header field's extension mechanism has been removed due to The Expect header field's extension mechanism has been removed due to
widely-deployed broken implementations. (Section 5.1.1) widely deployed broken implementations (Section 5.1.1).
The Max-Forwards header field has been restricted to the OPTIONS and The Max-Forwards header field has been restricted to the OPTIONS and
TRACE methods; previously, extension methods could have used it as TRACE methods; previously, extension methods could have used it as
well. (Section 5.1.2) well (Section 5.1.2).
The "about:blank" URI has been suggested as a value for the Referer The "about:blank" URI has been suggested as a value for the Referer
header field when no referring URI is applicable, which distinguishes header field when no referring URI is applicable, which distinguishes
that case from others where the Referer field is not sent or has been that case from others where the Referer field is not sent or has been
removed. (Section 5.5.2) removed (Section 5.5.2).
The following status codes are now cacheable (that is, they can be The following status codes are now cacheable (that is, they can be
stored and reused by a cache without explicit freshness information stored and reused by a cache without explicit freshness information
present): 204, 404, 405, 414, 501. (Section 6) present): 204, 404, 405, 414, 501 (Section 6).
The 201 (Created) status description has been changed to allow for The 201 (Created) status description has been changed to allow for
the possibility that more than one resource has been created. the possibility that more than one resource has been created
(Section 6.3.2) (Section 6.3.2).
The definition of 203 (Non-Authoritative Information) has been The definition of 203 (Non-Authoritative Information) has been
broadened to include cases of payload transformations as well. broadened to include cases of payload transformations as well
(Section 6.3.4) (Section 6.3.4).
The set of request methods that are safe to automatically redirect is The set of request methods that are safe to automatically redirect is
no longer closed; user agents are able to make that determination no longer closed; user agents are able to make that determination
based upon the request method semantics. The redirect status codes based upon the request method semantics. The redirect status codes
301, 302, and 307 no longer have normative requirements on response 301, 302, and 307 no longer have normative requirements on response
payloads and user interaction. (Section 6.4) payloads and user interaction (Section 6.4).
The status codes 301 and 302 have been changed to allow user agents The status codes 301 and 302 have been changed to allow user agents
to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3) to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3.)
The description of 303 (See Other) status code has been changed to The description of the 303 (See Other) status code has been changed
allow it to be cached if explicit freshness information is given, and to allow it to be cached if explicit freshness information is given,
a specific definition has been added for a 303 response to GET. and a specific definition has been added for a 303 response to GET
(Section 6.4.4) (Section 6.4.4).
The 305 (Use Proxy) status code has been deprecated due to security The 305 (Use Proxy) status code has been deprecated due to security
concerns regarding in-band configuration of a proxy. (Section 6.4.5) concerns regarding in-band configuration of a proxy (Section 6.4.5).
The 400 (Bad Request) status code has been relaxed so that it isn't The 400 (Bad Request) status code has been relaxed so that it isn't
limited to syntax errors. (Section 6.5.1) limited to syntax errors (Section 6.5.1).
The 426 (Upgrade Required) status code has been incorporated from The 426 (Upgrade Required) status code has been incorporated from
[RFC2817]. (Section 6.5.15) [RFC2817] (Section 6.5.15).
The target of requirements on HTTP-date and the Date header field The target of requirements on HTTP-date and the Date header field
have been reduced to those systems generating the date, rather than have been reduced to those systems generating the date, rather than
all systems sending a date. (Section 7.1.1) all systems sending a date (Section 7.1.1).
The syntax of the Location header field has been changed to allow all The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2) appropriate (Section 7.1.2).
Allow has been reclassified as a response header field, removing the Allow has been reclassified as a response header field, removing the
option to specify it in a PUT request. Requirements relating to the option to specify it in a PUT request. Requirements relating to the
content of Allow have been relaxed; correspondingly, clients are not content of Allow have been relaxed; correspondingly, clients are not
required to always trust its value. (Section 7.4.1) required to always trust its value (Section 7.4.1).
A Method Registry has been defined. (Section 8.1) A Method Registry has been defined (Section 8.1).
The Status Code Registry has been redefined by this specification; The Status Code Registry has been redefined by this specification;
previously, it was defined in Section 7.1 of [RFC2817]. previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
(Section 8.2)
Registration of Content Codings has been changed to require IETF Registration of content codings has been changed to require IETF
Review. (Section 8.4) Review (Section 8.4).
The Content-Disposition header field has been removed since it is now The Content-Disposition header field has been removed since it is now
defined by [RFC6266]. defined by [RFC6266].
The Content-MD5 header field has been removed because it was The Content-MD5 header field has been removed because it was
inconsistently implemented with respect to partial responses. inconsistently implemented with respect to partial responses.
Appendix C. Imported ABNF Appendix C. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
skipping to change at page 99, line 45 skipping to change at page 99, line 40
HEAD method 25 HEAD method 25
I I
idempotent 23 idempotent 23
L L
Location header field 68 Location header field 68
M M
Max-Forwards header field 36 Max-Forwards header field 36
MIME-Version header field 89 MIME-Version header field 88
O O
OPTIONS method 31 OPTIONS method 31
P P
payload 17 payload 17
POST method 25 POST method 25
PUT method 26 PUT method 26
R R
 End of changes. 103 change blocks. 
254 lines changed or deleted 230 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/