Changeset 1171
- Timestamp:
- 13/03/11 06:51:57 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1170 r1171 717 717 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 718 718 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 719 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 request targets and relationships between resources. Messages are passed in a format similar to that used by Internet720 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="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).719 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 and relationships between resources. Messages are passed in a format similar to that used 720 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="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 721 721 </p> 722 722 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented … … 927 927 and response structures onto the data units of the underlying transport protocol is outside the scope of this specification. 928 928 </p> 929 <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the identifier930 (if any) provided for the request target. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.6.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use929 <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's 930 URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section 2.6.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use 931 931 a proxy via some other connection port or protocol instead of using the defaults. 932 932 </p> … … 1078 1078 </p> 1079 1079 <p id="rfc.section.2.6.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "port", "host", "path-abempty", 1080 "path-absolute", "query", and "authority" from <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI without a fragment.1080 "path-absolute", "query", and "authority" from the URI generic syntax <a href="#RFC3986" id="rfc.xref.RFC3986.4"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>. In addition, we define a partial-URI rule for protocol elements that allow a relative URI but not a fragment. 1081 1081 </p> 1082 1082 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#uri" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.5"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>> … … 1092 1092 <a href="#uri" class="smpl">partial-URI</a> = relative-part [ "?" query ] 1093 1093 </pre><p id="rfc.section.2.6.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows 1094 only a URI in absolute form (absolute-URI), any relative reference (relative-ref), or some other subset of the URI-reference1095 grammar. Unless otherwise indicated, URI references are parsed relative to the request target (the default base URI for both1096 the request and its corresponding response).1094 any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components, 1095 or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request 1096 URI, which defines the default base URI for references in both the request and its corresponding response. 1097 1097 </p> 1098 1098 <h3 id="rfc.section.2.6.1"><a href="#rfc.section.2.6.1">2.6.1</a> <a id="http.uri" href="#http.uri">http URI scheme</a></h3> … … 1100 1100 <div id="rfc.iref.u.3"></div> 1101 1101 <p id="rfc.section.2.6.1.p.1">The "http" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical 1102 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. The HTTP server is identified 1103 via the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port, and the remainder of the URI is considered to be identifying 1104 data corresponding to a resource for which that server might provide an HTTP interface. 1102 namespace governed by a potential HTTP origin server listening for TCP connections on a given port. 1105 1103 </p> 1106 1104 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#http.uri" class="smpl">http-URI</a> = "http:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1107 </pre><p id="rfc.section.2.6.1.p.3">The host identifier within an <a href="#uri" class="smpl">authority</a> component is defined in <a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>. If host is provided as an IP literal or IPv4 address, then the HTTP server is any listener on the indicated TCP port at 1108 that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient might 1109 use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved 1105 </pre><p id="rfc.section.2.6.1.p.3">The HTTP origin server is identified by the generic syntax's <a href="#uri" class="smpl">authority</a> component, which includes a host identifier and optional TCP port (<a href="#RFC3986" id="rfc.xref.RFC3986.14"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.2">Section 3.2.2</a>). The remainder of the URI, consisting of both the hierarchical path component and optional query component, serves as an 1106 identifier for a potential resource within that origin server's name space. 1107 </p> 1108 <p id="rfc.section.2.6.1.p.4">If the host identifier is provided as an IP literal or IPv4 address, then the origin server is any listener on the indicated 1109 TCP port at that IP address. If host is a registered name, then that name is considered an indirect identifier and the recipient 1110 might use a name resolution service, such as DNS, to find the address of a listener for that host. The host <em class="bcp14">MUST NOT</em> be empty; if an "http" URI is received with an empty host, then it <em class="bcp14">MUST</em> be rejected as invalid. If the port subcomponent is empty or not given, then TCP port 80 is assumed (the default reserved 1110 1111 port for WWW services). 1111 1112 </p> 1112 <p id="rfc.section.2.6.1.p. 4">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address.1113 <p id="rfc.section.2.6.1.p.5">Regardless of the form of host identifier, access to that host is not implied by the mere presence of its name or address. 1113 1114 The host might or might not exist and, even when it does exist, might or might not be running an HTTP server or listening 1114 1115 to the indicated port. The "http" URI scheme makes use of the delegated nature of Internet names and addresses to establish … … 1116 1117 authority to determine which names are valid and how they might be used. 1117 1118 </p> 1118 <p id="rfc.section.2.6.1.p. 5">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,1119 <p id="rfc.section.2.6.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1119 1120 and sending an HTTP request message to the server containing the URI's identifying data as described in <a href="#request" title="Request">Section 4</a>. If the server responds to that request with a non-interim HTTP response message, as described in <a href="#response" title="Response">Section 5</a>, then that response is considered an authoritative answer to the client's request. 1120 1121 </p> 1121 <p id="rfc.section.2.6.1.p. 6">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name1122 <p id="rfc.section.2.6.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name 1122 1123 delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 1123 1124 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require … … 1125 1126 — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1126 1127 </p> 1127 <p id="rfc.section.2.6.1.p. 7">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><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 internal1128 <p id="rfc.section.2.6.1.p.8">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><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 1128 1129 configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, 1129 1130 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 messages … … 1141 1142 </p> 1142 1143 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] 1143 </pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus are ineligible for shared caching.1144 Their default is "private" and might be further constrained via use ofthe Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1144 </pre><p id="rfc.section.2.6.2.p.4">Unlike the "http" scheme, responses to "https" identified requests are never "public" and thus <em class="bcp14">MUST NOT</em> be reused for shared caching. They can, however, be reused in a private cache if the message is cacheable by default in HTTP 1145 or specifically indicated as such by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1145 1146 </p> 1146 1147 <p id="rfc.section.2.6.2.p.5">Resources made available via the "https" scheme have no shared identity with the "http" scheme even if their resource identifiers 1147 only differ by the single "s" in the scheme name. They are different services governed by different authorities. However,1148 some extensions to HTTP that apply to entire host domains, such as the Cookie protocol, do allow one service to effect communication1149 with the other services based on host domain matching.1148 indicate the same authority (the same host listening to the same TCP port). They are distinct name spaces and are considered 1149 to be distinct origin servers. However, an extension to HTTP that is defined to apply to entire host domains, such as the 1150 Cookie protocol <a href="#draft-ietf-httpstate-cookie" id="rfc.xref.draft-ietf-httpstate-cookie.1"><cite title="HTTP State Management Mechanism">[draft-ietf-httpstate-cookie]</cite></a>, can allow information set by one service to impact communication with other services within a matching group of host domains. 1150 1151 </p> 1151 1152 <p id="rfc.section.2.6.2.p.6">The process for authoritative access to an "https" identified resource is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. … … 1164 1165 http://EXAMPLE.com/%7Esmith/home.html 1165 1166 http://EXAMPLE.com:/%7esmith/home.html 1166 </pre><p id="rfc.section.2.6.3.p.5"> <span class="comment" id="TODO-not-here">[<a href="#TODO-not-here" class="smpl">TODO-not-here</a>: This paragraph does not belong here. --roy]</span> If path-abempty is the empty string (i.e., there is no slash "/" path separator following the authority), then the "http" 1167 URI <em class="bcp14">MUST</em> be given as "/" when used as a request-target (<a href="#request-target" title="request-target">Section 4.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1168 </p> 1169 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="http.message" href="#http.message">HTTP Message</a></h1> 1167 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="http.message" href="#http.message">HTTP Message</a></h1> 1170 1168 <div id="rfc.iref.h.3"></div> 1171 1169 <div id="rfc.iref.h.4"></div> … … 1236 1234 <div class="note" id="rfc.section.3.2.p.7"> 1237 1235 <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 1238 cannot be combined into a single line (<a href="#draft-ietf-httpstate-cookie" id="rfc.xref.draft-ietf-httpstate-cookie. 1"><cite title="HTTP State Management Mechanism">[draft-ietf-httpstate-cookie]</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.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.1236 cannot be combined into a single line (<a href="#draft-ietf-httpstate-cookie" id="rfc.xref.draft-ietf-httpstate-cookie.2"><cite title="HTTP State Management Mechanism">[draft-ietf-httpstate-cookie]</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.) Also note that the Set-Cookie2 header field specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem. 1239 1237 </p> 1240 1238 </div> … … 1410 1408 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.47"></span> <a href="#method" class="smpl">Method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1411 1409 </pre><h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="request-target" href="#request-target">request-target</a></h3> 1412 <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request.</p> 1410 <p id="rfc.section.4.1.2.p.1">The request-target identifies the target resource upon which to apply the request. In most cases, the user agent is provided 1411 a URI reference from which it determines an absolute URI for identifying the target resource. When a request to the resource 1412 is initiated, all or part of that URI is used to construct the HTTP request-target. 1413 </p> 1413 1414 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.48"></span> <a href="#request-target" class="smpl">request-target</a> = "*" 1414 1415 / <a href="#uri" class="smpl">absolute-URI</a> … … 1416 1417 / <a href="#uri" class="smpl">authority</a> 1417 1418 </pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p> 1418 <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.2"></span> The asterisk "*" ("asterisk form") means that the request does not apply to a particular resource, but to the server itself.1419 This is only allowed for the OPTIONS request method. Thus, the only valid example is1419 <p id="rfc.section.4.1.2.p.4"><span id="rfc.iref.a.2"></span> The asterisk "*" form of request-target, which <em class="bcp14">MUST NOT</em> be used with any request method other than OPTIONS, means that the request applies to the server as a whole (the listening 1420 process) rather than to a specific named resource at that server. For example, 1420 1421 </p> 1421 1422 <div id="rfc.figure.u.31"></div><pre class="text2">OPTIONS * HTTP/1.1 1422 </pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,1423 andreturn the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request1424 loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example1425 Request-Line would be:1423 </pre><p id="rfc.section.4.1.2.p.6"><span id="rfc.iref.a.3"></span> The "absolute-URI" form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to either forward the request or service it from a valid 1424 cache, and then return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request 1425 loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, and the numeric IP 1426 address. An example Request-Line would be: 1426 1427 </p> 1427 1428 <div id="rfc.figure.u.32"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1428 1429 </pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1429 1430 </p> 1430 <p id="rfc.section.4.1.2.p.9"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1431 </p> 1432 <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.p.2"></span> The most common form of request-target is that used to identify a resource on an origin server or gateway ("path-absolute 1433 form"). In this case the absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>, path-absolute) as the request-target, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin 1434 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1431 <p id="rfc.section.4.1.2.p.9">If a proxy receives a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1432 </p> 1433 <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1434 </p> 1435 <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server or gateway ("origin form"). 1436 In this case, the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified 1437 above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and 1438 send the lines: 1435 1439 </p> 1436 1440 <div id="rfc.figure.u.33"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1 1437 1441 Host: www.example.org 1438 </pre><p id="rfc.section.4.1.2.p.12">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original 1439 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). 1440 </p> 1441 <p id="rfc.section.4.1.2.p.13">If a proxy receives an OPTIONS request without any path in the request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target. 1442 </pre><p id="rfc.section.4.1.2.p.13">followed by the remainder of the Request. Note that the origin form of request-target always starts with an absolute path; 1443 if the target resource's URI path is empty, then an absolute path of "/" <em class="bcp14">MUST</em> be provided in the request-target. 1444 </p> 1445 <p id="rfc.section.4.1.2.p.14">If a proxy receives an OPTIONS request with an absolute-URI form of request-target in which the URI has an empty path and 1446 no query component, then the last proxy on the request chain <em class="bcp14">MUST</em> use a request-target of "*" when it forwards the request to the indicated origin server. 1442 1447 </p> 1443 1448 <div id="rfc.figure.u.34"></div> … … 1447 1452 Host: www.example.org:8001 1448 1453 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1449 <p id="rfc.section.4.1.2.p.1 6">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.1450 </p> 1451 <p id="rfc.section.4.1.2.p.1 7">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted1454 <p id="rfc.section.4.1.2.p.17">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1455 </p> 1456 <p id="rfc.section.4.1.2.p.18">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted 1452 1457 above to replace a null path-absolute with "/" or "*". 1453 1458 </p> 1454 <div class="note" id="rfc.section.4.1.2.p.1 8">1459 <div class="note" id="rfc.section.4.1.2.p.19"> 1455 1460 <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1456 1461 a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been … … 1458 1463 </p> 1459 1464 </div> 1460 <p id="rfc.section.4.1.2.p. 19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target1465 <p id="rfc.section.4.1.2.p.20">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1461 1466 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1462 1467 </p> 1463 <p id="rfc.section.4.1.2.p.2 0">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.1464 </p> 1465 <div class="note" id="rfc.section.4.1.2.p.2 1">1468 <p id="rfc.section.4.1.2.p.21">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets. 1469 </p> 1470 <div class="note" id="rfc.section.4.1.2.p.22"> 1466 1471 <p> <b>Note:</b> Fragments (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>) are not part of the request-target and thus will not be transmitted in an HTTP request. 1467 1472 </p> … … 3613 3618 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.2.2.2</a></li> 3614 3619 <li>downstream <a href="#rfc.iref.d.1"><b>2.3</b></a></li> 3615 <li><em>draft-ietf-httpstate-cookie</em> <a href="#rfc.xref.draft-ietf-httpstate-cookie.1"> 3.2</a>, <a href="#draft-ietf-httpstate-cookie"><b>13.2</b></a></li>3620 <li><em>draft-ietf-httpstate-cookie</em> <a href="#rfc.xref.draft-ietf-httpstate-cookie.1">2.6.2</a>, <a href="#rfc.xref.draft-ietf-httpstate-cookie.2">3.2</a>, <a href="#draft-ietf-httpstate-cookie"><b>13.2</b></a></li> 3616 3621 </ul> 3617 3622 </li> … … 3794 3799 </li> 3795 3800 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 3801 <li>origin form (of request-target) <a href="#rfc.iref.o.3">4.1.2</a></li> 3796 3802 <li>origin server <a href="#rfc.iref.o.1"><b>2.1</b></a></li> 3797 3803 <li>outbound <a href="#rfc.iref.o.2"><b>2.3</b></a></li> … … 3824 3830 </ul> 3825 3831 </li> 3826 <li>path-absolute form (of request-target) <a href="#rfc.iref.p.2">4.1.2</a></li>3827 3832 <li>proxy <a href="#rfc.iref.p.1"><b>2.3</b></a></li> 3828 3833 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1170 r1171 229 229 message payloads for flexible interaction with network-based hypertext 230 230 information systems. HTTP relies upon the Uniform Resource Identifier (URI) 231 standard <xref target="RFC3986"/> to indicate request targetsand231 standard <xref target="RFC3986"/> to indicate the target resource and 232 232 relationships between resources. 233 233 Messages are passed in a format similar to that used by Internet mail … … 625 625 <t> 626 626 The specific connection protocols to be used for an interaction 627 are determined by client configuration and the identifier (if any)628 provided for the request target.For example, the "http" URI scheme627 are determined by client configuration and the target resource's URI. 628 For example, the "http" URI scheme 629 629 (<xref target="http.uri"/>) indicates a default connection of TCP 630 630 over IP, with a default TCP port of 80, but the client might be … … 942 942 This specification adopts the definitions of "URI-reference", 943 943 "absolute-URI", "relative-part", "port", "host", 944 "path-abempty", "path-absolute", "query", and "authority" from 945 <xref target="RFC3986"/>. In addition, we define a partial-URI rule for 946 protocol elements that allow a relative URI without a fragment. 944 "path-abempty", "path-absolute", "query", and "authority" from the 945 URI generic syntax <xref target="RFC3986"/>. 946 In addition, we define a partial-URI rule for protocol elements 947 that allow a relative URI but not a fragment. 947 948 </t> 948 949 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="URI-reference"/><iref primary="true" item="Grammar" subitem="absolute-URI"/><iref primary="true" item="Grammar" subitem="authority"/><iref primary="true" item="Grammar" subitem="path-absolute"/><iref primary="true" item="Grammar" subitem="port"/><iref primary="true" item="Grammar" subitem="query"/><iref primary="true" item="Grammar" subitem="uri-host"/> … … 960 961 </artwork></figure> 961 962 <t> 962 Each protocol element in HTTP that allows a URI reference will indicate in 963 its ABNF production whether the element allows only a URI in absolute form 964 (absolute-URI), any relative reference (relative-ref), or some other subset 965 of the URI-reference grammar. Unless otherwise indicated, URI references 966 are parsed relative to the request target (the default base URI for both 967 the request and its corresponding response). 963 Each protocol element in HTTP that allows a URI reference will indicate 964 in its ABNF production whether the element allows any form of reference 965 (URI-reference), only a URI in absolute form (absolute-URI), only the 966 path and optional query components, or some combination of the above. 967 Unless otherwise indicated, URI references are parsed relative to the 968 effective request URI, which defines the default base URI for references 969 in both the request and its corresponding response. 968 970 </t> 969 971 … … 977 979 namespace governed by a potential HTTP origin server listening for 978 980 TCP connections on a given port. 979 The HTTP server is identified via the generic syntax's980 <x:ref>authority</x:ref> component, which includes a host981 identifier and optional TCP port, and the remainder of the URI is982 considered to be identifying data corresponding to a resource for983 which that server might provide an HTTP interface.984 981 </t> 985 982 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/> … … 987 984 </artwork></figure> 988 985 <t> 989 The host identifier within an <x:ref>authority</x:ref> component is 990 defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>. If host is 991 provided as an IP literal or IPv4 address, then the HTTP server is any 992 listener on the indicated TCP port at that IP address. If host is a 993 registered name, then that name is considered an indirect identifier 994 and the recipient might use a name resolution service, such as DNS, 995 to find the address of a listener for that host. 986 The HTTP origin server is identified by the generic syntax's 987 <x:ref>authority</x:ref> component, which includes a host identifier 988 and optional TCP port (<xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>). 989 The remainder of the URI, consisting of both the hierarchical path 990 component and optional query component, serves as an identifier for 991 a potential resource within that origin server's name space. 992 </t> 993 <t> 994 If the host identifier is provided as an IP literal or IPv4 address, 995 then the origin server is any listener on the indicated TCP port at 996 that IP address. If host is a registered name, then that name is 997 considered an indirect identifier and the recipient might use a name 998 resolution service, such as DNS, to find the address of a listener 999 for that host. 996 1000 The host &MUST-NOT; be empty; if an "http" URI is received with an 997 1001 empty host, then it &MUST; be rejected as invalid. … … 1070 1074 <t> 1071 1075 Unlike the "http" scheme, responses to "https" identified requests 1072 are never "public" and thus are ineligible for shared caching. 1073 Their default is "private" and might be further constrained via use 1074 of the Cache-Control header field (&header-cache-control;). 1076 are never "public" and thus &MUST-NOT; be reused for shared caching. 1077 They can, however, be reused in a private cache if the message is 1078 cacheable by default in HTTP or specifically indicated as such by 1079 the Cache-Control header field (&header-cache-control;). 1075 1080 </t> 1076 1081 <t> 1077 1082 Resources made available via the "https" scheme have no shared 1078 1083 identity with the "http" scheme even if their resource identifiers 1079 only differ by the single "s" in the scheme name. They are 1080 different services governed by different authorities. However, 1081 some extensions to HTTP that apply to entire host domains, such 1082 as the Cookie protocol, do allow one service to effect communication 1083 with the other services based on host domain matching. 1084 indicate the same authority (the same host listening to the same 1085 TCP port). They are distinct name spaces and are considered to be 1086 distinct origin servers. However, an extension to HTTP that is 1087 defined to apply to entire host domains, such as the Cookie protocol 1088 <xref target="draft-ietf-httpstate-cookie"/>, can allow information 1089 set by one service to impact communication with other services 1090 within a matching group of host domains. 1084 1091 </t> 1085 1092 <t> … … 1115 1122 http://EXAMPLE.com:/%7esmith/home.html 1116 1123 </artwork></figure> 1117 <t>1118 <cref anchor="TODO-not-here" source="roy">This paragraph does not belong here.</cref>1119 If path-abempty is the empty string (i.e., there is no slash "/"1120 path separator following the authority), then the "http" URI1121 &MUST; be given as "/" when1122 used as a request-target (<xref target="request-target"/>). If a proxy1123 receives a host name which is not a fully qualified domain name, it1124 &MAY; add its domain to the host name it received. If a proxy receives1125 a fully qualified domain name, the proxy &MUST-NOT; change the host1126 name.1127 </t>1128 1124 </section> 1129 1125 </section> … … 1582 1578 <x:anchor-alias value="request-target"/> 1583 1579 <t> 1584 The request-target identifies the target resource upon which to apply the request. 1580 The request-target identifies the target resource upon which to apply 1581 the request. In most cases, the user agent is provided a URI reference 1582 from which it determines an absolute URI for identifying the target 1583 resource. When a request to the resource is initiated, all or part 1584 of that URI is used to construct the HTTP request-target. 1585 1585 </t> 1586 1586 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/> … … 1595 1595 </t> 1596 1596 <t><iref item="asterisk form (of request-target)"/> 1597 The asterisk "*" ("asterisk form") means that the request does not apply to a 1598 particular resource, but to the server itself. This is only allowed for the 1599 OPTIONS request method. Thus, the only valid example is 1597 The asterisk "*" form of request-target, which &MUST-NOT; be used 1598 with any request method other than OPTIONS, means that the request 1599 applies to the server as a whole (the listening process) rather than 1600 to a specific named resource at that server. For example, 1600 1601 </t> 1601 1602 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 1604 1605 <t><iref item="absolute-URI form (of request-target)"/> 1605 1606 The "absolute-URI" form is &REQUIRED; when the request is being made to a 1606 proxy. The proxy is requested to forward the request or service it1607 from a valid cache, and return the response. Note that the proxy &MAY;1607 proxy. The proxy is requested to either forward the request or service it 1608 from a valid cache, and then return the response. Note that the proxy &MAY; 1608 1609 forward the request on to another proxy or directly to the server 1609 1610 specified by the absolute-URI. In order to avoid request loops, a 1610 proxy &MUST; be able to recognize all of its server names, including 1611 proxy that forwards requests to other proxies &MUST; be able to 1612 recognize and exclude all of its own server names, including 1611 1613 any aliases, local variations, and the numeric IP address. An example 1612 1614 Request-Line would be: … … 1621 1623 them in requests to proxies. 1622 1624 </t> 1625 <t> 1626 If a proxy receives a host name that is not a fully qualified domain 1627 name, it &MAY; add its domain to the host name it received. If a proxy 1628 receives a fully qualified domain name, the proxy &MUST-NOT; change 1629 the host name. 1630 </t> 1623 1631 <t><iref item="authority form (of request-target)"/> 1624 1632 The "authority form" is only used by the CONNECT request method (&CONNECT;). 1625 1633 </t> 1626 <t><iref item=" path-absoluteform (of request-target)"/>1627 The most common form of request-target is that used to identify a1628 resource on an origin server or gateway ("path-absolute form"). In this case the absolute1629 path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as1630 the request-target, and the network location of the URI (authority) &MUST;1631 be transmitted in a Host header field. For example, a client wishing1632 to retrieve the resource above directly from the origin server would1633 create a TCP connection to port 80 of the host "www.example.org" and send1634 t he lines:1634 <t><iref item="origin form (of request-target)"/> 1635 The most common form of request-target is that used when making 1636 a request to an origin server or gateway ("origin form"). 1637 In this case, the absolute path and query components of the URI 1638 &MUST; be transmitted as the request-target, and the authority component 1639 &MUST; be transmitted in a Host header field. For example, a client wishing 1640 to retrieve a representation of the resource, as identified above, 1641 directly from the origin server would open (or reuse) a TCP connection 1642 to port 80 of the host "www.example.org" and send the lines: 1635 1643 </t> 1636 1644 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 1639 1647 </artwork></figure> 1640 1648 <t> 1641 followed by the remainder of the Request. Note that the absolute path 1642 cannot be empty; if none is present in the original URI, it &MUST; be 1643 given as "/" (the server root). 1644 </t> 1645 <t> 1646 If a proxy receives an OPTIONS request without any path in the 1647 request-target, then the last proxy on the request chain &MUST; 1648 forward the request with "*" as the final request-target. 1649 followed by the remainder of the Request. Note that the origin form 1650 of request-target always starts with an absolute path; if the target 1651 resource's URI path is empty, then an absolute path of "/" &MUST; be 1652 provided in the request-target. 1653 </t> 1654 <t> 1655 If a proxy receives an OPTIONS request with an absolute-URI form of 1656 request-target in which the URI has an empty path and no query component, 1657 then the last proxy on the request chain &MUST; use a request-target 1658 of "*" when it forwards the request to the indicated origin server. 1649 1659 </t> 1650 1660 <figure><preamble>
Note: See TracChangeset
for help on using the changeset viewer.