Ignore:
Timestamp:
15/11/08 00:44:55 (12 years ago)
Author:
julian.reschke@…
Message:

Merge in Roy's changes wrt Introduction and HTTP Architecture, replace Request-URI by request-target and relative-URI by partial-URI throughout.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r390 r391  
    230230   The Hypertext Transfer Protocol (HTTP) is an application-level
    231231   request/response protocol that uses extensible semantics and MIME-like
    232    message payloads for flexible interaction with network-based hypermedia
     232   message payloads for flexible interaction with network-based hypertext
    233233   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
    234    standard <xref target="RFC3986"/> to indicate resource targets for
    235    interaction and to identify other resources.
     234   standard <xref target="RFC3986"/> to indicate resource targets and
     235   relationships between resources.
    236236   Messages are passed in a format similar to that used by Internet mail
    237237   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
    238238   (MIME) <xref target="RFC2045"/> (see &diff2045entity; for the differences
    239239   between HTTP and MIME messages).
     240</t>
     241<t>
     242   HTTP is a generic interface protocol for informations systems. It is
     243   designed to hide the details of how a service is implemented by presenting
     244   a uniform interface to clients that is independent of the types of
     245   resources provided. Likewise, servers do not need to be aware of each
     246   client's purpose: an HTTP request can be considered in isolation rather
     247   than being associated with a specific type of client or a predetermined
     248   sequence of application steps. The result is a protocol that can be used
     249   effectively in many different contexts and for which implementations can
     250   evolve independently over time.
    240251</t>
    241252<t>
    … …  
    251262</t>
    252263<t>
     264   One consequence of HTTP flexibility is that we cannot define the protocol
     265   in terms of how to implement it behind the interface. Instead, we are
     266   limited to restricting the syntax of communication, defining the intent
     267   of received communication, and the expected behavior of recipients. If
     268   the communication is considered in isolation, then successful actions
     269   should be reflected in the observable interface provided by servers.
     270   However, since many clients are potentially acting in parallel and
     271   perhaps at cross-purposes, it would be meaningless to require that such
     272   behavior be observable.
     273</t>
     274<t>
    253275   This document is Part 1 of the seven-part specification of HTTP,
    254276   defining the protocol referred to as "HTTP/1.1" and obsoleting
    255277   <xref target="RFC2616"/>.
    256    Part 1 defines how clients determine when to use HTTP, the URI schemes
    257    specific to HTTP-based resources, overall network operation with
    258    transport protocol connection management, and HTTP message framing.
     278   Part 1 defines the URI schemes specific to HTTP-based resources, overall
     279   network operation, transport protocol connection management, and HTTP
     280   message framing and forwarding requirements.
    259281   Our goal is to define all of the mechanisms necessary for HTTP message
    260282   handling that are independent of message semantics, thereby defining the
    261    complete set of requirements for an HTTP message relay or generic
    262    message parser.
     283   complete set of requirements for a message parser and transparent
     284   message-forwarding intermediaries.
    263285</t>
    264286
    … …  
    503525
    504526</section>
     527</section>
     528
     529<section title="HTTP architecture" anchor="architecture">
     530<t>
     531   HTTP was created with a specific architecture in mind, the World Wide Web,
     532   and has evolved over time to support the scalability needs of a worldwide
     533   hypertext system. Much of that architecture is reflected in the terminology
     534   and syntax productions used to define HTTP.
     535</t>
     536
     537<section title="Uniform Resource Identifiers" anchor="uri">
     538<t>
     539   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used
     540   throughout HTTP as the means for identifying resources. URI references
     541   are used to target requests, redirect responses, and define relationships.
     542   HTTP does not limit what a resource may be; it merely defines an interface
     543   that can be used to interact with a resource via HTTP. More information on
     544   the scope of URIs and resources can be found in <xref target="RFC3986"/>.
     545</t>
     546  <x:anchor-alias value="URI"/>
     547  <x:anchor-alias value="URI-reference"/>
     548  <x:anchor-alias value="absolute-URI"/>
     549  <x:anchor-alias value="relative-part"/>
     550  <x:anchor-alias value="authority"/>
     551  <x:anchor-alias value="fragment"/>
     552  <x:anchor-alias value="path-abempty"/>
     553  <x:anchor-alias value="path-absolute"/>
     554  <x:anchor-alias value="port"/>
     555  <x:anchor-alias value="query"/>
     556  <x:anchor-alias value="uri-host"/>
     557  <x:anchor-alias value="partial-URI"/>
     558<t>
     559   This specification adopts the definitions of "URI-reference",
     560   "absolute-URI", "relative-part", "fragment", "port", "host",
     561   "path-abempty", "path-absolute", "query", and "authority" from
     562   <xref target="RFC3986"/>. In addition, we define a partial-URI rule for
     563   protocol elements that allow a relative URI without a fragment.
     564</t>
     565<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"/>
     566  <x:ref>URI</x:ref>           = &lt;URI, defined in <xref target="RFC3986" x:fmt="," x:sec="3"/>>
     567  <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in <xref target="RFC3986" x:fmt="," x:sec="4.1"/>>
     568  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
     569  <x:ref>relative-part</x:ref> = &lt;relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>
     570  <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
     571  <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
     572  <x:ref>path-abempty</x:ref>  = &lt;path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
     573  <x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
     574  <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>
     575  <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
     576  <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>
     577 
     578  <x:ref>partial-URI</x:ref>   = relative-part [ "?" query ]
     579</artwork></figure>
     580<t>
     581   Each protocol element in HTTP that allows a URI reference will indicate in
     582   its ABNF production whether the element allows only a URI in absolute form
     583   (absolute-URI), any relative reference (relative-ref), or some other subset
     584   of the URI-reference grammar. Unless otherwise indicated, URI references
     585   are parsed relative to the request target (the default base URI for both
     586   the request and its corresponding response).
     587</t>
     588
     589<section title="http URI scheme" anchor="http.uri">
     590  <x:anchor-alias value="http-URI"/>
     591  <iref item="http URI scheme" primary="true"/>
     592  <iref item="URI scheme" subitem="http" primary="true"/>
     593<t>
     594   The "http" scheme is used to locate network resources via the HTTP
     595   protocol. This section defines the syntax and semantics for identifiers
     596   using the http or https URI schemes.
     597</t>
     598<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/>
     599  <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
     600</artwork></figure>
     601<t>
     602   If the port is empty or not given, port 80 is assumed. The semantics
     603   are that the identified resource is located at the server listening
     604   for TCP connections on that port of that host, and the request-target
     605   for the resource is path-absolute (<xref target="request-target"/>). The use of IP addresses
     606   in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
     607   the path-absolute is not present in the URL, it &MUST; be given as "/" when
     608   used as a request-target for a resource (<xref target="request-target"/>). If a proxy
     609   receives a host name which is not a fully qualified domain name, it
     610   &MAY; add its domain to the host name it received. If a proxy receives
     611   a fully qualified domain name, the proxy &MUST-NOT; change the host
     612   name.
     613</t>
     614<t><list><t>
     615  <iref item="https URI scheme"/>
     616  <iref item="URI scheme" subitem="https"/>
     617  <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
     618</t></list></t>
     619</section>
     620
     621<section title="URI Comparison" anchor="uri.comparison">
     622<t>
     623   When comparing two URIs to decide if they match or not, a client
     624   &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
     625   URIs, with these exceptions:
     626  <list style="symbols">
     627    <t>A port that is empty or not given is equivalent to the default
     628        port for that URI-reference;</t>
     629    <t>Comparisons of host names &MUST; be case-insensitive;</t>
     630    <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
     631    <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>
     632  </list>
     633</t>
     634<t>
     635   Characters other than those in the "reserved" set (see
     636   <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their
     637   ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.
     638</t>
     639<t>
     640   For example, the following three URIs are equivalent:
     641</t>
     642<figure><artwork type="example">
     643   http://example.com:80/~smith/home.html
     644   http://EXAMPLE.com/%7Esmith/home.html
     645   http://EXAMPLE.com:/%7esmith/home.html
     646</artwork></figure>
     647</section>
     648
     649<section title="Scheme aliases considered harmful" anchor="scheme.aliases">
     650<t>
     651</t>
     652</section>
     653</section>
    505654
    506655<section title="Overall Operation" anchor="intro.overall.operation">
    … …  
    513662   including the message's protocol version and a success or error code,
    514663   followed by a MIME-like message containing server information, entity
    515    metainformation, and possible entity-body content. The relationship
    516    between HTTP and MIME is described in &diff2045entity;.
     664   metainformation, and possible entity-body content.
    517665</t>
    518666<t>
    … …  
    612760</t>
    613761</section>
    614 </section>
    615 
     762
     763<section title="Use of HTTP for proxy communication" anchor="http.proxy">
     764<t>
     765   Configured to use HTTP to proxy HTTP or other protocols.
     766</t>
     767</section>
     768<section title="Interception of HTTP for access control" anchor="http.intercept">
     769<t>
     770   Interception of HTTP traffic for initiating access control.
     771</t>
     772</section>
     773<section title="Use of HTTP by other protocols" anchor="http.others">
     774<t>
     775   Profiles of HTTP defined by other protocol.
     776   Extensions of HTTP like WebDAV.
     777</t>
     778</section>
     779<section title="Use of HTTP by media type specification" anchor="http.media">
     780<t>
     781   Instructions on composing HTTP requests via hypertext formats.
     782</t>
     783</section>
     784</section>
    616785
    617786<section title="Protocol Parameters" anchor="protocol.parameters">
    … …  
    688857  </list>
    689858</t>
    690 </section>
    691 
    692 <section title="Uniform Resource Identifiers" anchor="uri">
    693 <t>
    694    Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used in HTTP
    695    to indicate the target of a request and to identify additional resources related
    696    to that resource, the request, or the response. Each protocol element in HTTP
    697    that allows a URI reference will indicate in its ABNF whether the element allows
    698    only a URI in absolute form, any relative reference, or some limited subset of
    699    the URI-reference grammar. Unless otherwise indicated, relative URI references
    700    are to be parsed relative to the URI corresponding to the request target
    701    (the base URI).
    702 </t>
    703   <x:anchor-alias value="URI-reference"/>
    704   <x:anchor-alias value="absolute-URI"/>
    705   <x:anchor-alias value="authority"/>
    706   <x:anchor-alias value="fragment"/>
    707   <x:anchor-alias value="path-abempty"/>
    708   <x:anchor-alias value="path-absolute"/>
    709   <x:anchor-alias value="port"/>
    710   <x:anchor-alias value="query"/>
    711   <x:anchor-alias value="relativeURI"/>
    712   <x:anchor-alias value="relative-part"/>
    713   <x:anchor-alias value="uri-host"/>
    714 <t>
    715    This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port",
    716    "host", "path-abempty", "path-absolute", "query", and "authority" from <xref target="RFC3986"/>:
    717 </t>
    718 <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"/><iref primary="true" item="Grammar" subitem="relativeURI"/><iref primary="true" item="Grammar" subitem="relative-part"/>
    719   <x:ref>absolute-URI</x:ref>   = &lt;absolute-URI, defined in <xref target="RFC3986" x:fmt="," x:sec="4.3"/>>
    720   <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2"/>>
    721   <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC3986" x:fmt="," x:sec="3.5"/>>
    722   <x:ref>path-abempty</x:ref>  = &lt;path-abempty, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
    723   <x:ref>path-absolute</x:ref> = &lt;path-absolute, defined in <xref target="RFC3986" x:fmt="," x:sec="3.3"/>>
    724   <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.3"/>>
    725   <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC3986" x:fmt="," x:sec="3.4"/>>
    726   <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>>
    727 
    728   <x:ref>relative-part</x:ref> = &lt;relative-part, defined in <xref target="RFC3986" x:fmt="," x:sec="4.2"/>>
    729   <x:ref>relativeURI</x:ref>   = <x:ref>relative-part</x:ref> [ "?" <x:ref>query</x:ref> ]
    730 </artwork></figure>
    731 <t>
    732    HTTP does not place an a priori limit on the length of
    733    a URI. Servers &MUST; be able to handle the URI of any resource they
    734    serve, and &SHOULD; be able to handle URIs of unbounded length if they
    735    provide GET-based forms that could generate such URIs. A server
    736    &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer
    737    than the server can handle (see &status-414;).
    738 </t>
    739 <t>
    740   <list>
    741     <t>
    742       <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths
    743       above 255 bytes, because some older client or proxy
    744       implementations might not properly support these lengths.
    745     </t>
    746   </list>
    747 </t>
    748 
    749 <section title="http URI scheme" anchor="http.uri">
    750   <x:anchor-alias value="http-URI"/>
    751   <iref item="http URI scheme" primary="true"/>
    752   <iref item="URI scheme" subitem="http" primary="true"/>
    753 <t>
    754    The "http" scheme is used to locate network resources via the HTTP
    755    protocol. This section defines the syntax and semantics for identifiers
    756    using the http or https URI schemes.
    757 </t>
    758 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/>
    759   <x:ref>http-URI</x:ref> = "http:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
    760 </artwork></figure>
    761 <t>
    762    If the port is empty or not given, port 80 is assumed. The semantics
    763    are that the identified resource is located at the server listening
    764    for TCP connections on that port of that host, and the Request-URI
    765    for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses
    766    in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
    767    the path-absolute is not present in the URL, it &MUST; be given as "/" when
    768    used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
    769    receives a host name which is not a fully qualified domain name, it
    770    &MAY; add its domain to the host name it received. If a proxy receives
    771    a fully qualified domain name, the proxy &MUST-NOT; change the host
    772    name.
    773 </t>
    774 <t><list><t>
    775   <iref item="https URI scheme"/>
    776   <iref item="URI scheme" subitem="https"/>
    777   <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
    778 </t></list></t>
    779 </section>
    780 
    781 <section title="URI Comparison" anchor="uri.comparison">
    782 <t>
    783    When comparing two URIs to decide if they match or not, a client
    784    &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
    785    URIs, with these exceptions:
    786   <list style="symbols">
    787     <t>A port that is empty or not given is equivalent to the default
    788         port for that URI-reference;</t>
    789     <t>Comparisons of host names &MUST; be case-insensitive;</t>
    790     <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
    791     <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>
    792   </list>
    793 </t>
    794 <t>
    795    Characters other than those in the "reserved" set (see
    796    <xref target="RFC3986" x:fmt="," x:sec="2.2"/>) are equivalent to their
    797    ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.
    798 </t>
    799 <t>
    800    For example, the following three URIs are equivalent:
    801 </t>
    802 <figure><artwork type="example">
    803    http://example.com:80/~smith/home.html
    804    http://EXAMPLE.com/%7Esmith/home.html
    805    http://EXAMPLE.com:/%7esmith/home.html
    806 </artwork></figure>
    807 </section>
    808859</section>
    809860
    … …  
    14151466<t>
    14161467   The Request-Line begins with a method token, followed by the
    1417    Request-URI and the protocol version, and ending with CRLF. The
     1468   request-target and the protocol version, and ending with CRLF. The
    14181469   elements are separated by SP characters. No CR or LF is allowed
    14191470   except in the final CRLF sequence.
    14201471</t>
    14211472<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-Line"/>
    1422   <x:ref>Request-Line</x:ref>   = <x:ref>Method</x:ref> <x:ref>SP</x:ref> <x:ref>Request-URI</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-Version</x:ref> <x:ref>CRLF</x:ref>
     1473  <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>
    14231474</artwork></figure>
    14241475
    … …  
    14271478<t>
    14281479   The Method  token indicates the method to be performed on the
    1429    resource identified by the Request-URI. The method is case-sensitive.
     1480   resource identified by the request-target. The method is case-sensitive.
    14301481</t>
    14311482<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
    … …  
    14341485</section>
    14351486
    1436 <section title="Request-URI" anchor="request-uri">
    1437   <x:anchor-alias value="Request-URI"/>
    1438 <t>
    1439    The Request-URI is a Uniform Resource Identifier (<xref target="uri"/>) and
     1487<section title="request-target" anchor="request-target">
     1488  <x:anchor-alias value="request-target"/>
     1489<t>
     1490   The request-target is a Uniform Resource Identifier (<xref target="uri"/>) and
    14401491   identifies the resource upon which to apply the request.
    14411492</t>
    1442 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request-URI"/>
    1443   <x:ref>Request-URI</x:ref>    = "*"
     1493<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/>
     1494  <x:ref>request-target</x:ref>    = "*"
    14441495                 / <x:ref>absolute-URI</x:ref>
    14451496                 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] )
    … …  
    14471498</artwork></figure>
    14481499<t>
    1449    The four options for Request-URI are dependent on the nature of the
     1500   The four options for request-target are dependent on the nature of the
    14501501   request. The asterisk "*" means that the request does not apply to a
    14511502   particular resource, but to the server itself, and is only allowed
    … …  
    14791530</t>
    14801531<t>
    1481    The most common form of Request-URI is that used to identify a
     1532   The most common form of request-target is that used to identify a
    14821533   resource on an origin server or gateway. In this case the absolute
    14831534   path of the URI &MUST; be transmitted (see <xref target="http.uri"/>, path-absolute) as
    1484    the Request-URI, and the network location of the URI (authority) &MUST;
     1535   the request-target, and the network location of the URI (authority) &MUST;
    14851536   be transmitted in a Host header field. For example, a client wishing
    14861537   to retrieve the resource above directly from the origin server would
    … …  
    14981549</t>
    14991550<t>
    1500    The Request-URI is transmitted in the format specified in
    1501    <xref target="http.uri"/>. If the Request-URI is encoded using the
     1551   The request-target is transmitted in the format specified in
     1552   <xref target="http.uri"/>. If the request-target is encoded using the
    15021553   "% <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding
    15031554   (<xref target="RFC3986" x:fmt="," x:sec="2.4"/>), the origin server
    1504    &MUST; decode the Request-URI in order to
     1555   &MUST; decode the request-target in order to
    15051556   properly interpret the request. Servers &SHOULD; respond to invalid
    1506    Request-URIs with an appropriate status code.
     1557   request-targets with an appropriate status code.
    15071558</t>
    15081559<t>
    15091560   A transparent proxy &MUST-NOT; rewrite the "path-absolute" part of the
    1510    received Request-URI when forwarding it to the next inbound server,
     1561   received request-target when forwarding it to the next inbound server,
    15111562   except as noted above to replace a null path-absolute with "/".
    15121563</t>
    … …  
    15171568      a non-reserved URI character for a reserved purpose.  Implementors
    15181569      should be aware that some pre-HTTP/1.1 proxies have been known to
    1519       rewrite the Request-URI.
     1570      rewrite the request-target.
    15201571  </t></list>
    15211572</t>
     1573<t>
     1574   HTTP does not place a pre-defined limit on the length of a request-target.
     1575   A server &MUST; be prepared to receive URIs of unbounded length and
     1576   respond with the 414 (URI too long) status if the received
     1577   request-target would be longer than the server wishes to handle
     1578   (see &status-414;).
     1579</t>
     1580<t>
     1581   Various ad-hoc limitations on request-target length are found in practice.
     1582   It is &RECOMMENDED; that all HTTP senders and recipients support
     1583   request-target lengths of 8000 or more OCTETs.
     1584</t>
    15221585</section>
    15231586</section>
    … …  
    15261589<t>
    15271590   The exact resource identified by an Internet request is determined by
    1528    examining both the Request-URI and the Host header field.
     1591   examining both the request-target and the Host header field.
    15291592</t>
    15301593<t>
    … …  
    15411604   resource on an HTTP/1.1 request:
    15421605  <list style="numbers">
    1543     <t>If Request-URI is an absolute-URI, the host is part of the
    1544      Request-URI. Any Host header field value in the request &MUST; be
     1606    <t>If request-target is an absolute-URI, the host is part of the
     1607     request-target. Any Host header field value in the request &MUST; be
    15451608     ignored.</t>
    1546     <t>If the Request-URI is not an absolute-URI, and the request includes
     1609    <t>If the request-target is not an absolute-URI, and the request includes
    15471610     a Host header field, the host is determined by the Host header
    15481611     field value.</t>
    … …  
    22382301   The request-header field "Host" specifies the Internet host and port
    22392302   number of the resource being requested, as obtained from the original
    2240    URI given by the user or referring resource (generally an HTTP URL,
     2303   URI given by the user or referring resource (generally an http URI,
    22412304   as described in <xref target="http.uri"/>). The Host field value &MUST; represent
    22422305   the naming authority of the origin server or gateway given by the
    … …  
    28752938   other operating systems use ".." as a path component to indicate a
    28762939   directory level above the current one. On such a system, an HTTP
    2877    server &MUST; disallow any such construct in the Request-URI if it
     2940   server &MUST; disallow any such construct in the request-target if it
    28782941   would otherwise allow access to a resource outside those intended to
    28792942   be accessible via the HTTP server. Similarly, files intended for
    … …  
    39093972   The requirements that clients and servers support the Host request-header,
    39103973   report an error if the Host request-header (<xref target="header.host"/>) is
    3911    missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-uri"/>)
     3974   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    39123975   are among the most important changes defined by this
    39133976   specification.
    … …  
    40374100  Update use of abs_path production from RFC1808 to the path-absolute + query
    40384101  components of RFC3986.
    4039   (<xref target="request-uri"/>)
     4102  (<xref target="request-target"/>)
    40404103</t>
    40414104<t>
    … …  
    45984661  </list>
    45994662</t>
     4663<t>
     4664  Other changes:
     4665  <list style="symbols">
     4666    <t>
     4667      Rewrite introduction; add mostly new Architecture Section.
     4668    </t>
     4669  </list>
     4670</t>
    46004671</section>
    46014672
Note: See TracChangeset for help on using the changeset viewer.