Changeset 2030
- Timestamp:
- 04/12/12 12:58:55 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2029 r2030 596 596 </li> 597 597 <li><a href="#rfc.section.3.2">3.2</a> <a href="#header.fields">Header Fields</a><ul> 598 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#whitespace">Whitespace</a></li> 599 <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#field.parsing">Field Parsing</a></li> 600 <li><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#field.length">Field Length</a></li> 601 <li><a href="#rfc.section.3.2.4">3.2.4</a> <a href="#field.components">Field value components</a></li> 598 <li><a href="#rfc.section.3.2.1">3.2.1</a> <a href="#field.extensibility">Field Extensibility</a></li> 599 <li><a href="#rfc.section.3.2.2">3.2.2</a> <a href="#field.order">Field Order</a></li> 600 <li><a href="#rfc.section.3.2.3">3.2.3</a> <a href="#whitespace">Whitespace</a></li> 601 <li><a href="#rfc.section.3.2.4">3.2.4</a> <a href="#field.parsing">Field Parsing</a></li> 602 <li><a href="#rfc.section.3.2.5">3.2.5</a> <a href="#field.limits">Field Limits</a></li> 603 <li><a href="#rfc.section.3.2.6">3.2.6</a> <a href="#field.components">Field value components</a></li> 602 604 </ul> 603 605 </li> … … 735 737 into a hypertext format that can be viewed and manipulated by clients in the same way as HTTP services. 736 738 </p> 737 <p id="rfc.section.1.p.5">One consequence of HTTPflexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead,739 <p id="rfc.section.1.p.5">One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, 738 740 we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of 739 741 recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding … … 791 793 <div id="rfc.iref.r.1"></div> 792 794 <p id="rfc.section.2.1.p.2">The terms client and server refer only to the roles that these programs perform for a particular connection. The same program 793 might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the794 term "<dfn>origin server</dfn>" to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term795 "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives themessage.795 might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders 796 (web-based robots), command-line tools, native applications, and mobile apps. The term "<dfn>origin server</dfn>" is used to refer to the program that can originate authoritative responses to a request. For general requirements, we use 797 the terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" to refer to any component that sends or receives, respectively, a given message. 796 798 </p> 797 799 <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the differences between HTTP and MIME messages). … … 1062 1064 <p id="rfc.section.2.7.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.13"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal 1063 1065 configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, 1064 even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST NOT</em> include a userinfo subcomponent (and its "@" delimiter) when transmitting an "http" URI in a message. Recipients of HTTP messages1065 t hat contain a URI reference <em class="bcp14">SHOULD</em> parse for the existence of userinfo and treat its presence as an error, likely indicating that the deprecated subcomponent1066 is being used to obscure the authority for the sakeof phishing attacks.1066 even though such usage might expose a user identifier or password. Senders <em class="bcp14">MUST</em> exclude the userinfo subcomponent (and its "@" delimiter) when an "http" URI is transmitted within a message as a request 1067 target or header field value. Recipients of an "http" URI reference <em class="bcp14">SHOULD</em> parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake 1068 of phishing attacks. 1067 1069 </p> 1068 1070 <h3 id="rfc.section.2.7.2"><a href="#rfc.section.2.7.2">2.7.2</a> <a id="https.uri" href="#https.uri">https URI scheme</a></h3> … … 1149 1151 </p> 1150 1152 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#request.line" class="smpl">request-line</a> = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a> 1151 </pre><p id="rfc.section.3.1.1.p.3">A server <em class="bcp14">MUST</em> be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message. 1152 </p> 1153 <div id="rfc.iref.m.2"></div> 1153 </pre><div id="rfc.iref.m.2"></div> 1154 1154 <div id="method"> 1155 <p id="rfc.section.3.1.1.p. 4">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>1155 <p id="rfc.section.3.1.1.p.3">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p> 1156 1156 </div> 1157 1157 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1158 </pre><p id="rfc.section.3.1.1.p. 6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1158 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1159 1159 </p> 1160 1160 <div id="rfc.iref.r.6"></div> 1161 <p id="rfc.section.3.1.1.p. 7">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section 5.3</a>.1162 </p> 1163 <p id="rfc.section.3.1.1.p. 8">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line1161 <p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section 5.3</a>. 1162 </p> 1163 <p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line 1164 1164 into its component parts by splitting on whitespace (see <a href="#message.robustness" title="Message Parsing Robustness">Section 3.5</a>). 1165 1165 </p> 1166 <p id="rfc.section.3.1.1.p. 9">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters1166 <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters 1167 1167 directly instead of properly encoding or excluding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately 1168 1168 crafted to bypass security filters along the request chain. 1169 1169 </p> 1170 <p id="rfc.section.3.1.1.p. 10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that1170 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1171 1171 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1172 1172 </p> 1173 <p id="rfc.section.3.1.1.p.1 1">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to8000 octets.1173 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets. 1174 1174 </p> 1175 1175 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="status.line" href="#status.line">Status Line</a></h3> … … 1178 1178 </p> 1179 1179 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.line" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1180 </pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message. 1181 </p> 1182 <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy 1180 </pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy 1183 1181 the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined 1184 1182 for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit), … … 1186 1184 </p> 1187 1185 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#status.line" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1188 </pre><p id="rfc.section.3.1.2.p. 6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status1186 </pre><p id="rfc.section.3.1.2.p.5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status 1189 1187 code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text 1190 1188 clients. A client <em class="bcp14">SHOULD</em> ignore the reason-phrase content. … … 1201 1199 <a href="#header.fields" class="smpl">obs-fold</a> = <a href="#core.rules" class="smpl">CRLF</a> ( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) 1202 1200 ; obsolete line folding 1203 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2. 2</a>1201 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.4</a> 1204 1202 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1205 1203 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1206 1204 </p> 1207 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining 1208 new semantics, or on the number of header fields used in a given message. Existing fields are defined in each part of this 1209 specification and in many other specifications outside the standards process. New header fields can be introduced without 1210 changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize 1211 them. 1212 </p> 1213 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1214 </p> 1215 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1205 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="field.extensibility" href="#field.extensibility">Field Extensibility</a></h3> 1206 <p id="rfc.section.3.2.1.p.1">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining 1207 new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this 1208 specification and in many other specifications outside the core standard. New header fields can be introduced without changing 1209 the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them. 1210 </p> 1211 <p id="rfc.section.3.2.1.p.2">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1212 </p> 1213 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.order" href="#field.order">Field Order</a></h3> 1214 <p id="rfc.section.3.2.2.p.1">The order in which header fields with differing field names are received is not significant. However, it is "good practice" 1216 1215 to send header fields that contain control data first, such as <a href="#header.host" class="smpl">Host</a> on requests and <a href="p2-semantics.html#header.date" class="smpl">Date</a> on responses, so that implementations can decide when not to handle a message as early as possible. A server <em class="bcp14">MUST</em> wait until the entire header section is received before interpreting a request message, since later header fields might include 1217 1216 conditionals, authentication credentials, or deliberately misleading duplicate header fields that would impact request processing. 1218 1217 </p> 1219 <p id="rfc.section.3.2.p.7">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)]. 1220 Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing 1218 <p id="rfc.section.3.2.2.p.2">Multiple header fields with the same field name <em class="bcp14">MUST NOT</em> be sent in a message unless the entire field value for that header field is defined as a comma-separated list [i.e., #(values)]. 1219 </p> 1220 <p id="rfc.section.3.2.2.p.3">Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing 1221 1221 the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by 1222 1222 a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation 1223 1223 of the combined field value; a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when forwarding a message. 1224 1224 </p> 1225 <div class="note" id="rfc.section.3.2.p.8"> 1226 <p> <b>Note:</b> The "Set-Cookie" header field as implemented in practice can occur multiple times, but does not use the list syntax, and thus 1227 cannot be combined into a single line (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>). (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) 1225 <div class="note" id="rfc.section.3.2.2.p.4"> 1226 <p> <b>Note:</b> In practice, the "Set-Cookie" header field (<a href="#RFC6265" id="rfc.xref.RFC6265.2"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>) often appears multiple times in a response message and does not use the list syntax, violating the above requirements on 1227 multiple header fields with the same name. Since it cannot be combined into a single field-value, recipients ought to handle 1228 "Set-Cookie" as a special case while processing header fields. (See Appendix A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) 1228 1229 </p> 1229 1230 </div> 1230 <h3 id="rfc.section.3.2. 1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="whitespace" href="#whitespace">Whitespace</a></h3>1231 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="whitespace" href="#whitespace">Whitespace</a></h3> 1231 1232 <div id="rule.LWS"> 1232 <p id="rfc.section.3.2. 1.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace),1233 <p id="rfc.section.3.2.3.p.1">This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), 1233 1234 and BWS ("bad" whitespace). 1234 1235 </p> 1235 1236 </div> 1236 1237 <div id="rule.OWS"> 1237 <p id="rfc.section.3.2. 1.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting1238 <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be generated or be generated as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting 1238 1239 the field value or forwarding the message downstream. 1239 1240 </p> 1240 1241 </div> 1241 1242 <div id="rule.RWS"> 1242 <p id="rfc.section.3.2. 1.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be produced as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the1243 <p id="rfc.section.3.2.3.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be generated as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the 1243 1244 message downstream. 1244 1245 </p> 1245 1246 </div> 1246 1247 <div id="rule.BWS"> 1247 <p id="rfc.section.3.2. 1.p.4">BWS is used where the grammar allows optional whitespace, for historical reasons, but senders <em class="bcp14">SHOULD NOT</em> produce it in messages; recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.1248 <p id="rfc.section.3.2.3.p.4">BWS is used where the grammar allows optional whitespace, for historical reasons, but senders <em class="bcp14">SHOULD NOT</em> generate it in messages; recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. 1248 1249 </p> 1249 1250 </div> 1250 1251 <div id="rule.whitespace"> 1251 <p id="rfc.section.3.2. 1.p.5"> </p>1252 <p id="rfc.section.3.2.3.p.5"> </p> 1252 1253 </div> 1253 1254 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span> <a href="#rule.whitespace" class="smpl">OWS</a> = *( <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">HTAB</a> ) … … 1257 1258 <a href="#rule.whitespace" class="smpl">BWS</a> = <a href="#rule.whitespace" class="smpl">OWS</a> 1258 1259 ; "bad" whitespace 1259 </pre><h3 id="rfc.section.3.2. 2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3>1260 <p id="rfc.section.3.2. 2.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace1260 </pre><h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.parsing" href="#field.parsing">Field Parsing</a></h3> 1261 <p id="rfc.section.3.2.4.p.1">No whitespace is allowed between the header field-name and colon. In the past, differences in the handling of such whitespace 1261 1262 have led to security vulnerabilities in request routing and response handling. Any received request message that contains 1262 1263 whitespace between a header field-name and colon <em class="bcp14">MUST</em> be rejected with a response code of 400 (Bad Request). A proxy <em class="bcp14">MUST</em> remove any such whitespace from a response message before forwarding the message downstream. 1263 1264 </p> 1264 <p id="rfc.section.3.2. 2.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading1265 <p id="rfc.section.3.2.4.p.2">A field value is preceded by optional whitespace (OWS); a single SP is preferred. The field value does not include any leading 1265 1266 or trailing white space: OWS occurring before the first non-whitespace octet of the field value or after the last non-whitespace 1266 1267 octet of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field). 1267 1268 </p> 1268 <p id="rfc.section.3.2. 2.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one1269 <p id="rfc.section.3.2.4.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1269 1270 space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type 1270 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> produce messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the1271 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a>). HTTP senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the 1271 1272 message is intended for packaging within the message/http media type. HTTP recipients <em class="bcp14">SHOULD</em> accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets 1272 1273 (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream. 1273 1274 </p> 1274 <p id="rfc.section.3.2.2.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data. 1275 </p> 1276 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="field.length" href="#field.length">Field Length</a></h3> 1277 <p id="rfc.section.3.2.3.p.1">HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with a <a href="p2-semantics.html#status.4xx" class="smpl">4xx 1278 (Client Error)</a> status code if the received header field(s) would be longer than the server wishes to handle. 1279 </p> 1280 <p id="rfc.section.3.2.3.p.2">A client that receives response header fields that are longer than it wishes to handle can only treat it as a server error.</p> 1281 <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header field length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets. 1282 </p> 1283 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.components" href="#field.components">Field value components</a></h3> 1275 <p id="rfc.section.3.2.4.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data. 1276 </p> 1277 <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="field.limits" href="#field.limits">Field Limits</a></h3> 1278 <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole. 1279 Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field 1280 semantics. 1281 </p> 1282 <p id="rfc.section.3.2.5.p.2">A server <em class="bcp14">MUST</em> be prepared to receive request header fields of unbounded length and respond with an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> status code if the received header field(s) are larger than the server wishes to process. 1283 </p> 1284 <p id="rfc.section.3.2.5.p.3">A client <em class="bcp14">MUST</em> be prepared to receive response header fields of unbounded length. A client <em class="bcp14">MAY</em> discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such 1285 that the dropped value(s) can be safely ignored without changing the response semantics. 1286 </p> 1287 <h3 id="rfc.section.3.2.6"><a href="#rfc.section.3.2.6">3.2.6</a> <a id="field.components" href="#field.components">Field value components</a></h3> 1284 1288 <div id="rule.token.separators"> 1285 <p id="rfc.section.3.2. 4.p.1"> Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These1289 <p id="rfc.section.3.2.6.p.1"> Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These 1286 1290 special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1287 1291 </p> … … 1300 1304 / "]" / "?" / "=" / "{" / "}" 1301 1305 </pre><div id="rule.quoted-string"> 1302 <p id="rfc.section.3.2. 4.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p>1306 <p id="rfc.section.3.2.6.p.3"> A string of text is parsed as a single word if it is quoted using double-quote marks.</p> 1303 1307 </div> 1304 1308 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span> <a href="#rule.quoted-string" class="smpl">quoted-string</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#rule.quoted-string" class="smpl">qdtext</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> … … 1306 1310 <a href="#rule.quoted-string" class="smpl">obs-text</a> = %x80-FF 1307 1311 </pre><div id="rule.quoted-pair"> 1308 <p id="rfc.section.3.2. 4.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p>1312 <p id="rfc.section.3.2.6.p.5"> The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string constructs:</p> 1309 1313 </div> 1310 1314 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1311 </pre><p id="rfc.section.3.2.4.p.7">Recipients that process the value of the quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 1312 </p> 1313 <p id="rfc.section.3.2.4.p.8">Senders <em class="bcp14">SHOULD NOT</em> escape octets in quoted-strings that do not require escaping (i.e., other than DQUOTE and the backslash octet). 1315 </pre><p id="rfc.section.3.2.6.p.7">Recipients that process the value of a quoted-string <em class="bcp14">MUST</em> handle a quoted-pair as if it were replaced by the octet following the backslash. 1316 </p> 1317 <p id="rfc.section.3.2.6.p.8">Senders <em class="bcp14">SHOULD NOT</em> generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that 1318 string. 1314 1319 </p> 1315 1320 <div id="rule.comment"> 1316 <p id="rfc.section.3.2. 4.p.9"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed1321 <p id="rfc.section.3.2.6.p.9"> Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed 1317 1322 in fields containing "comment" as part of their field value definition. 1318 1323 </p> … … 1321 1326 <a href="#rule.comment" class="smpl">ctext</a> = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21-27 / %x2A-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1322 1327 </pre><div id="rule.quoted-cpair"> 1323 <p id="rfc.section.3.2. 4.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p>1328 <p id="rfc.section.3.2.6.p.11"> The backslash octet ("\") can be used as a single-octet quoting mechanism within comment constructs:</p> 1324 1329 </div> 1325 1330 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1326 </pre><p id="rfc.section.3.2. 4.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and1331 </pre><p id="rfc.section.3.2.6.p.13">Senders <em class="bcp14">SHOULD NOT</em> escape octets in comments that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and 1327 1332 ")"). 1328 1333 </p> … … 1531 1536 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2> 1532 1537 <p id="rfc.section.4.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size 1533 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary1538 indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary 1534 1539 for the recipient to verify that it has received the full message. 1535 1540 </p> … … 2818 2823 <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly 2819 2824 negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0 2820 persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header field to the next inbound server, which would result in a hung connection.2825 persistent connections are faulty; for example, if an HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header field to the next inbound server, which would result in a hung connection. 2821 2826 </p> 2822 2827 <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header field, targeted specifically at proxies. In practice, … … 2843 2848 </p> 2844 2849 <p id="rfc.section.A.2.p.5">Minimum supported sizes for various protocol elements have been suggested, to improve interoperability.</p> 2845 <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section 3.2. 2</a>)2850 <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section 3.2.4</a>) 2846 2851 </p> 2847 2852 <p id="rfc.section.A.2.p.7">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted … … 2861 2866 </p> 2862 2867 <p id="rfc.section.A.2.p.13">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed 2863 where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section 3.2. 1</a>)2868 where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section 3.2.3</a>) 2864 2869 </p> 2865 2870 <p id="rfc.section.A.2.p.14">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been 2866 clarified. (<a href="#field.components" title="Field value components">Section 3.2. 4</a>)2867 </p> 2868 <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section 3.2. 4</a>)2869 </p> 2870 <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section 3.2. 4</a>)2871 clarified. (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 2872 </p> 2873 <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 2874 </p> 2875 <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 2871 2876 </p> 2872 2877 <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a>) … … 2937 2942 <p id="rfc.section.B.p.9">For example, given these ABNF productions:</p> 2938 2943 <div id="rfc.figure.u.63"></div><pre class="text"> example-list = 1#example-list-elmt 2939 example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section 3.2. 4</a>2944 example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section 3.2.6</a> 2940 2945 </pre><p id="rfc.section.B.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p> 2941 2946 <div id="rfc.figure.u.64"></div><pre class="text"> "foo,bar" … … 3103 3108 <li>chunked (Coding Format) <a href="#rfc.iref.c.7">4.1</a></li> 3104 3109 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3105 <li>close <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2 </a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.10"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.12">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3110 <li>close <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.10"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.12">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3106 3111 <li>compress (Coding Format) <a href="#rfc.iref.c.8">4.2.1</a></li> 3107 3112 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3108 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2 </a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.9"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.11">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3113 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2.1</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.9"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.11">6.2.5</a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3109 3114 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li> 3110 3115 </ul> … … 3130 3135 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3131 3136 <li><tt>authority-form</tt> <a href="#rfc.iref.g.82"><b>5.3</b></a></li> 3132 <li><tt>BWS</tt> <a href="#rfc.iref.g.40"><b>3.2. 1</b></a></li>3137 <li><tt>BWS</tt> <a href="#rfc.iref.g.40"><b>3.2.3</b></a></li> 3133 3138 <li><tt>chunk</tt> <a href="#rfc.iref.g.63"><b>4.1</b></a></li> 3134 3139 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.69"><b>4.1</b></a></li> … … 3138 3143 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.64"><b>4.1</b></a></li> 3139 3144 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.62"><b>4.1</b></a></li> 3140 <li><tt>comment</tt> <a href="#rfc.iref.g.49"><b>3.2. 4</b></a></li>3145 <li><tt>comment</tt> <a href="#rfc.iref.g.49"><b>3.2.6</b></a></li> 3141 3146 <li><tt>Connection</tt> <a href="#rfc.iref.g.91"><b>6.1</b></a></li> 3142 3147 <li><tt>connection-option</tt> <a href="#rfc.iref.g.92"><b>6.1</b></a></li> … … 3144 3149 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> 3145 3150 <li>CRLF <a href="#rfc.iref.g.3"><b>1.2</b></a></li> 3146 <li><tt>ctext</tt> <a href="#rfc.iref.g.50"><b>3.2. 4</b></a></li>3151 <li><tt>ctext</tt> <a href="#rfc.iref.g.50"><b>3.2.6</b></a></li> 3147 3152 <li>CTL <a href="#rfc.iref.g.4"><b>1.2</b></a></li> 3148 3153 <li><tt>date2</tt> <a href="#rfc.iref.g.60"><b>4</b></a></li> … … 3167 3172 <li><tt>method</tt> <a href="#rfc.iref.g.29"><b>3.1.1</b></a></li> 3168 3173 <li><tt>obs-fold</tt> <a href="#rfc.iref.g.37"><b>3.2</b></a></li> 3169 <li><tt>obs-text</tt> <a href="#rfc.iref.g.47"><b>3.2. 4</b></a></li>3174 <li><tt>obs-text</tt> <a href="#rfc.iref.g.47"><b>3.2.6</b></a></li> 3170 3175 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3171 3176 <li><tt>origin-form</tt> <a href="#rfc.iref.g.80"><b>5.3</b></a></li> 3172 <li><tt>OWS</tt> <a href="#rfc.iref.g.38"><b>3.2. 1</b></a></li>3177 <li><tt>OWS</tt> <a href="#rfc.iref.g.38"><b>3.2.3</b></a></li> 3173 3178 <li><tt>partial-URI</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> 3174 3179 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> … … 3177 3182 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.88"><b>5.7</b></a></li> 3178 3183 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.90"><b>5.7</b></a></li> 3179 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2. 4</b></a></li>3184 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.6</b></a></li> 3180 3185 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> 3181 3186 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3182 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.51"><b>3.2. 4</b></a></li>3183 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.48"><b>3.2. 4</b></a></li>3187 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.51"><b>3.2.6</b></a></li> 3188 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.48"><b>3.2.6</b></a></li> 3184 3189 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a></li> 3185 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.45"><b>3.2. 4</b></a></li>3190 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.45"><b>3.2.6</b></a></li> 3186 3191 <li><tt>rank</tt> <a href="#rfc.iref.g.78"><b>4.3</b></a></li> 3187 3192 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> … … 3190 3195 <li><tt>request-line</tt> <a href="#rfc.iref.g.28"><b>3.1.1</b></a></li> 3191 3196 <li><tt>request-target</tt> <a href="#rfc.iref.g.79"><b>5.3</b></a></li> 3192 <li><tt>RWS</tt> <a href="#rfc.iref.g.39"><b>3.2. 1</b></a></li>3197 <li><tt>RWS</tt> <a href="#rfc.iref.g.39"><b>3.2.3</b></a></li> 3193 3198 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> 3194 <li><tt>special</tt> <a href="#rfc.iref.g.44"><b>3.2. 4</b></a></li>3199 <li><tt>special</tt> <a href="#rfc.iref.g.44"><b>3.2.6</b></a></li> 3195 3200 <li><tt>start-line</tt> <a href="#rfc.iref.g.27"><b>3.1</b></a></li> 3196 3201 <li><tt>status-code</tt> <a href="#rfc.iref.g.31"><b>3.1.2</b></a></li> … … 3198 3203 <li><tt>t-codings</tt> <a href="#rfc.iref.g.76"><b>4.3</b></a></li> 3199 3204 <li><tt>t-ranking</tt> <a href="#rfc.iref.g.77"><b>4.3</b></a></li> 3200 <li><tt>tchar</tt> <a href="#rfc.iref.g.43"><b>3.2. 4</b></a></li>3205 <li><tt>tchar</tt> <a href="#rfc.iref.g.43"><b>3.2.6</b></a></li> 3201 3206 <li><tt>TE</tt> <a href="#rfc.iref.g.75"><b>4.3</b></a></li> 3202 <li><tt>token</tt> <a href="#rfc.iref.g.42"><b>3.2. 4</b></a></li>3207 <li><tt>token</tt> <a href="#rfc.iref.g.42"><b>3.2.6</b></a></li> 3203 3208 <li><tt>Trailer</tt> <a href="#rfc.iref.g.73"><b>4.1.1</b></a></li> 3204 3209 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a></li> … … 3213 3218 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3214 3219 <li><tt>Via</tt> <a href="#rfc.iref.g.85"><b>5.7</b></a></li> 3215 <li><tt>word</tt> <a href="#rfc.iref.g.41"><b>3.2. 4</b></a></li>3220 <li><tt>word</tt> <a href="#rfc.iref.g.41"><b>3.2.6</b></a></li> 3216 3221 </ul> 3217 3222 </li> … … 3232 3237 <li>interception proxy <a href="#rfc.iref.i.3"><b>2.3</b></a></li> 3233 3238 <li>intermediary <a href="#rfc.iref.i.1"><b>2.3</b></a></li> 3234 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2. 2</a>, <a href="#ISO-8859-1"><b>10.2</b></a></li>3239 <li><em>ISO-8859-1</em> <a href="#rfc.xref.ISO-8859-1.1">3.2.4</a>, <a href="#ISO-8859-1"><b>10.2</b></a></li> 3235 3240 </ul> 3236 3241 </li> 3237 3242 <li><a id="rfc.index.K" href="#rfc.index.K"><b>K</b></a><ul> 3238 <li><em>Kri2001</em> <a href="#rfc.xref.Kri2001.1">3.2 </a>, <a href="#Kri2001"><b>10.2</b></a></li>3243 <li><em>Kri2001</em> <a href="#rfc.xref.Kri2001.1">3.2.2</a>, <a href="#Kri2001"><b>10.2</b></a></li> 3239 3244 </ul> 3240 3245 </li> … … 3262 3267 </li> 3263 3268 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3264 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2 </a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3269 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3265 3270 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3266 3271 <li><em>Section 3.1.1.5</em> <a href="#rfc.xref.Part2.25">5.8</a></li> … … 3284 3289 <li><em>Section 8.4.1</em> <a href="#rfc.xref.Part2.21">5.8</a></li> 3285 3290 <li><em>Section 8.4.2</em> <a href="#rfc.xref.Part2.23">5.8</a></li> 3286 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.10">3.2 </a></li>3291 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> 3287 3292 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3288 3293 </ul> … … 3326 3331 </ul> 3327 3332 </li> 3328 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2. 2</a>, <a href="#RFC2047"><b>10.2</b></a></li>3333 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.4</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3329 3334 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.4">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul> 3330 3335 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li> … … 3380 3385 </ul> 3381 3386 </li> 3382 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2 </a>, <a href="#RFC6265"><b>10.2</b></a></li>3387 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="#RFC6265"><b>10.2</b></a></li> 3383 3388 </ul> 3384 3389 </li> … … 3409 3414 </ul> 3410 3415 </li> 3411 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2. 2</a>, <a href="#USASCII"><b>10.1</b></a></li>3416 <li><em>USASCII</em> <a href="#rfc.xref.USASCII.1">1.2</a>, <a href="#rfc.xref.USASCII.2">3</a>, <a href="#rfc.xref.USASCII.3">3.2.4</a>, <a href="#USASCII"><b>10.1</b></a></li> 3412 3417 <li>user agent <a href="#rfc.iref.u.1"><b>2.1</b></a></li> 3413 3418 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2029 r2030 185 185 </t> 186 186 <t> 187 One consequence of HTTPflexibility is that the protocol cannot be187 One consequence of this flexibility is that the protocol cannot be 188 188 defined in terms of what occurs behind the interface. Instead, we 189 189 are limited to defining the syntax of communication, the intent … … 298 298 The terms client and server refer only to the roles that 299 299 these programs perform for a particular connection. The same program 300 might act as a client on some connections and a server on others. We use 301 the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request, 302 such as a WWW browser, editor, or spider (web-traversing robot), and 303 the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate 304 authoritative responses to a request. For general requirements, we use 305 the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message 306 and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the 307 message. 300 might act as a client on some connections and a server on others. 301 We use the term "<x:dfn>user agent</x:dfn>" to refer to any of the various 302 client programs that initiate a request, including (but not limited to) 303 browsers, spiders (web-based robots), command-line tools, native 304 applications, and mobile apps. The term "<x:dfn>origin server</x:dfn>" is 305 used to refer to the program that can originate authoritative responses to 306 a request. For general requirements, we use the terms 307 "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" to refer to any 308 component that sends or receives, respectively, a given message. 308 309 </t> 309 310 <t> … … 887 888 invocation options, configuration files, or bookmark lists, even 888 889 though such usage might expose a user identifier or password. 889 Senders &MUST -NOT; include auserinfo subcomponent (and its "@"890 delimiter) when transmitting an "http" URI in a message. Recipients891 of HTTP messages that contain a URI reference &SHOULD; parse for the892 existence of userinfo and treat its presence as an error, likely893 indicating that the deprecated subcomponent isbeing used to obscure890 Senders &MUST; exclude the userinfo subcomponent (and its "@" 891 delimiter) when an "http" URI is transmitted within a message as a 892 request target or header field value. 893 Recipients of an "http" URI reference &SHOULD; parse for userinfo and 894 treat its presence as an error, since it is likely being used to obscure 894 895 the authority for the sake of phishing attacks. 895 896 </t> … … 1068 1069 <x:ref>request-line</x:ref> = <x:ref>method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-version</x:ref> <x:ref>CRLF</x:ref> 1069 1070 </artwork></figure> 1070 <t>1071 A server &MUST; be able to parse any received message that begins1072 with a request-line and matches the ABNF rule for HTTP-message.1073 </t>1074 1071 <iref primary="true" item="method"/> 1075 1072 <t anchor="method"> … … 1120 1117 Various ad-hoc limitations on request-line length are found in practice. 1121 1118 It is &RECOMMENDED; that all HTTP senders and recipients support, at a 1122 minimum, request-line lengths of up to8000 octets.1119 minimum, request-line lengths of 8000 octets. 1123 1120 </t> 1124 1121 </section> … … 1138 1135 <x:ref>status-line</x:ref> = <x:ref>HTTP-version</x:ref> <x:ref>SP</x:ref> <x:ref>status-code</x:ref> <x:ref>SP</x:ref> <x:ref>reason-phrase</x:ref> <x:ref>CRLF</x:ref> 1139 1136 </artwork></figure> 1140 <t>1141 A client &MUST; be able to parse any received message that begins1142 with a status-line and matches the ABNF rule for HTTP-message.1143 </t>1144 1137 <t> 1145 1138 The status-code element is a 3-digit integer code describing the … … 1193 1186 timestamp for the message in which it appears. 1194 1187 </t> 1188 1189 <section title="Field Extensibility" anchor="field.extensibility"> 1195 1190 <t> 1196 1191 HTTP header fields are fully extensible: there is no limit on the 1197 1192 introduction of new field names, each presumably defining new semantics, 1198 or on the number of header fields used in a given message. Existing1193 nor on the number of header fields used in a given message. Existing 1199 1194 fields are defined in each part of this specification and in many other 1200 specifications outside the standards process.1195 specifications outside the core standard. 1201 1196 New header fields can be introduced without changing the protocol version 1202 1197 if their defined semantics allow them to be safely ignored by recipients … … 1212 1207 Unrecognized header fields &SHOULD; be ignored by other recipients. 1213 1208 </t> 1209 </section> 1210 1211 <section title="Field Order" anchor="field.order"> 1214 1212 <t> 1215 1213 The order in which header fields with differing field names are … … 1227 1225 sent in a message unless the entire field value for that 1228 1226 header field is defined as a comma-separated list [i.e., #(values)]. 1227 </t> 1228 <t> 1229 1229 Multiple header fields with the same field name can be combined into 1230 1230 one "field-name: field-value" pair, without changing the semantics of the … … 1238 1238 <x:note> 1239 1239 <t> 1240 &Note; The "Set-Cookie" header field as implemented in 1241 practice can occur multiple times, but does not use the list syntax, and 1242 thus cannot be combined into a single line (<xref target="RFC6265"/>). (See Appendix A.2.3 of <xref target="Kri2001"/> 1243 for details.) 1244 </t> 1240 &Note; In practice, the "Set-Cookie" header field (<xref target="RFC6265"/>) 1241 often appears multiple times in a response message and does not use the 1242 list syntax, violating the above requirements on multiple header fields 1243 with the same name. Since it cannot be combined into a single field-value, 1244 recipients ought to handle "Set-Cookie" as a special case while processing 1245 header fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for details.) 1246 </t> 1245 1247 </x:note> 1248 </section> 1246 1249 1247 1250 <section title="Whitespace" anchor="whitespace"> … … 1253 1256 <t anchor="rule.OWS"> 1254 1257 The OWS rule is used where zero or more linear whitespace octets might 1255 appear. OWS &SHOULD; either not be produced or be produced as a single1258 appear. OWS &SHOULD; either not be generated or be generated as a single 1256 1259 SP. Multiple OWS octets that occur within field-content &SHOULD; either 1257 1260 be replaced with a single SP or transformed to all SP octets (each … … 1261 1264 <t anchor="rule.RWS"> 1262 1265 RWS is used when at least one linear whitespace octet is required to 1263 separate field tokens. RWS &SHOULD; be produced as a single SP.1266 separate field tokens. RWS &SHOULD; be generated as a single SP. 1264 1267 Multiple RWS octets that occur within field-content &SHOULD; either 1265 1268 be replaced with a single SP or transformed to all SP octets before … … 1268 1271 <t anchor="rule.BWS"> 1269 1272 BWS is used where the grammar allows optional whitespace, for historical 1270 reasons, but senders &SHOULD-NOT; produce it in messages;1273 reasons, but senders &SHOULD-NOT; generate it in messages; 1271 1274 recipients &MUST; accept such bad optional whitespace and remove it before 1272 1275 interpreting the field value or forwarding the message downstream. … … 1311 1314 folding except within the message/http media type 1312 1315 (<xref target="internet.media.type.message.http"/>). 1313 HTTP senders &MUST-NOT; produce messages that include line folding1316 HTTP senders &MUST-NOT; generate messages that include line folding 1314 1317 (i.e., that contain any field-value that matches the obs-fold rule) unless 1315 1318 the message is intended for packaging within the message/http media type. … … 1331 1334 </section> 1332 1335 1333 <section title="Field Length" anchor="field.length"> 1334 <t> 1335 HTTP does not place a pre-defined limit on the length of header fields, 1336 either in isolation or as a set. A server &MUST; be prepared to receive 1337 request header fields of unbounded length and respond with a <x:ref>4xx 1338 (Client Error)</x:ref> status code if the received header field(s) would be 1339 longer than the server wishes to handle. 1340 </t> 1341 <t> 1342 A client that receives response header fields that are longer than it wishes 1343 to handle can only treat it as a server error. 1344 </t> 1345 <t> 1346 Various ad-hoc limitations on header field length are found in practice. It 1347 is &RECOMMENDED; that all HTTP senders and recipients support messages whose 1348 combined header fields have 4000 or more octets. 1336 <section title="Field Limits" anchor="field.limits"> 1337 <t> 1338 HTTP does not place a pre-defined limit on the length of each header field 1339 or on the length of the header block as a whole. Various ad-hoc 1340 limitations on individual header field length are found in practice, 1341 often depending on the specific field semantics. 1342 </t> 1343 <t> 1344 A server &MUST; be prepared to receive request header fields of unbounded 1345 length and respond with an appropriate <x:ref>4xx (Client Error)</x:ref> 1346 status code if the received header field(s) are larger than the server 1347 wishes to process. 1348 </t> 1349 <t> 1350 A client &MUST; be prepared to receive response header fields of unbounded 1351 length. A client &MAY; discard or truncate received header fields that are 1352 larger than the client wishes to process if the field semantics are such 1353 that the dropped value(s) can be safely ignored without changing the 1354 response semantics. 1349 1355 </t> 1350 1356 </section> … … 1398 1404 </artwork></figure> 1399 1405 <t> 1400 Recipients that process the value of thequoted-string &MUST; handle a1406 Recipients that process the value of a quoted-string &MUST; handle a 1401 1407 quoted-pair as if it were replaced by the octet following the backslash. 1402 1408 </t> 1403 1409 <t> 1404 Senders &SHOULD-NOT; escape octets in quoted-strings that do not require1405 escaping (i.e., other than DQUOTE and the backslash octet).1410 Senders &SHOULD-NOT; generate a quoted-pair in a quoted-string except where 1411 necessary to quote DQUOTE and backslash octets occurring within that string. 1406 1412 </t> 1407 1413 <t anchor="rule.comment"> … … 1891 1897 transfer it as a series of chunks, each with its own size indicator, 1892 1898 followed by an &OPTIONAL; trailer containing header fields. This 1893 allows dynamically produced content to be transferred along with the1899 allows dynamically generated content to be transferred along with the 1894 1900 information necessary for the recipient to verify that it has 1895 1901 received the full message. … … 4702 4708 with a "Connection: keep-alive" request header field. However, some 4703 4709 experimental implementations of HTTP/1.0 persistent connections are faulty; 4704 for example, if a HTTP/1.0 proxy server doesn't understand4710 for example, if an HTTP/1.0 proxy server doesn't understand 4705 4711 <x:ref>Connection</x:ref>, it will erroneously forward that header field 4706 4712 to the next inbound server, which would result in a hung connection. -
draft-ietf-httpbis/latest/p2-semantics.html
r2027 r2030 449 449 } 450 450 @bottom-center { 451 content: "Expires June 4, 2013";451 content: "Expires June 7, 2013"; 452 452 } 453 453 @bottom-right { … … 496 496 <meta name="dct.creator" content="Reschke, J. F."> 497 497 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 1">498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-04"> 499 499 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 500 500 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 524 524 <tr> 525 525 <td class="left">Intended status: Standards Track</td> 526 <td class="right">December 1, 2012</td>526 <td class="right">December 4, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: June 4, 2013</td>529 <td class="left">Expires: June 7, 2013</td> 530 530 <td class="right"></td> 531 531 </tr> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on June 4, 2013.</p>557 <p>This Internet-Draft will expire on June 7, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2651 2651 <div id="rfc.iref.74"></div> 2652 2652 <h3 id="rfc.section.7.5.7"><a href="#rfc.section.7.5.7">7.5.7</a> <a id="status.408" href="#status.408">408 Request Timeout</a></h3> 2653 <p id="rfc.section.7.5.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time. 2653 <p id="rfc.section.7.5.7.p.1">The server did not receive a complete request message within the time that it was prepared to wait. If the client has sent 2654 a request, it <em class="bcp14">MAY</em> repeat that request, possibly on a new connection if the server indicates that the present connection is being closed. 2654 2655 </p> 2655 2656 <div id="rfc.iref.74"></div> … … 3221 3222 a zero-length payload body. 3222 3223 </p> 3223 <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status3224 <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that would cause a response containing that status 3224 3225 code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields 3225 3226 (e.g., what fields are required and what fields can modify the semantics). A response that can transfer a payload ought to … … 3473 3474 <p id="rfc.section.9.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 3474 3475 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 3475 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3476 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3476 3477 </p> 3477 3478 <p id="rfc.section.9.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 3797 3798 </h2> 3798 3799 <p id="rfc.section.10.4.p.1">Since tunneled data is opaque to the proxy, there are additional risks to tunneling to other well-known or reserved ports. 3799 A HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports.3800 An HTTP client CONNECTing to port 25 could relay spam via SMTP, for example. As such, proxies <em class="bcp14">SHOULD</em> restrict CONNECT access to a small number of known ports. 3800 3801 </p> 3801 3802 <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2> … … 4154 4155 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4155 4156 </p> 4156 <p id="rfc.section.C.p.30">The requirement to produce a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>)4157 <p id="rfc.section.C.p.30">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>) 4157 4158 </p> 4158 4159 <p id="rfc.section.C.p.31">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) … … 4181 4182 <p id="rfc.section.D.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>: 4182 4183 </p> 4183 <div id="rfc.figure.u.65"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2. 1</a>>4184 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2. 1</a>>4185 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2. 1</a>>4184 <div id="rfc.figure.u.65"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4185 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4186 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4186 4187 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4187 4188 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4188 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a>>4189 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4189 4190 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 4190 4191 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4191 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a>>4192 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a>>4193 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a>>4192 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4193 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4194 <a href="#imported.abnf" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4194 4195 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 4195 4196 <div id="rfc.figure.u.66"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4541 4542 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a></li> 4542 4543 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">6.5.3</a>, <a href="#rfc.xref.Part1.28">8.4.2</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.52">D</a></li> 4543 <li><em>Section 3.2. 1</em> <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li>4544 <li><em>Section 3.2. 4</em> <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li>4544 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a></li> 4545 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a>, <a href="#rfc.xref.Part1.56">D</a></li> 4545 4546 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.14">3.3</a></li> 4546 4547 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.24">7.3.6</a>, <a href="#rfc.xref.Part1.30">9.1.2</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2027 r2030 3222 3222 <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/> 3223 3223 <t> 3224 The client did not produce a request within the time that the server 3225 was prepared to wait. The client &MAY; repeat the request without 3226 modifications at any later time. 3224 The server did not receive a complete request message within the time that 3225 it was prepared to wait. If the client has sent a request, it &MAY; repeat 3226 that request, possibly on a new connection if the server indicates that the 3227 present connection is being closed. 3227 3228 </t> 3228 3229 </section> … … 4124 4125 <t> 4125 4126 A definition for a new status code ought to explain the request 4126 conditions that produce a response containing that status code (e.g.,4127 conditions that would cause a response containing that status code (e.g., 4127 4128 combinations of request header fields and/or method(s)) along with any 4128 4129 dependencies on response header fields (e.g., what fields are required … … 4755 4756 Since tunneled data is opaque to the proxy, there are additional 4756 4757 risks to tunneling to other well-known or reserved ports. 4757 A HTTP client CONNECTing to port 25 could relay spam4758 An HTTP client CONNECTing to port 25 could relay spam 4758 4759 via SMTP, for example. As such, proxies &SHOULD; restrict CONNECT 4759 4760 access to a small number of known ports. … … 5806 5807 </t> 5807 5808 <t> 5808 The requirement to produce a <x:ref>Via</x:ref> header field has been moved5809 The requirement to generate a <x:ref>Via</x:ref> header field has been moved 5809 5810 from the description of the <x:ref>Server</x:ref> header field to 5810 5811 &header-via;. -
draft-ietf-httpbis/latest/p6-cache.html
r2027 r2030 452 452 } 453 453 @bottom-center { 454 content: "Expires June 4, 2013";454 content: "Expires June 7, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 1">500 <meta name="dct.issued" scheme="ISO8601" content="2012-12-04"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: June 4, 2013</td>526 <td class="left">Expires: June 7, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">December 1, 2012</td>535 <td class="right">December 4, 2012</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on June 4, 2013.</p>561 <p>This Internet-Draft will expire on June 7, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 700 700 </p> 701 701 <ul class="empty"> 702 <li>A conformant implementation of a HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define702 <li>A conformant implementation of an HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define 703 703 conformance for HTTP/1.0 caches. 704 704 </li> … … 1436 1436 <p id="rfc.section.7.3.p.8">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes 1437 1437 are no longer prohibited, extremely large values have been demonstrated to cause problems (e.g., clock overflows due to use 1438 of 32-bit integers for time values), and many caches will evict a response far sooner than that. Therefore, senders ought 1439 not produce them. 1438 of 32-bit integers for time values), and many caches will evict a response far sooner than that. 1440 1439 </p> 1441 1440 <p id="rfc.section.7.3.p.9">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires values to a response unless these values were associated with the resource by a system or user with a reliable … … 1947 1946 <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>: 1948 1947 </p> 1949 <div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2. 1</a>>1948 <div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 1950 1949 <a href="#imported.abnf" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 1951 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a>>1952 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2. 4</a>>1950 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 1951 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 1953 1952 1954 1953 <a href="#imported.abnf" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> … … 2126 2125 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.17">B</a></li> 2127 2126 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.12">B</a></li> 2128 <li><em>Section 3.2. 1</em> <a href="#rfc.xref.Part1.11">B</a></li>2129 <li><em>Section 3.2. 4</em> <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a></li>2127 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.11">B</a></li> 2128 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a></li> 2130 2129 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a></li> 2131 2130 <li><em>Section 5.7</em> <a href="#rfc.xref.Part1.16">B</a></li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2027 r2030 175 175 <x:dfn>cache</x:dfn> 176 176 <list> 177 <t>A conformant implementation of a HTTP cache. Note that this implies177 <t>A conformant implementation of an HTTP cache. Note that this implies 178 178 an HTTP/1.1 cache; this specification does not define conformance 179 179 for HTTP/1.0 caches.</t> … … 1626 1626 problems (e.g., clock overflows due to use of 32-bit integers for 1627 1627 time values), and many caches will evict a response far sooner than 1628 that. Therefore, senders ought not produce them.1628 that. 1629 1629 </t> 1630 1630 <t>
Note: See TracChangeset
for help on using the changeset viewer.