Ignore:
Timestamp:
11/11/08 01:00:46 (14 years ago)
Author:
fielding@…
Message:

No content changes. Move ABNF up to intro. Move URIs up to when to use HTTP.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r339 r340  
    306306</section>
    307307
    308 <section title="Syntax Notation" anchor="syntax.notation">
     308<section title="Syntax Notation" anchor="notation">
    309309<t>
    310310   This specification uses the Augmented Backus-Naur Form (ABNF) notation
    … …  
    314314   and SP (space).
    315315</t>
    316 </section>
    317 </section>
    318 
    319 <section title="When to use HTTP" anchor="when">
    320 
    321 <section title="Overall Operation" anchor="intro.overall.operation">
    322 <t>
    323    HTTP is a request/response protocol. A client sends a
    324    request to the server in the form of a request method, URI, and
    325    protocol version, followed by a MIME-like message containing request
    326    modifiers, client information, and possible body content over a
    327    connection with a server. The server responds with a status line,
    328    including the message's protocol version and a success or error code,
    329    followed by a MIME-like message containing server information, entity
    330    metainformation, and possible entity-body content. The relationship
    331    between HTTP and MIME is described in &diff2045entity;.
    332 </t>
    333 <t>
    334    Most HTTP communication is initiated by a user agent and consists of
    335    a request to be applied to a resource on some origin server. In the
    336    simplest case, this may be accomplished via a single connection (v)
    337    between the user agent (UA) and the origin server (O).
    338 </t>
    339 <figure><artwork type="drawing">
    340        request chain ------------------------&gt;
    341     UA -------------------v------------------- O
    342        &lt;----------------------- response chain
    343 </artwork></figure>
    344 <t>
    345    A more complicated situation occurs when one or more intermediaries
    346    are present in the request/response chain. There are three common
    347    forms of intermediary: proxy, gateway, and tunnel. A proxy is a
    348    forwarding agent, receiving requests for a URI in its absolute form,
    349    rewriting all or part of the message, and forwarding the reformatted
    350    request toward the server identified by the URI. A gateway is a
    351    receiving agent, acting as a layer above some other server(s) and, if
    352    necessary, translating the requests to the underlying server's
    353    protocol. A tunnel acts as a relay point between two connections
    354    without changing the messages; tunnels are used when the
    355    communication needs to pass through an intermediary (such as a
    356    firewall) even when the intermediary cannot understand the contents
    357    of the messages.
    358 </t>
    359 <figure><artwork type="drawing">
    360        request chain --------------------------------------&gt;
    361     UA -----v----- A -----v----- B -----v----- C -----v----- O
    362        &lt;------------------------------------- response chain
    363 </artwork></figure>
    364 <t>
    365    The figure above shows three intermediaries (A, B, and C) between the
    366    user agent and origin server. A request or response message that
    367    travels the whole chain will pass through four separate connections.
    368    This distinction is important because some HTTP communication options
    369    may apply only to the connection with the nearest, non-tunnel
    370    neighbor, only to the end-points of the chain, or to all connections
    371    along the chain. Although the diagram is linear, each participant may
    372    be engaged in multiple, simultaneous communications. For example, B
    373    may be receiving requests from many clients other than A, and/or
    374    forwarding requests to servers other than C, at the same time that it
    375    is handling A's request.
    376 </t>
    377 <t>
    378    Any party to the communication which is not acting as a tunnel may
    379    employ an internal cache for handling requests. The effect of a cache
    380    is that the request/response chain is shortened if one of the
    381    participants along the chain has a cached response applicable to that
    382    request. The following illustrates the resulting chain if B has a
    383    cached copy of an earlier response from O (via C) for a request which
    384    has not been cached by UA or A.
    385 </t>
    386 <figure><artwork type="drawing">
    387           request chain ----------&gt;
    388        UA -----v----- A -----v----- B - - - - - - C - - - - - - O
    389           &lt;--------- response chain
    390 </artwork></figure>
    391 <t>
    392    Not all responses are usefully cacheable, and some requests may
    393    contain modifiers which place special requirements on cache behavior.
    394    HTTP requirements for cache behavior and cacheable responses are
    395    defined in &caching;.
    396 </t>
    397 <t>
    398    In fact, there are a wide variety of architectures and configurations
    399    of caches and proxies currently being experimented with or deployed
    400    across the World Wide Web. These systems include national hierarchies
    401    of proxy caches to save transoceanic bandwidth, systems that
    402    broadcast or multicast cache entries, organizations that distribute
    403    subsets of cached data via CD-ROM, and so on. HTTP systems are used
    404    in corporate intranets over high-bandwidth links, and for access via
    405    PDAs with low-power radio links and intermittent connectivity. The
    406    goal of HTTP/1.1 is to support the wide diversity of configurations
    407    already deployed while introducing protocol constructs that meet the
    408    needs of those who build web applications that require high
    409    reliability and, failing that, at least reliable indications of
    410    failure.
    411 </t>
    412 <t>
    413    HTTP communication usually takes place over TCP/IP connections. The
    414    default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
    415    not preclude HTTP from being implemented on top of any other protocol
    416    on the Internet, or on other networks. HTTP only presumes a reliable
    417    transport; any protocol that provides such guarantees can be used;
    418    the mapping of the HTTP/1.1 request and response structures onto the
    419    transport data units of the protocol in question is outside the scope
    420    of this specification.
    421 </t>
    422 <t>
    423    In HTTP/1.0, most implementations used a new connection for each
    424    request/response exchange. In HTTP/1.1, a connection may be used for
    425    one or more request/response exchanges, although connections may be
    426    closed for a variety of reasons (see <xref target="persistent.connections"/>).
    427 </t>
    428 </section>
    429 </section>
    430 
    431 <section title="Notational Conventions and Generic Grammar" anchor="notation">
     316<t anchor="core.rules">
     317  <x:anchor-alias value="OCTET"/>
     318  <x:anchor-alias value="CHAR"/>
     319  <x:anchor-alias value="ALPHA"/>
     320  <x:anchor-alias value="DIGIT"/>
     321  <x:anchor-alias value="CTL"/>
     322  <x:anchor-alias value="CR"/>
     323  <x:anchor-alias value="LF"/>
     324  <x:anchor-alias value="SP"/>
     325  <x:anchor-alias value="HTAB"/>
     326  <x:anchor-alias value="DQUOTE"/>
     327   The following rules are used throughout this specification to
     328   describe basic parsing constructs. The US-ASCII coded character set
     329   is defined by ANSI X3.4-1986 <xref target="USASCII"/>.
     330</t>
     331<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HTAB"/><iref primary="true" item="Grammar" subitem="DQUOTE"/>
     332  <x:ref>OCTET</x:ref>          = %x00-FF
     333                   ; any 8-bit sequence of data
     334  <x:ref>CHAR</x:ref>           = %x01-7F
     335                   ; any US-ASCII character, excluding NUL
     336  <x:ref>ALPHA</x:ref>          = %x41-5A / %x61-7A
     337                   ; A-Z / a-z
     338  <x:ref>DIGIT</x:ref>          = %x30-39
     339                   ; any US-ASCII digit "0".."9"
     340  <x:ref>CTL</x:ref>            = %x00-1F / %x7F
     341                   ; (octets 0 - 31) and DEL (127)
     342  <x:ref>CR</x:ref>             = %x0D
     343                   ; US-ASCII CR, carriage return (13)
     344  <x:ref>LF</x:ref>             = %x0A
     345                   ; US-ASCII LF, linefeed (10)
     346  <x:ref>SP</x:ref>             = %x20
     347                   ; US-ASCII SP, space (32)
     348  <x:ref>HTAB</x:ref>           = %x09
     349                   ; US-ASCII HT, horizontal-tab (9)
     350  <x:ref>DQUOTE</x:ref>         = %x22
     351                   ; US-ASCII double-quote mark (34)
     352</artwork></figure>
    432353
    433354<section title="Augmented BNF" anchor="notation.abnf">
    … …  
    483404
    484405<section title="Basic Rules" anchor="basic.rules">
    485 <t anchor="core.rules">
    486   <x:anchor-alias value="OCTET"/>
    487   <x:anchor-alias value="CHAR"/>
    488   <x:anchor-alias value="ALPHA"/>
    489   <x:anchor-alias value="DIGIT"/>
    490   <x:anchor-alias value="CTL"/>
    491   <x:anchor-alias value="CR"/>
    492   <x:anchor-alias value="LF"/>
    493   <x:anchor-alias value="SP"/>
    494   <x:anchor-alias value="HTAB"/>
    495   <x:anchor-alias value="DQUOTE"/>
    496    The following rules are used throughout this specification to
    497    describe basic parsing constructs. The US-ASCII coded character set
    498    is defined by ANSI X3.4-1986 <xref target="USASCII"/>.
    499 </t>
    500 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HTAB"/><iref primary="true" item="Grammar" subitem="DQUOTE"/>
    501   <x:ref>OCTET</x:ref>          = %x00-FF
    502                    ; any 8-bit sequence of data
    503   <x:ref>CHAR</x:ref>           = %x01-7F
    504                    ; any US-ASCII character, excluding NUL
    505   <x:ref>ALPHA</x:ref>          = %x41-5A / %x61-7A
    506                    ; A-Z / a-z
    507   <x:ref>DIGIT</x:ref>          = %x30-39
    508                    ; any US-ASCII digit "0".."9"
    509   <x:ref>CTL</x:ref>            = %x00-1F / %x7F
    510                    ; (octets 0 - 31) and DEL (127)
    511   <x:ref>CR</x:ref>             = %x0D
    512                    ; US-ASCII CR, carriage return (13)
    513   <x:ref>LF</x:ref>             = %x0A
    514                    ; US-ASCII LF, linefeed (10)
    515   <x:ref>SP</x:ref>             = %x20
    516                    ; US-ASCII SP, space (32)
    517   <x:ref>HTAB</x:ref>           = %x09
    518                    ; US-ASCII HT, horizontal-tab (9)
    519   <x:ref>DQUOTE</x:ref>         = %x22
    520                    ; US-ASCII double-quote mark (34)
    521 </artwork></figure>
    522406<t anchor="rule.CRLF">
    523407  <x:anchor-alias value="CRLF"/>
    … …  
    653537</section>
    654538
     539</section>
     540</section>
     541
     542<section title="When to use HTTP" anchor="when">
     543
     544<section title="Uniform Resource Identifiers" anchor="uri">
     545<t>
     546   URIs have been known by many names: WWW addresses, Universal Document
     547   Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the
     548   combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN)
     549   <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are
     550   simply formatted strings which identify--via name, location, or any
     551   other characteristic--a resource.
     552</t>
     553
     554<section title="General Syntax" anchor="general.syntax">
     555  <x:anchor-alias value="absoluteURI"/>
     556  <x:anchor-alias value="authority"/>
     557  <x:anchor-alias value="fragment"/>
     558  <x:anchor-alias value="path-absolute"/>
     559  <x:anchor-alias value="port"/>
     560  <x:anchor-alias value="query"/>
     561  <x:anchor-alias value="relativeURI"/>
     562  <x:anchor-alias value="uri-host"/>
     563<t>
     564   URIs in HTTP can be represented in absolute form or relative to some
     565   known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two
     566   forms are differentiated by the fact that absolute URIs always begin
     567   with a scheme name followed by a colon. For definitive information on
     568   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
     569   Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/>
     570   and <xref target="RFC1808"/>). This specification adopts the
     571   definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port",
     572   "host", "abs_path", "query", and "authority" from that specification:
     573</t>
     574<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><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="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/>
     575  <x:ref>absoluteURI</x:ref>   = &lt;absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
     576  <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>>
     577  <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>>
     578  <x:ref>path-absolute</x:ref> = &lt;abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
     579  <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
     580  <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>>
     581  <x:ref>relativeURI</x:ref>   = &lt;relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>>
     582  <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
     583</artwork></figure>
     584<t>
     585   HTTP does not place any a priori limit on the length of
     586   a URI. Servers &MUST; be able to handle the URI of any resource they
     587   serve, and &SHOULD; be able to handle URIs of unbounded length if they
     588   provide GET-based forms that could generate such URIs. A server
     589   &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer
     590   than the server can handle (see &status-414;).
     591</t>
     592<t>
     593  <list>
     594    <t>
     595      <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths
     596      above 255 bytes, because some older client or proxy
     597      implementations might not properly support these lengths.
     598    </t>
     599  </list>
     600</t>
     601</section>
     602
     603<section title="http URL" anchor="http.url">
     604  <x:anchor-alias value="http-URL"/>
     605  <iref item="http URI scheme" primary="true"/>
     606  <iref item="URI scheme" subitem="http" primary="true"/>
     607<t>
     608   The "http" scheme is used to locate network resources via the HTTP
     609   protocol. This section defines the scheme-specific syntax and
     610   semantics for http URLs.
     611</t>
     612<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/>
     613  <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ]
     614             [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]]
     615</artwork></figure>
     616<t>
     617   If the port is empty or not given, port 80 is assumed. The semantics
     618   are that the identified resource is located at the server listening
     619   for TCP connections on that port of that host, and the Request-URI
     620   for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses
     621   in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
     622   the path-absolute is not present in the URL, it &MUST; be given as "/" when
     623   used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
     624   receives a host name which is not a fully qualified domain name, it
     625   &MAY; add its domain to the host name it received. If a proxy receives
     626   a fully qualified domain name, the proxy &MUST-NOT; change the host
     627   name.
     628</t>
     629<t><list><t>
     630  <iref item="https URI scheme"/>
     631  <iref item="URI scheme" subitem="https"/>
     632  <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
     633</t></list></t>
     634</section>
     635
     636<section title="URI Comparison" anchor="uri.comparison">
     637<t>
     638   When comparing two URIs to decide if they match or not, a client
     639   &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
     640   URIs, with these exceptions:
     641  <list style="symbols">
     642    <t>A port that is empty or not given is equivalent to the default
     643        port for that URI-reference;</t>
     644    <t>Comparisons of host names &MUST; be case-insensitive;</t>
     645    <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
     646    <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>
     647  </list>
     648</t>
     649<t>
     650   Characters other than those in the "reserved" set (see
     651   <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their
     652   ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.
     653</t>
     654<t>
     655   For example, the following three URIs are equivalent:
     656</t>
     657<figure><artwork type="example">
     658   http://example.com:80/~smith/home.html
     659   http://EXAMPLE.com/%7Esmith/home.html
     660   http://EXAMPLE.com:/%7esmith/home.html
     661</artwork></figure>
     662</section>
     663</section>
     664
     665<section title="Overall Operation" anchor="intro.overall.operation">
     666<t>
     667   HTTP is a request/response protocol. A client sends a
     668   request to the server in the form of a request method, URI, and
     669   protocol version, followed by a MIME-like message containing request
     670   modifiers, client information, and possible body content over a
     671   connection with a server. The server responds with a status line,
     672   including the message's protocol version and a success or error code,
     673   followed by a MIME-like message containing server information, entity
     674   metainformation, and possible entity-body content. The relationship
     675   between HTTP and MIME is described in &diff2045entity;.
     676</t>
     677<t>
     678   Most HTTP communication is initiated by a user agent and consists of
     679   a request to be applied to a resource on some origin server. In the
     680   simplest case, this may be accomplished via a single connection (v)
     681   between the user agent (UA) and the origin server (O).
     682</t>
     683<figure><artwork type="drawing">
     684       request chain ------------------------&gt;
     685    UA -------------------v------------------- O
     686       &lt;----------------------- response chain
     687</artwork></figure>
     688<t>
     689   A more complicated situation occurs when one or more intermediaries
     690   are present in the request/response chain. There are three common
     691   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
     692   forwarding agent, receiving requests for a URI in its absolute form,
     693   rewriting all or part of the message, and forwarding the reformatted
     694   request toward the server identified by the URI. A gateway is a
     695   receiving agent, acting as a layer above some other server(s) and, if
     696   necessary, translating the requests to the underlying server's
     697   protocol. A tunnel acts as a relay point between two connections
     698   without changing the messages; tunnels are used when the
     699   communication needs to pass through an intermediary (such as a
     700   firewall) even when the intermediary cannot understand the contents
     701   of the messages.
     702</t>
     703<figure><artwork type="drawing">
     704       request chain --------------------------------------&gt;
     705    UA -----v----- A -----v----- B -----v----- C -----v----- O
     706       &lt;------------------------------------- response chain
     707</artwork></figure>
     708<t>
     709   The figure above shows three intermediaries (A, B, and C) between the
     710   user agent and origin server. A request or response message that
     711   travels the whole chain will pass through four separate connections.
     712   This distinction is important because some HTTP communication options
     713   may apply only to the connection with the nearest, non-tunnel
     714   neighbor, only to the end-points of the chain, or to all connections
     715   along the chain. Although the diagram is linear, each participant may
     716   be engaged in multiple, simultaneous communications. For example, B
     717   may be receiving requests from many clients other than A, and/or
     718   forwarding requests to servers other than C, at the same time that it
     719   is handling A's request.
     720</t>
     721<t>
     722   Any party to the communication which is not acting as a tunnel may
     723   employ an internal cache for handling requests. The effect of a cache
     724   is that the request/response chain is shortened if one of the
     725   participants along the chain has a cached response applicable to that
     726   request. The following illustrates the resulting chain if B has a
     727   cached copy of an earlier response from O (via C) for a request which
     728   has not been cached by UA or A.
     729</t>
     730<figure><artwork type="drawing">
     731          request chain ----------&gt;
     732       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
     733          &lt;--------- response chain
     734</artwork></figure>
     735<t>
     736   Not all responses are usefully cacheable, and some requests may
     737   contain modifiers which place special requirements on cache behavior.
     738   HTTP requirements for cache behavior and cacheable responses are
     739   defined in &caching;.
     740</t>
     741<t>
     742   In fact, there are a wide variety of architectures and configurations
     743   of caches and proxies currently being experimented with or deployed
     744   across the World Wide Web. These systems include national hierarchies
     745   of proxy caches to save transoceanic bandwidth, systems that
     746   broadcast or multicast cache entries, organizations that distribute
     747   subsets of cached data via CD-ROM, and so on. HTTP systems are used
     748   in corporate intranets over high-bandwidth links, and for access via
     749   PDAs with low-power radio links and intermittent connectivity. The
     750   goal of HTTP/1.1 is to support the wide diversity of configurations
     751   already deployed while introducing protocol constructs that meet the
     752   needs of those who build web applications that require high
     753   reliability and, failing that, at least reliable indications of
     754   failure.
     755</t>
     756<t>
     757   HTTP communication usually takes place over TCP/IP connections. The
     758   default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
     759   not preclude HTTP from being implemented on top of any other protocol
     760   on the Internet, or on other networks. HTTP only presumes a reliable
     761   transport; any protocol that provides such guarantees can be used;
     762   the mapping of the HTTP/1.1 request and response structures onto the
     763   transport data units of the protocol in question is outside the scope
     764   of this specification.
     765</t>
     766<t>
     767   In HTTP/1.0, most implementations used a new connection for each
     768   request/response exchange. In HTTP/1.1, a connection may be used for
     769   one or more request/response exchanges, although connections may be
     770   closed for a variety of reasons (see <xref target="persistent.connections"/>).
     771</t>
     772</section>
    655773</section>
    656774
    … …  
    728846  </list>
    729847</t>
    730 </section>
    731 
    732 <section title="Uniform Resource Identifiers" anchor="uri">
    733 <t>
    734    URIs have been known by many names: WWW addresses, Universal Document
    735    Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the
    736    combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN)
    737    <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are
    738    simply formatted strings which identify--via name, location, or any
    739    other characteristic--a resource.
    740 </t>
    741 
    742 <section title="General Syntax" anchor="general.syntax">
    743   <x:anchor-alias value="absoluteURI"/>
    744   <x:anchor-alias value="authority"/>
    745   <x:anchor-alias value="fragment"/>
    746   <x:anchor-alias value="path-absolute"/>
    747   <x:anchor-alias value="port"/>
    748   <x:anchor-alias value="query"/>
    749   <x:anchor-alias value="relativeURI"/>
    750   <x:anchor-alias value="uri-host"/>
    751 <t>
    752    URIs in HTTP can be represented in absolute form or relative to some
    753    known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two
    754    forms are differentiated by the fact that absolute URIs always begin
    755    with a scheme name followed by a colon. For definitive information on
    756    URL syntax and semantics, see "Uniform Resource Identifiers (URI):
    757    Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/>
    758    and <xref target="RFC1808"/>). This specification adopts the
    759    definitions of "URI-reference", "absoluteURI", "fragment", "relativeURI", "port",
    760    "host", "abs_path", "query", and "authority" from that specification:
    761 </t>
    762 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="absoluteURI"/><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="relativeURI"/><iref primary="true" item="Grammar" subitem="uri-host"/>
    763   <x:ref>absoluteURI</x:ref>   = &lt;absoluteURI, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
    764   <x:ref>authority</x:ref>     = &lt;authority, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2"/>>
    765   <x:ref>fragment</x:ref>      = &lt;fragment, defined in <xref target="RFC2396" x:fmt="," x:sec="4.1"/>>
    766   <x:ref>path-absolute</x:ref> = &lt;abs_path, defined in <xref target="RFC2396" x:fmt="," x:sec="3"/>>
    767   <x:ref>port</x:ref>          = &lt;port, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
    768   <x:ref>query</x:ref>         = &lt;query, defined in <xref target="RFC2396" x:fmt="," x:sec="3.4"/>>
    769   <x:ref>relativeURI</x:ref>   = &lt;relativeURI, defined in <xref target="RFC2396" x:fmt="," x:sec="5"/>>
    770   <x:ref>uri-host</x:ref>      = &lt;host, defined in <xref target="RFC2396" x:fmt="," x:sec="3.2.2"/>>
    771 </artwork></figure>
    772 <t>
    773    HTTP does not place any a priori limit on the length of
    774    a URI. Servers &MUST; be able to handle the URI of any resource they
    775    serve, and &SHOULD; be able to handle URIs of unbounded length if they
    776    provide GET-based forms that could generate such URIs. A server
    777    &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer
    778    than the server can handle (see &status-414;).
    779 </t>
    780 <t>
    781   <list>
    782     <t>
    783       <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths
    784       above 255 bytes, because some older client or proxy
    785       implementations might not properly support these lengths.
    786     </t>
    787   </list>
    788 </t>
    789 </section>
    790 
    791 <section title="http URL" anchor="http.url">
    792   <x:anchor-alias value="http-URL"/>
    793   <iref item="http URI scheme" primary="true"/>
    794   <iref item="URI scheme" subitem="http" primary="true"/>
    795 <t>
    796    The "http" scheme is used to locate network resources via the HTTP
    797    protocol. This section defines the scheme-specific syntax and
    798    semantics for http URLs.
    799 </t>
    800 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URL"/>
    801   <x:ref>http-URL</x:ref> = "http:" "//" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ]
    802              [ <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ]]
    803 </artwork></figure>
    804 <t>
    805    If the port is empty or not given, port 80 is assumed. The semantics
    806    are that the identified resource is located at the server listening
    807    for TCP connections on that port of that host, and the Request-URI
    808    for the resource is path-absolute (<xref target="request-uri"/>). The use of IP addresses
    809    in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
    810    the path-absolute is not present in the URL, it &MUST; be given as "/" when
    811    used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
    812    receives a host name which is not a fully qualified domain name, it
    813    &MAY; add its domain to the host name it received. If a proxy receives
    814    a fully qualified domain name, the proxy &MUST-NOT; change the host
    815    name.
    816 </t>
    817 <t><list><t>
    818   <iref item="https URI scheme"/>
    819   <iref item="URI scheme" subitem="https"/>
    820   <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
    821 </t></list></t>
    822 </section>
    823 
    824 <section title="URI Comparison" anchor="uri.comparison">
    825 <t>
    826    When comparing two URIs to decide if they match or not, a client
    827    &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
    828    URIs, with these exceptions:
    829   <list style="symbols">
    830     <t>A port that is empty or not given is equivalent to the default
    831         port for that URI-reference;</t>
    832     <t>Comparisons of host names &MUST; be case-insensitive;</t>
    833     <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
    834     <t>An empty path-absolute is equivalent to an path-absolute of "/".</t>
    835   </list>
    836 </t>
    837 <t>
    838    Characters other than those in the "reserved" set (see
    839    <xref target="RFC2396" x:fmt="," x:sec="2.2"/>) are equivalent to their
    840    ""%" <x:ref>HEXDIG</x:ref> <x:ref>HEXDIG</x:ref>" encoding.
    841 </t>
    842 <t>
    843    For example, the following three URIs are equivalent:
    844 </t>
    845 <figure><artwork type="example">
    846    http://example.com:80/~smith/home.html
    847    http://EXAMPLE.com/%7Esmith/home.html
    848    http://EXAMPLE.com:/%7esmith/home.html
    849 </artwork></figure>
    850 </section>
    851848</section>
    852849
Note: See TracChangeset for help on using the changeset viewer.