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/>.
The changes in this draft are summarized in Appendix E.4.
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 This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7231.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 7, 2014.
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 7 skipping to change at page 4, line 39
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75
8.2.2. Considerations for New Status Codes . . . . . . . . . 76 8.2.2. Considerations for New Status Codes . . . . . . . . . 76
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
8.3.1. Considerations for New Header Fields . . . . . . . . . 78 8.3.1. Considerations for New Header Fields . . . . . . . . . 78
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 82 9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82
9.2. Attacks Based On Command, Code, or Query Injection . . . . 82 9.2. Attacks Based on Command, Code, or Query Injection . . . . 82
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 . . . . . . . . . . . . . . 90 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
Appendix E. Change Log (to be removed by RFC Editor before Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
publication) . . . . . . . . . . . . . . . . . . . . 96
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96
E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 96
E.3. Since draft-ietf-httpbis-p2-semantics-25 . . . . . . . . . 97
E.4. Since draft-ietf-httpbis-p2-semantics-26 . . . . . . . . . 97
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
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
relation to the identified request target, and responds to that relation to the identified request target, and responds to that
request with one or more response messages. A client constructs request with one or more response messages. A client constructs
request messages to communicate specific intentions, and examines request messages to communicate specific intentions, examines
received responses to see if the intentions were carried out and received responses to see if the intentions were carried out, and
determine how to interpret the results. This document defines determines how to interpret the results. This document defines
HTTP/1.1 request and response semantics in terms of the architecture HTTP/1.1 request and response semantics in terms of the architecture
defined in [RFC7230]. defined in [RFC7230].
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 2), regardless of its type, nature, or implementation, via (Section 2), regardless of its type, nature, or implementation, via
the manipulation and transfer of representations (Section 3). the manipulation and transfer of representations (Section 3).
HTTP semantics include the intentions defined by each request method HTTP semantics include the intentions defined by each request method
(Section 4), extensions to those semantics that might be described in (Section 4), extensions to those semantics that might be described in
request header fields (Section 5), the meaning of status codes to request header fields (Section 5), the meaning of status codes to
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 7, line 46 skipping to change at page 7, line 46
abstraction is needed to represent ("take the place of") the current abstraction is needed to represent ("take the place of") the current
or desired state of that thing in our communications. That or desired state of that thing in our communications. That
abstraction is called a representation [REST]. abstraction is called a representation [REST].
For the purposes of HTTP, a "representation" is information that is For the purposes of HTTP, a "representation" is information that is
intended to reflect a past, current, or desired state of a given intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the resource, in a format that can be readily communicated via the
protocol, and that consists of a set of representation metadata and a protocol, and that consists of a set of representation metadata and a
potentially unbounded stream of representation data. potentially unbounded stream of representation data.
An origin server might be provided with, or capable of generating, An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as used by the origin server to select one of those representations as
most applicable to a given request, usually based on content most applicable to a given request, usually based on content
negotiation. This "selected representation" is used to provide the negotiation. This "selected representation" is used to provide the
data and metadata for evaluating conditional requests [RFC7232] and data and metadata for evaluating conditional requests [RFC7232] and
constructing the payload for 200 (OK) and 304 (Not Modified) constructing the payload for 200 (OK) and 304 (Not Modified)
responses to GET (Section 4.3.1). responses to GET (Section 4.3.1).
3.1. Representation Metadata 3.1. Representation Metadata
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 as either 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:
text/html;charset=utf-8 text/html;charset=utf-8
text/html;charset=UTF-8 text/html;charset=UTF-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
Internet media types ought to be registered with IANA according to Internet media types ought to be registered with IANA according to
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 IANA Character Set registry Charset names ought to be registered in the IANA "Character Sets"
(<http://www.iana.org/assignments/character-sets>) according to the registry <http://www.iana.org/assignments/character-sets> according
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 13, line 24 skipping to change at page 13, line 24
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and Content-
Language header fields. Accept-Language uses the broader language- Language header fields. Accept-Language uses the broader language-
range production defined in Section 5.3.5, whereas Content-Language range production defined in Section 5.3.5, whereas Content-Language
uses the language-tag production defined below. uses the language-tag production defined below.
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English) which is broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include: tag. Example tags include:
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
3.1.3.2. Content-Language 3.1.3.2. Content-Language
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 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.
4.2.3. Cacheable Methods 4.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for responses to them are allowed to be stored for future reuse; for
specific requirements see [RFC7234]. In general, safe methods that specific requirements see [RFC7234]. In general, safe methods that
do not depend on a current or authoritative response are defined as do not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD and POST as cacheable; this specification defines GET, HEAD, and POST as
cacheable, although the overwhelming majority of cache cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD. implementations only support GET and HEAD.
4.3. Method Definitions 4.3. Method Definitions
4.3.1. GET 4.3.1. GET
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations. retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request. via HTTP, they are generally referring to making a GET request.
It is tempting to think of resource identifiers as remote file system It is tempting to think of resource identifiers as remote file system
pathnames, and of representations as being a copy of the contents of pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are Section 9.1 for related security considerations). However, there are
no such limitations in practice. The HTTP interface for a resource no such limitations in practice. The HTTP interface for a resource
is just as likely to be implemented as a tree of content objects, a is just as likely to be implemented as a tree of content objects, a
programmatic view on various database records, or a gateway to other programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to information systems. Even when the URI mapping mechanism is tied to
a file system, an origin server might be configured to execute the a file system, an origin server might be configured to execute the
files with the request as input and send the output as the files with the request as input and send the output as the
representation, rather than transfer the files directly. Regardless, representation rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource only the origin server needs to know how each of its resource
identifiers corresponds to an implementation, and how each identifiers corresponds to an implementation and how each
implementation manages to select and send a current representation of implementation manages to select and send a current representation of
the target resource in a response to GET. the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
([RFC7233]). ([RFC7233]).
A payload within a GET request message has no defined semantics; A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing sending a payload body on a GET request might cause some existing
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 18 skipping to change at page 28, line 19
intentionally hidden by the server. intentionally hidden by the server.
An origin server MUST NOT send a validator header field An origin server MUST NOT send a validator header field
(Section 7.2), such as an ETag or Last-Modified field, in a (Section 7.2), such as an ETag or Last-Modified field, in a
successful response to PUT unless the request's representation data successful response to PUT unless the request's representation data
was saved without any transformation applied to the body (i.e., the was saved without any transformation applied to the body (i.e., the
resource's new representation data is identical to the representation resource's new representation data is identical to the representation
data received in the PUT request) and the validator field value data received in the PUT request) and the validator field value
reflects the new representation. This requirement allows a user reflects the new representation. This requirement allows a user
agent to know when the representation body it has in memory remains agent to know when the representation body it has in memory remains
current as a result of the PUT, thus not in need of retrieving again current as a result of the PUT, thus not in need of being retrieved
from the origin server, and that the new validator(s) received in the again from the origin server, and that the new validator(s) received
response can be used for future conditional requests in order to in the response can be used for future conditional requests in order
prevent accidental overwrites (Section 5.2). to prevent accidental overwrites (Section 5.2).
The fundamental difference between the POST and PUT methods is The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation. highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics, enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server. effect is only known by the origin server.
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 29, line 26 skipping to change at page 29, line 27
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 4.4 of [RFC7234]). invalidated (see Section 4.4 of [RFC7234]).
4.3.5. DELETE 4.3.5. DELETE
The DELETE method requests that the origin server remove the The DELETE method requests that the origin server remove the
association between the target resource and its current association between the target resource and its current
functionality. In effect, this method is similar to the rm command functionality. In effect, this method is similar to the rm command
in UNIX: it expresses a deletion operation on the URI mapping of the in UNIX: it expresses a deletion operation on the URI mapping of the
origin server, rather than an expectation that the previously origin server rather than an expectation that the previously
associated information be deleted. associated information be deleted.
If the target resource has one or more current representations, they If the target resource has one or more current representations, they
might or might not be destroyed by the origin server, and the might or might not be destroyed by the origin server, and the
associated storage might or might not be reclaimed, depending associated storage might or might not be reclaimed, depending
entirely on the nature of the resource and its implementation by the entirely on the nature of the resource and its implementation by the
origin server (which are beyond the scope of this specification). origin server (which are beyond the scope of this specification).
Likewise, other implementation aspects of a resource might need to be Likewise, other implementation aspects of a resource might need to be
deactivated or archived as a result of a DELETE, such as database or deactivated or archived as a result of a DELETE, such as database or
gateway connections. In general, it is assumed that the origin gateway connections. In general, it is assumed that the origin
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 31, line 42 skipping to change at page 31, line 43
A payload within a CONNECT request message has no defined semantics; A payload within a CONNECT request message has no defined semantics;
sending a payload body on a CONNECT request might cause some existing sending a payload body on a CONNECT request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the CONNECT method are not cacheable. Responses to the CONNECT method are not cacheable.
4.3.7. OPTIONS 4.3.7. OPTIONS
The OPTIONS method requests information about the communication The OPTIONS method requests information about the communication
options available for the target resource, either at the origin options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a resource, or the capabilities of a server, without implying a
resource action. resource action.
An OPTIONS request with an asterisk ("*") as the request-target An OPTIONS request with an asterisk ("*") as the request-target
(Section 5.3 of [RFC7230]) applies to the server in general rather (Section 5.3 of [RFC7230]) applies to the server in general rather
than to a specific resource. Since a server's communication options than to a specific resource. Since a server's communication options
typically depend on the resource, the "*" request is only useful as a typically depend on the resource, the "*" request is only useful as a
"ping" or "no-op" type of method; it does nothing beyond allowing the "ping" or "no-op" type of method; it does nothing beyond allowing the
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 36, line 40 skipping to change at page 36, line 40
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message can be forwarded. number of times this request message can be forwarded.
Each intermediary that receives a TRACE or OPTIONS request containing Each intermediary that receives a TRACE or OPTIONS request containing
a Max-Forwards header field MUST check and update its value prior to a Max-Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the forwarding the request. If the received value is zero (0), the
intermediary MUST NOT forward the request; instead, the intermediary intermediary MUST NOT forward the request; instead, the intermediary
MUST respond as the final recipient. If the received Max-Forwards MUST respond as the final recipient. If the received Max-Forwards
value is greater than zero, the intermediary MUST generate an updated value is greater than zero, the intermediary MUST generate an updated
Max-Forwards field in the forwarded message with a field-value that Max-Forwards field in the forwarded message with a field-value that
is the lesser of: a) the received value decremented by one (1), or b) is the lesser of a) the received value decremented by one (1) or b)
the recipient's maximum supported value for Max-Forwards. the recipient's maximum supported value for Max-Forwards.
A recipient MAY ignore a Max-Forwards header field received with any A recipient MAY ignore a Max-Forwards header field received with any
other request methods. other request methods.
5.2. Conditionals 5.2. Conditionals
The HTTP conditional request header fields [RFC7232] allow a client The HTTP conditional request header fields [RFC7232] allow a client
to place a precondition on the state of the target resource, so that to place a precondition on the state of the target resource, so that
the action corresponding to the method semantics will not be applied the action corresponding to the method semantics will not be applied
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 43, line 4 skipping to change at page 43, line 4
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English". other types of English".
A request without any Accept-Language header field implies that the A request without any Accept-Language header field implies that the
user agent will accept any language in response. If the header field user agent will accept any language in response. If the header field
is present in a request and none of the available representations for is present in a request and none of the available representations for
the response have a matching language tag, the origin server can the response have a matching language tag, the origin server can
either disregard the header field by treating the response as if it either disregard the header field by treating the response as if it
is not subject to content negotiation, or honor the header field by is not subject to content negotiation or honor the header field by
sending a 406 (Not Acceptable) response. However, the latter is not sending a 406 (Not Acceptable) response. However, the latter is not
encouraged, as doing so can prevent users from accessing content that encouraged, as doing so can prevent users from accessing content that
they might be able to use (with translation software, for example). they might be able to use (with translation software, for example).
Note that some recipients treat the order in which language tags are Note that some recipients treat the order in which language tags are
listed as an indication of descending priority, particularly for tags listed as an indication of descending priority, particularly for tags
that are assigned equal quality values (no value is the same as q=1). that are assigned equal quality values (no value is the same as q=1).
However, this behavior cannot be relied upon. For consistency and to However, this behavior cannot be relied upon. For consistency and to
maximize interoperability, many user agents assign each language tag maximize interoperability, many user agents assign each language tag
a unique quality value while also listing them in order of decreasing a unique quality value while also listing them in order of decreasing
skipping to change at page 43, line 30 skipping to change at page 43, line 30
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 9.7). preferences of the user in every request (Section 9.7).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself, or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an Accept-
Language header field. Language header field.
Note: User agents ought to provide guidance to users when setting Note: User agents ought to provide guidance to users when setting
a preference, since users are rarely familiar with the details of a preference, since users are rarely familiar with the details of
language matching as described above. For example, users might language matching as described above. For example, users might
assume that on selecting "en-gb", they will be served any kind of assume that on selecting "en-gb", they will be served any kind of
English document if British English is not available. A user English document if British English is not available. A user
agent might suggest, in such a case, to add "en" to the list for agent might suggest, in such a case, to add "en" to the list for
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 to only 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
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 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 3-digit integer code giving the result The status-code element is a three-digit integer code giving the
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 5 The last two digits do not have any categorization role. There are
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
o 3xx (Redirection): Further action needs to be taken in order to o 3xx (Redirection): Further action needs to be taken in order to
complete the request complete the request
o 4xx (Client Error): The request contains bad syntax or cannot be o 4xx (Client Error): The request contains bad syntax or cannot be
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 |
| 204 | No Content | Section 6.3.5 | | 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 | | 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] | | 206 | Partial Content | Section 4.1 of [RFC7233] |
skipping to change at page 50, line 13 skipping to change at page 50, line 13
extension status codes defined in other specifications. The complete extension status codes defined in other specifications. The complete
list of status codes is maintained by IANA. See Section 8.2 for list of status codes is maintained by IANA. See Section 8.2 for
details. details.
6.2. Informational 1xx 6.2. Informational 1xx
The 1xx (Informational) class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. All 1xx responses consist of only the status-line and response. All 1xx responses consist of only the status-line and
optional header fields, and thus are terminated by the empty line at optional header fields and, thus, are terminated by the empty line at
the end of the header section. Since HTTP/1.0 did not define any 1xx the end of the header section. Since HTTP/1.0 did not define any 1xx
status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
client. client.
A client MUST be able to parse one or more 1xx responses received A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses. user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an the generation of the 1xx response. For example, if a proxy adds an
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 57, line 26 skipping to change at page 57, line 26
a retrieval request targeting that URI (a GET or HEAD request if a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the in the Location header field is not considered equivalent to the
effective request URI. effective request URI.
This status code is applicable to any HTTP method. It is primarily This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached independent of the original identified, bookmarked, and cached, independent of the original
request. request.
A 303 response to a GET request indicates that the origin server does A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be not have a representation of the target resource that can be
transferred by the server over HTTP. However, the Location field transferred by the server over HTTP. However, the Location field
value refers to a resource that is descriptive of the target value refers to a resource that is descriptive of the target
resource, such that making a retrieval request on that other resource resource, such that making a retrieval request on that other resource
might result in a representation that is useful to recipients without might result in a representation that is useful to recipients without
implying that it represents the original target resource. Note that implying that it represents the original target resource. Note that
answers to the questions of what can be represented, what answers to the questions of what can be represented, what
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) ([status-308], 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.
6.5.1. 400 Bad Request 6.5.1. 400 Bad Request
The 400 (Bad Request) status code indicates that the server cannot or The 400 (Bad Request) status code indicates that the server cannot or
will not process the request due to something which is perceived to will not process the request due to something that is perceived to be
be a client error (e.g., malformed request syntax, invalid request a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing). message framing, or deceptive request routing).
6.5.2. 402 Payment Required 6.5.2. 402 Payment Required
The 402 (Payment Required) status code is reserved for future use. The 402 (Payment Required) status code is reserved for future use.
6.5.3. 403 Forbidden 6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to the request but refuses to authorize it. A server that wishes to
skipping to change at page 61, line 39 skipping to change at page 61, line 39
6.5.12. 414 URI Too Long 6.5.12. 414 URI Too Long
The 414 (URI Too Long) status code indicates that the server is The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section refusing to service the request because the request-target (Section
5.3 of [RFC7230]) is longer than the server is willing to interpret. 5.3 of [RFC7230]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to itself) or when the server is under attack by a client attempting to
exploit potential security holes. exploit potential security holes.
A 414 response is cacheable by default; i.e., unless otherwise A 414 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]).
6.5.13. 415 Unsupported Media Type 6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
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 69, line 5 skipping to change at page 69, line 5
The field value consists of a single URI-reference. When it has the The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI value is computed by resolving it against the effective request URI
([RFC3986], Section 5). ([RFC3986], Section 5).
For 201 (Created) responses, the Location value refers to the primary For 201 (Created) responses, the Location value refers to the primary
resource created by the request. For 3xx (Redirection) responses, resource created by the request. For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for the Location value refers to the preferred target resource for
automatically redirecting the request. automatically redirecting the request.
If the Location value provided in a 3xx (Redirection) does not have a If the Location value provided in a 3xx (Redirection) response does
fragment component, a user agent MUST process the redirection as if not have a fragment component, a user agent MUST process the
the value inherits the fragment component of the URI reference used redirection as if the value inherits the fragment component of the
to generate the request target (i.e., the redirection inherits the URI reference used to generate the request target (i.e., the
original reference's fragment, if any). redirection inherits the original reference's fragment, if any).
For example, a GET request generated for the URI reference For example, a GET request generated for the URI reference
"http://www.example.org/~tim" might result in a 303 (See Other) "http://www.example.org/~tim" might result in a 303 (See Other)
response containing the header field: response containing the header field:
Location: /People.html#tim Location: /People.html#tim
which suggests that the user agent redirect to which suggests that the user agent redirect to
"http://www.example.org/People.html#tim" "http://www.example.org/People.html#tim"
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 to not 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 79, line 15 skipping to change at page 79, line 15
Allowing both unquoted (token) and quoted (quoted-string) syntax for Allowing both unquoted (token) and quoted (quoted-string) syntax for
the parameter value enables recipients to use existing parser the parameter value enables recipients to use existing parser
components. When allowing both forms, the meaning of a parameter components. When allowing both forms, the meaning of a parameter
value ought to be independent of the syntax used for it (for an value ought to be independent of the syntax used for it (for an
example, see the notes on parameter handling for media types in example, see the notes on parameter handling for media types in
Section 3.1.1.1). Section 3.1.1.1).
Authors of specifications defining new header fields are advised to Authors of specifications defining new header fields are advised to
consider documenting: consider documenting:
o Whether the field is a single value, or whether it can be a list o Whether the field is a single value or whether it can be a list
(delimited by commas; see Section 3.2 of [RFC7230]). (delimited by commas; see Section 3.2 of [RFC7230]).
If it does not use the list syntax, document how to treat messages If it does not use the list syntax, document how to treat messages
where the field occurs multiple times (a sensible default would be where the field occurs multiple times (a sensible default would be
to ignore the field, but this might not always be the right to ignore the field, but this might not always be the right
choice). choice).
Note that intermediaries and software libraries might combine Note that intermediaries and software libraries might combine
multiple header field instances into a single one, despite the multiple header field instances into a single one, despite the
field's definition not allowing the list syntax. A robust format field's definition not allowing the list syntax. A robust format
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 |
| Content-Encoding | http | standard | Section 3.1.2.2 | | Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 | | Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 | | Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 | | Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 | | Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 | | Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 | | From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 | | Location | http | standard | Section 7.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Max-Forwards | http | standard | Section 5.1.2 | | Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 | | Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 | | Retry-After | http | standard | Section 7.1.3 |
| 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.
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 use specially named paths or file names to send data current one, and they use specially named paths or file names to send
to system devices. Similar naming conventions might exist within data to system devices. Similar naming conventions might exist
other types of storage systems. Likewise, local storage systems have within other types of storage systems. Likewise, local storage
an annoying tendency to prefer user-friendliness over security when systems have an annoying tendency to prefer user-friendliness over
handling invalid or unexpected characters, recomposition of security when handling invalid or unexpected characters,
decomposed characters, and case-normalization of case-insensitive recomposition of decomposed characters, and case-normalization of
names. case-insensitive names.
Attacks based on such special names tend to focus on either denial of Attacks based on such special names tend to focus on either denial 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
data that might be misinterpreted as a command, code, or query when data that might be misinterpreted as a command, code, or query when
passed through a command invocation, language interpreter, or passed through a command invocation, language interpreter, or
database interface. database interface.
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 85, line 33 skipping to change at page 85, line 33
negotiation header fields in relayed requests. negotiation header fields in relayed requests.
10. Acknowledgments 10. Acknowledgments
See Section 10 of [RFC7230]. See Section 10 of [RFC7230].
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Mail Extensions (MIME) Part One: Format of Internet Extensions (MIME) Part One: Format of Internet Message
Message Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Mail Extensions (MIME) Part Two: Media Types", Extensions (MIME) Part Two: Media Types", RFC 2046,
RFC 2046, November 1996. November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
"Uniform Resource Identifier (URI): Generic Syntax", Resource Identifier (URI): Generic Syntax", STD 66,
STD 66, RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Language Tags", BCP 47, RFC 4647, September 2006. Tags", BCP 47, RFC 4647, September 2006.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234, January 2008.
January 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Identifying Languages", BCP 47, RFC 5646, Languages", BCP 47, RFC 5646, September 2009.
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 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Transfer Protocol (HTTP/1.1): Message Syntax and Protocol (HTTP/1.1): Message Syntax and Routing",
Routing", draft-ietf-httpbis-p1-messaging-latest (work RFC 7230, May 2014.
in progress), May 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
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 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
Requests", draft-ietf-httpbis-p5-range-latest (work in RFC 7233, May 2014.
progress), 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 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
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.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90, RFC 3864,
RFC 3864, September 2004. September 2004.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Applications and Web Services", The Open Web Application
Application Security Project (OWASP) 2.0.1, July 2005, Security Project (OWASP) 2.0.1, July 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures",
Doctoral Dissertation, University of California, Doctoral Dissertation, University of California, Irvine,
Irvine, September 2000, September 2000,
<http://roy.gbiv.com/pubs/dissertation/top.htm>. <http://roy.gbiv.com/pubs/dissertation/top.htm>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
May 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Mail Extensions (MIME) Part Five: Conformance Criteria Extensions (MIME) Part Five: Conformance Criteria and
and Examples", RFC 2049, November 1996. Examples", RFC 2049, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
T. Berners-Lee, "Hypertext Transfer Protocol -- Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
HTTP/1.1", RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
Negotiation in HTTP", RFC 2295, March 1998. in HTTP", RFC 2295, March 1998.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as "MIME Encapsulation of Aggregate Documents, such as HTML
HTML (MHTML)", RFC 2557, March 1999. (MHTML)", RFC 2557, March 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP [RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP
Extension Framework", RFC 2774, February 2000. Extension Framework", RFC 2774, February 2000.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
an IANA Considerations Section in RFCs", BCP 26, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
RFC 5226, May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Security (TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246, August 2008.
August 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010. RFC 5789, March 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and "Network Time Protocol Version 4: Protocol and Algorithms
Algorithms Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
[RFC5987] Reschke, J., "Character Set and Language Encoding for [RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010. Parameters", RFC 5987, August 2010.
[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 [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
Field in the Hypertext Transfer Protocol (HTTP)", in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
RFC 6266, June 2011. June 2011.
[status-308] 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, and hence HTTP has many characteristics that differ from email; hence, HTTP has features
features that differ from MIME. These differences were carefully that differ from MIME. These differences were carefully chosen to
chosen to optimize performance over binary connections, to allow optimize performance over binary connections, to allow greater
greater freedom in the use of new media types, to make date freedom in the use of new media types, to make date comparisons
comparisons easier, and to acknowledge the practice of some early easier, and to acknowledge the practice of some early HTTP servers
HTTP servers and clients. and clients.
This appendix describes specific areas where HTTP differs from MIME. This appendix describes specific areas where HTTP differs from MIME.
Proxies and gateways to and from strict MIME environments need to be Proxies and gateways to and from strict MIME environments need to be
aware of these differences and provide the appropriate conversions aware of these differences and provide the appropriate conversions
where necessary. where necessary.
A.1. MIME-Version A.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, messages can include HTTP is not a MIME-compliant protocol. However, messages can include
a single MIME-Version header field to indicate what version of the a single MIME-Version header field to indicate what version of the
skipping to change at page 90, line 32 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 96, line 28 skipping to change at page 96, line 20
subtype = token subtype = token
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = <token, defined in [RFC7230], Section 3.2.6> token = <token, defined in [RFC7230], Section 3.2.6>
type = token type = token
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in <http://
trac.tools.ietf.org/html/
draft-ietf-httpbis-p2-semantics-24#appendix-E>.
E.2. Since draft-ietf-httpbis-p2-semantics-24
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Review
Cachability of Status Codes WRT 'Negative Caching'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
needs to be updated to 5905"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency:
clarify 'effect'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR
review of draft-ietf-httpbis-p2-semantics-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
registrations to correct draft"
E.3. Since draft-ietf-httpbis-p2-semantics-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/520>: "Gen-Art
review of draft-ietf-httpbis-p2-semantics-24 with security
considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/532>: "IESG ballot
on draft-ietf-httpbis-p2-semantics-25"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/545>: "requirement
on implementing methods according to their semantics"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/546>:
"considerations for new headers: privacy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
E.4. Since draft-ietf-httpbis-p2-semantics-26
None yet.
Index Index
1 1
1xx Informational (status code class) 50 1xx Informational (status code class) 50
2 2
2xx Successful (status code class) 51 2xx Successful (status code class) 51
3 3
3xx Redirection (status code class) 54 3xx Redirection (status code class) 54
skipping to change at page 101, line 8 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. 172 change blocks. 
469 lines changed or deleted 382 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/