Ignore:
Timestamp:
30/01/12 01:48:21 (10 years ago)
Author:
fielding@…
Message:

Streamline the meaty sections by moving the miscellaneous conformance
and error handling down where it is applicable, and the ABNF stuff only
used by header fields down to the header fields sections. Simplify
the reference to ABNF in all parts.

Clarify what stateless means for HTTP and correct overstatement
about connection-based authentication. Move discussion of streaming
to where it belongs.

Clarify section on request-target by reordering it by common types
and use an example that has path and query. Provide an example
for CONNECT authority-form. Remove obsolete note about the "no rewrite" rule.

Location:
draft-ietf-httpbis/latest
Files:
7 edited

Legend:

Unmodified
Added
Removed

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

    r1517 r1518  
    301301</t>
    302302
    303 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     303<section title="Requirement Notation" anchor="intro.requirements">
    304304<t>
    305305   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    306306   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    307307   document are to be interpreted as described in <xref target="RFC2119"/>.
    308 </t>
    309 <t>
    310    This document defines conformance criteria for several roles in HTTP
    311    communication, including Senders, Recipients, Clients, Servers, User-Agents,
    312    Origin Servers, Intermediaries, Proxies and Gateways. See <xref target="architecture"/>
    313    for definitions of these terms.
    314 </t>
    315 <t>
    316    An implementation is considered conformant if it complies with all of the
    317    requirements associated with its role(s). Note that SHOULD-level requirements
    318    are relevant here, unless one of the documented exceptions is applicable.
    319 </t>
    320 <t>
    321    This document also uses ABNF to define valid protocol elements
    322    (<xref target="notation"/>). In addition to the prose requirements placed
    323    upon them, Senders &MUST-NOT; generate protocol elements that are invalid.
    324 </t>
    325 <t>
    326    Unless noted otherwise, Recipients &MAY; take steps to recover a usable
    327    protocol element from an invalid construct. However, HTTP does not define
    328    specific error handling mechanisms, except in cases where it has direct
    329    impact on security. This is because different uses of the protocol require
    330    different error handling strategies; for example, a Web browser may wish to
    331    transparently recover from a response where the Location header field
    332    doesn't parse according to the ABNF, whereby in a systems control protocol
    333    using HTTP, this type of error recovery could lead to dangerous consequences.
    334308</t>
    335309</section>
    … …  
    350324<t>
    351325   This specification uses the Augmented Backus-Naur Form (ABNF) notation
    352    of <xref target="RFC5234"/>.
     326   of <xref target="RFC5234"/> with the list rule extension defined in
     327   <xref target="abnf.extension"/>.  <xref target="collected.abnf"/> shows
     328   the collected ABNF with the list rule expanded.
    353329</t>
    354330<t anchor="core.rules">
    … …  
    374350</t>
    375351<t>
    376    As a syntactic convention, ABNF rule names prefixed with "obs-" denote
     352   As a convention, ABNF rule names prefixed with "obs-" denote
    377353   "obsolete" grammar rules that appear for historical reasons.
    378354</t>
    379 
    380 <section title="ABNF Extension: #rule" anchor="notation.abnf">
    381 <t>
    382   The #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to
    383   improve readability.
    384 </t>
    385 <t>
    386   A construct "#" is defined, similar to "*", for defining comma-delimited
    387   lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating
    388   at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
    389   comma (",") and optional whitespace (OWS, <xref target="basic.rules"/>).   
    390 </t>
    391 <figure><preamble>
    392   Thus,
    393 </preamble><artwork type="example">
    394   1#element =&gt; element *( OWS "," OWS element )
    395 </artwork></figure>
    396 <figure><preamble>
    397   and:
    398 </preamble><artwork type="example">
    399   #element =&gt; [ 1#element ]
    400 </artwork></figure>
    401 <figure><preamble>
    402   and for n &gt;= 1 and m &gt; 1:
    403 </preamble><artwork type="example">
    404   &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
    405 </artwork></figure>
    406 <t>
    407   For compatibility with legacy list rules, recipients &SHOULD; accept empty
    408   list elements. In other words, consumers would follow the list productions:
    409 </t>
    410 <figure><artwork type="example">
    411   #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
    412  
    413   1#element =&gt; *( "," OWS ) element *( OWS "," [ OWS element ] )
    414 </artwork></figure>
    415 <t>
    416   Note that empty elements do not contribute to the count of elements present,
    417   though.
    418 </t>
    419 <t>
    420   For example, given these ABNF productions:
    421 </t>
    422 <figure><artwork type="example">
    423   example-list      = 1#example-list-elmt
    424   example-list-elmt = token ; see <xref target="field.rules"/>
    425 </artwork></figure>
    426 <t>
    427   Then these are valid values for example-list (not including the double
    428   quotes, which are present for delimitation only):
    429 </t>
    430 <figure><artwork type="example">
    431   "foo,bar"
    432   "foo ,bar,"
    433   "foo , ,bar,charlie   "
    434 </artwork></figure>
    435 <t>
    436   But these values would be invalid, as at least one non-empty element is
    437   required:
    438 </t>
    439 <figure><artwork type="example">
    440   ""
    441   ","
    442   ",   ,"
    443 </artwork></figure>
    444 <t>
    445   <xref target="collected.abnf"/> shows the collected ABNF, with the list rules
    446   expanded as explained above.
    447 </t>
    448 </section>
    449 
    450 <section title="Basic Rules" anchor="basic.rules">
    451 <t anchor="rule.LWS">
    452    This specification uses three rules to denote the use of linear
    453    whitespace: OWS (optional whitespace), RWS (required whitespace), and
    454    BWS ("bad" whitespace).
    455 </t>
    456 <t anchor="rule.OWS">
    457    The OWS rule is used where zero or more linear whitespace octets might
    458    appear. OWS &SHOULD; either not be produced or be produced as a single
    459    SP. Multiple OWS octets that occur within field-content &SHOULD; either
    460    be replaced with a single SP or transformed to all SP octets (each
    461    octet other than SP replaced with SP) before interpreting the field value
    462    or forwarding the message downstream.
    463 </t>
    464 <t anchor="rule.RWS">
    465    RWS is used when at least one linear whitespace octet is required to
    466    separate field tokens. RWS &SHOULD; be produced as a single SP.
    467    Multiple RWS octets that occur within field-content &SHOULD; either
    468    be replaced with a single SP or transformed to all SP octets before
    469    interpreting the field value or forwarding the message downstream.
    470 </t>
    471 <t anchor="rule.BWS">
    472    BWS is used where the grammar allows optional whitespace for historical
    473    reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1
    474    recipients &MUST; accept such bad optional whitespace and remove it before
    475    interpreting the field value or forwarding the message downstream.
    476 </t>
    477 <t anchor="rule.whitespace">
    478   <x:anchor-alias value="BWS"/>
    479   <x:anchor-alias value="OWS"/>
    480   <x:anchor-alias value="RWS"/>
    481   <x:anchor-alias value="obs-fold"/>
    482 </t>
    483 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/>
    484   <x:ref>OWS</x:ref>            = *( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold )
    485                  ; "optional" whitespace
    486   <x:ref>RWS</x:ref>            = 1*( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold )
    487                  ; "required" whitespace
    488   <x:ref>BWS</x:ref>            = <x:ref>OWS</x:ref>
    489                  ; "bad" whitespace
    490   <x:ref>obs-fold</x:ref>       = <x:ref>CRLF</x:ref> ( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> )
    491                  ; obsolete line folding
    492                  ; see <xref target="field.parsing"/>
    493 </artwork></figure>
    494 </section>
    495355</section>
    496356</section>
    … …  
    615475<x:span anchor="exbody">Hello World!
    616476</x:span></artwork></figure>
    617 </section>
    618 
    619 <section title="Message Orientation and Buffering" anchor="message-orientation-and-buffering">
    620 <t>
    621    Fundamentally, HTTP is a message-based protocol. Although message bodies can
    622    be chunked (<xref target="chunked.encoding"/>) and implementations often
    623    make parts of a message available progressively, this is not required, and
    624    some widely-used implementations only make a message available when it is
    625    complete. Furthermore, while most proxies will progressively stream messages,
    626    some amount of buffering will take place, and some proxies might buffer
    627    messages to perform transformations, check content or provide other services.
    628 </t>
    629 <t>
    630    Therefore, extensions to and uses of HTTP cannot rely on the availability of
    631    a partial message, or assume that messages will not be buffered. There are
    632    strategies that can be used to test for buffering in a given connection, but
    633    it should be understood that behaviors can differ across connections, and
    634    between requests and responses.
    635 </t>
    636 <t>
    637    Recipients &MUST; consider every message in a connection in isolation;
    638    because HTTP is a stateless protocol, it cannot be assumed that two requests
    639    on the same connection are from the same client or share any other common
    640    attributes. In particular, intermediaries might mix requests from different
    641    clients into a single server connection. Note that some existing HTTP
    642    extensions (e.g., <xref target="RFC4559"/>) violate this requirement, thereby
    643    potentially causing interoperability and security problems.
    644 </t>
    645477</section>
    646478
    … …  
    790622   They are indistinguishable from a man-in-the-middle attack.
    791623</t>
     624<t>
     625   HTTP is defined as a stateless protocol, meaning that each request message
     626   can be understood in isolation.  Many implementations depend on HTTP's
     627   stateless design in order to reuse proxied connections or dynamically
     628   load balance requests across multiple servers.  Hence, servers &MUST-NOT;
     629   assume that two requests on the same connection are from the same user
     630   agent unless the connection is secured and specific to that agent.
     631   Some non-standard HTTP extensions (e.g., <xref target="RFC4559"/>) have
     632   been known to violate this requirement, resulting in security and
     633   interoperability problems.
     634</t>
    792635</section>
    793636
    … …  
    830673   broadcast or multicast cache entries, organizations that distribute
    831674   subsets of cached data via optical media, and so on.
     675</t>
     676</section>
     677
     678<section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
     679<t>
     680   This specification targets conformance criteria according to the role of
     681   a participant in HTTP communication.  Hence, HTTP requirements are placed
     682   on senders, recipients, clients, servers, user agents, intermediaries,
     683   origin servers, proxies, gateways, or caches, depending on what behavior
     684   is being constrained by the requirement.
     685</t>
     686<t>
     687   An implementation is considered conformant if it complies with all of the
     688   requirements associated with the roles it partakes in HTTP.
     689</t>
     690<t>
     691   Senders &MUST-NOT; generate protocol elements that do not match the grammar
     692   defined by the ABNF rules for those protocol elements.
     693</t>
     694<t>
     695   Unless otherwise noted, recipients &MAY; attempt to recover a usable
     696   protocol element from an invalid construct.  HTTP does not define
     697   specific error handling mechanisms except when they have a direct impact
     698   on security, since different applications of the protocol require
     699   different error handling strategies.  For example, a Web browser might
     700   wish to transparently recover from a response where the Location header
     701   field doesn't parse according to the ABNF, whereas a systems control
     702   client might consider any form of error recovery to be dangerous.
    832703</t>
    833704</section>
    … …  
    12021073   after message parsing has delineated the individual fields.
    12031074</t>
     1075<t>
     1076   An HTTP message can be parsed as a stream for incremental processing or
     1077   forwarding downstream.  However, recipients cannot rely on incremental
     1078   delivery of partial messages, since some implementations will buffer or
     1079   delay message forwarding for the sake of network efficiency, security
     1080   checks, or payload transformations.
     1081</t>
    12041082
    12051083<section title="Start Line" anchor="start.line">
    … …  
    13351213</section>
    13361214</section>
    1337 
    13381215</section>
    13391216
    … …  
    14121289  </t>
    14131290</x:note>
     1291
     1292<section title="Whitespace" anchor="whitespace">
     1293<t anchor="rule.LWS">
     1294   This specification uses three rules to denote the use of linear
     1295   whitespace: OWS (optional whitespace), RWS (required whitespace), and
     1296   BWS ("bad" whitespace).
     1297</t>
     1298<t anchor="rule.OWS">
     1299   The OWS rule is used where zero or more linear whitespace octets might
     1300   appear. OWS &SHOULD; either not be produced or be produced as a single
     1301   SP. Multiple OWS octets that occur within field-content &SHOULD; either
     1302   be replaced with a single SP or transformed to all SP octets (each
     1303   octet other than SP replaced with SP) before interpreting the field value
     1304   or forwarding the message downstream.
     1305</t>
     1306<t anchor="rule.RWS">
     1307   RWS is used when at least one linear whitespace octet is required to
     1308   separate field tokens. RWS &SHOULD; be produced as a single SP.
     1309   Multiple RWS octets that occur within field-content &SHOULD; either
     1310   be replaced with a single SP or transformed to all SP octets before
     1311   interpreting the field value or forwarding the message downstream.
     1312</t>
     1313<t anchor="rule.BWS">
     1314   BWS is used where the grammar allows optional whitespace for historical
     1315   reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1
     1316   recipients &MUST; accept such bad optional whitespace and remove it before
     1317   interpreting the field value or forwarding the message downstream.
     1318</t>
     1319<t anchor="rule.whitespace">
     1320  <x:anchor-alias value="BWS"/>
     1321  <x:anchor-alias value="OWS"/>
     1322  <x:anchor-alias value="RWS"/>
     1323  <x:anchor-alias value="obs-fold"/>
     1324</t>
     1325<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OWS"/><iref primary="true" item="Grammar" subitem="RWS"/><iref primary="true" item="Grammar" subitem="BWS"/>
     1326  <x:ref>OWS</x:ref>            = *( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold )
     1327                 ; "optional" whitespace
     1328  <x:ref>RWS</x:ref>            = 1*( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> / obs-fold )
     1329                 ; "required" whitespace
     1330  <x:ref>BWS</x:ref>            = <x:ref>OWS</x:ref>
     1331                 ; "bad" whitespace
     1332  <x:ref>obs-fold</x:ref>       = <x:ref>CRLF</x:ref> ( <x:ref>SP</x:ref> / <x:ref>HTAB</x:ref> )
     1333                 ; obsolete line folding
     1334                 ; see <xref target="field.parsing"/>
     1335</artwork></figure>
     1336</section>
    14141337
    14151338<section title="Field Parsing" anchor="field.parsing">
    … …  
    14761399</section>
    14771400
    1478 <section title="Common Field ABNF Rules" anchor="field.rules">
     1401<section title="Field value components" anchor="field.components">
    14791402<t anchor="rule.token.separators">
    14801403  <x:anchor-alias value="tchar"/>
    … …  
    15531476   Senders &SHOULD-NOT; escape octets in comments that do not require escaping
    15541477   (i.e., other than the backslash octet "\" and the parentheses "(" and ")").
     1478</t>
     1479</section>
     1480
     1481<section title="ABNF list extension: #rule" anchor="abnf.extension">
     1482<t>
     1483  A #rule extension to the ABNF rules of <xref target="RFC5234"/> is used to
     1484  improve readability in the definitions of some header field values.
     1485</t>
     1486<t>
     1487  A construct "#" is defined, similar to "*", for defining comma-delimited
     1488  lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating
     1489  at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single
     1490  comma (",") and optional whitespace (OWS).   
     1491</t>
     1492<figure><preamble>
     1493  Thus,
     1494</preamble><artwork type="example">
     1495  1#element =&gt; element *( OWS "," OWS element )
     1496</artwork></figure>
     1497<figure><preamble>
     1498  and:
     1499</preamble><artwork type="example">
     1500  #element =&gt; [ 1#element ]
     1501</artwork></figure>
     1502<figure><preamble>
     1503  and for n &gt;= 1 and m &gt; 1:
     1504</preamble><artwork type="example">
     1505  &lt;n&gt;#&lt;m&gt;element =&gt; element &lt;n-1&gt;*&lt;m-1&gt;( OWS "," OWS element )
     1506</artwork></figure>
     1507<t>
     1508  For compatibility with legacy list rules, recipients &SHOULD; accept empty
     1509  list elements. In other words, consumers would follow the list productions:
     1510</t>
     1511<figure><artwork type="example">
     1512  #element =&gt; [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
     1513 
     1514  1#element =&gt; *( "," OWS ) element *( OWS "," [ OWS element ] )
     1515</artwork></figure>
     1516<t>
     1517  Note that empty elements do not contribute to the count of elements present,
     1518  though.
     1519</t>
     1520<t>
     1521  For example, given these ABNF productions:
     1522</t>
     1523<figure><artwork type="example">
     1524  example-list      = 1#example-list-elmt
     1525  example-list-elmt = token ; see <xref target="field.components"/>
     1526</artwork></figure>
     1527<t>
     1528  Then these are valid values for example-list (not including the double
     1529  quotes, which are present for delimitation only):
     1530</t>
     1531<figure><artwork type="example">
     1532  "foo,bar"
     1533  "foo ,bar,"
     1534  "foo , ,bar,charlie   "
     1535</artwork></figure>
     1536<t>
     1537  But these values would be invalid, as at least one non-empty element is
     1538  required:
     1539</t>
     1540<figure><artwork type="example">
     1541  ""
     1542  ","
     1543  ",   ,"
     1544</artwork></figure>
     1545<t>
     1546  <xref target="collected.abnf"/> shows the collected ABNF, with the list rules
     1547  expanded as explained above.
    15551548</t>
    15561549</section>
    … …  
    18111804<section title="Types of Request Target" anchor="request-target-types">
    18121805<t>
    1813    The four options for request-target are dependent on the nature of the
    1814    request.
     1806   The proper format choice of the four options available to request-target
     1807   depends on the method being requested and if the request is being made to
     1808   a proxy.
    18151809</t>   
    1816 <t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
    1817    The asterisk "*" form of request-target, which &MUST-NOT; be used
    1818    with any request method other than OPTIONS, means that the request
    1819    applies to the server as a whole (the listening process) rather than
    1820    to a specific named resource at that server.  For example,
     1810<t anchor="origin-form"><iref item="origin form (of request-target)"/>
     1811   The most common form of request-target is that used when making
     1812   a request to an origin server ("origin form") to access a resource
     1813   identified by an "http" (<xref target="http.uri"/>) or
     1814   "https" (<xref target="https.uri"/>) URI.
     1815   In this case, the absolute path and query components of the URI
     1816   &MUST; be transmitted as the request-target and the authority component
     1817   (excluding any userinfo) &MUST; be transmitted in a Host header field.
     1818   For example, a client wishing to retrieve a representation of the resource
     1819   identified as
     1820</t>
     1821<figure><artwork x:indent-with="  ">
     1822http://www.example.org/where?q=now
     1823</artwork></figure>
     1824<t>
     1825   directly from the origin server would open (or reuse) a TCP connection
     1826   to port 80 of the host "www.example.org" and send the lines:
    18211827</t>
    18221828<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1823 OPTIONS * HTTP/1.1
    1824 </artwork></figure>
     1829GET /where?q=now HTTP/1.1
     1830Host: www.example.org
     1831</artwork></figure>
     1832<t>
     1833   followed by the remainder of the request. Note that the origin form
     1834   of request-target always starts with an absolute path. If the target
     1835   resource's URI path is empty, then an absolute path of "/" &MUST; be
     1836   provided in the request-target.
     1837</t>
     1838<t>
     1839   If the request-target is percent-encoded
     1840   (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
     1841   &MUST; decode the request-target in order to
     1842   properly interpret the request. Servers &SHOULD; respond to invalid
     1843   request-targets with an appropriate status code.
     1844</t>
    18251845<t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/>
    1826    The "absolute-URI" form is &REQUIRED; when the request is being made to a
    1827    proxy. The proxy is requested to either forward the request or service it
    1828    from a valid cache, and then return the response. Note that the proxy &MAY;
    1829    forward the request on to another proxy or directly to the server
    1830    specified by the absolute-URI. In order to avoid request loops, a
    1831    proxy that forwards requests to other proxies &MUST; be able to
    1832    recognize and exclude all of its own server names, including
    1833    any aliases, local variations, and the numeric IP address. An example
    1834    Request-Line would be:
     1846   The "absolute-URI" form of request-target is &REQUIRED; when the request
     1847   is being made to a proxy.  The proxy is requested to either forward the
     1848   request or service it from a valid cache, and then return the response.
     1849   Note that the proxy &MAY; forward the request on to another proxy or
     1850   directly to the server specified by the absolute-URI.
     1851   In order to avoid request loops, a proxy that forwards requests to other
     1852   proxies &MUST; be able to recognize and exclude all of its own server
     1853   names, including any aliases, local variations, or literal IP addresses.
     1854   An example Request-Line would be:
    18351855</t>
    18361856<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    18501870</t>
    18511871<t anchor="authority-form"><iref item="authority form (of request-target)"/>
    1852    The "authority form" is only used by the CONNECT request method (&CONNECT;).
    1853 </t>
    1854 <t anchor="origin-form"><iref item="origin form (of request-target)"/>
    1855    The most common form of request-target is that used when making
    1856    a request to an origin server ("origin form").
    1857    In this case, the absolute path and query components of the URI
    1858    &MUST; be transmitted as the request-target, and the authority component
    1859    &MUST; be transmitted in a Host header field. For example, a client wishing
    1860    to retrieve a representation of the resource, as identified above,
    1861    directly from the origin server would open (or reuse) a TCP connection
    1862    to port 80 of the host "www.example.org" and send the lines:
     1872   The "authority form" of request-target, which &MUST-NOT; be used
     1873   with any request method other than CONNECT, is used to establish a
     1874   tunnel through one or more proxies (&CONNECT;).  For example,
    18631875</t>
    18641876<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1865 GET /pub/WWW/TheProject.html HTTP/1.1
    1866 Host: www.example.org
    1867 </artwork></figure>
    1868 <t>
    1869    followed by the remainder of the Request. Note that the origin form
    1870    of request-target always starts with an absolute path; if the target
    1871    resource's URI path is empty, then an absolute path of "/" &MUST; be
    1872    provided in the request-target.
    1873 </t>
     1877CONNECT www.example.com:80 HTTP/1.1
     1878</artwork></figure>
     1879<t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
     1880   The asterisk ("*") form of request-target, which &MUST-NOT; be used
     1881   with any request method other than OPTIONS, means that the request
     1882   applies to the server as a whole (the listening process) rather than
     1883   to a specific named resource at that server.  For example,
     1884</t>
     1885<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     1886OPTIONS * HTTP/1.1
     1887</artwork></figure>
    18741888<t>
    18751889   If a proxy receives an OPTIONS request with an absolute-URI form of
    … …  
    18941908</figure>
    18951909<t>
    1896    The request-target is transmitted in the format specified in
    1897    <xref target="http.uri"/>. If the request-target is percent-encoded
    1898    (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
    1899    &MUST; decode the request-target in order to
    1900    properly interpret the request. Servers &SHOULD; respond to invalid
    1901    request-targets with an appropriate status code.
    1902 </t>
    1903 <t>
    19041910   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
    19051911   parts of the received request-target when forwarding it to the next inbound
    … …  
    19071913   "*".
    19081914</t>
    1909 <x:note>
    1910   <t>
    1911     <x:h>Note:</x:h> The "no rewrite" rule above prevents the proxy from
    1912     changing the meaning of the request when the origin server is improperly
    1913     using a non-reserved URI character for a reserved purpose.  Implementors
    1914     need to be aware that some pre-HTTP/1.1 proxies have been known to
    1915     rewrite the request-target.
    1916   </t>
    1917 </x:note>
    19181915</section>
    19191916
    … …  
    49414938<t>
    49424939  Empty list elements in list productions have been deprecated.
    4943   (<xref target="notation.abnf"/>)
     4940  (<xref target="abnf.extension"/>)
    49444941</t>
    49454942<t>
    49464943  Rules about implicit linear whitespace between certain grammar productions
    4947   have been removed; now it's only allowed when specifically pointed out
    4948   in the ABNF.
    4949   (<xref target="basic.rules"/>)
     4944  have been removed; now whitespace is only allowed where specifically
     4945  defined in the ABNF.
     4946  (<xref target="whitespace"/>)
    49504947</t>
    49514948<t>
    … …  
    49654962  Non-ASCII content in header fields and reason phrase has been obsoleted and
    49664963  made opaque (the TEXT rule was removed).
    4967   (<xref target="field.rules"/>)
     4964  (<xref target="field.components"/>)
    49684965</t>
    49694966<t>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1516 r1518  
    2727  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY agent-driven-negotiation   "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    29   <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    30   <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    31   <!ENTITY field-rules                "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     29  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     30  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY field-components           "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3232  <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3333  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    346346  <x:anchor-alias value="SP"/>
    347347<t>
    348   This specification uses the ABNF syntax defined in &notation; (which
    349   extends the syntax defined in <xref target="RFC5234"/> with a list rule).
    350   <xref target="collected.abnf"/> shows the collected ABNF, with the list
    351   rule expanded.
     348   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     349   of <xref target="RFC5234"/> with the list rule extension defined in
     350   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     351   with the list rule expanded.
    352352</t>
    353353<t>
    … …  
    372372</t>
    373373<figure><artwork type="abnf2616">
    374   <x:ref>BWS</x:ref>           = &lt;BWS, defined in &basic-rules;&gt;
    375   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
    376   <x:ref>RWS</x:ref>           = &lt;RWS, defined in &basic-rules;&gt;
    377   <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &basic-rules;&gt;
    378   <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-rules;&gt;
    379   <x:ref>token</x:ref>         = &lt;token, defined in &field-rules;&gt;
     374  <x:ref>BWS</x:ref>           = &lt;BWS, defined in &whitespace;&gt;
     375  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     376  <x:ref>RWS</x:ref>           = &lt;RWS, defined in &whitespace;&gt;
     377  <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
     378  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-components;&gt;
     379  <x:ref>token</x:ref>         = &lt;token, defined in &field-components;&gt;
    380380</artwork></figure>
    381381</section>
    … …  
    392392<figure><!--Part1--><artwork type="abnf2616">
    393393  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in &uri;&gt;
    394   <x:ref>comment</x:ref>       = &lt;comment, defined in &field-rules;&gt;
     394  <x:ref>comment</x:ref>       = &lt;comment, defined in &field-components;&gt;
    395395  <x:ref>partial-URI</x:ref>   = &lt;partial-URI, defined in &uri;&gt;
    396396  <x:ref>product</x:ref>       = &lt;product, defined in &product-tokens;&gt;
    … …  
    525525<t>
    526526   New header field values typically have their syntax defined using ABNF
    527    (<xref target="RFC5234"/>), using the extensions defined in &notation-abnf;
     527   (<xref target="RFC5234"/>), using the extension defined in &abnf-extension;
    528528   as necessary, and are usually constrained to the range of ASCII characters.
    529529   Header fields needing a greater range of characters can use an encoding
    … …  
    534534   they need to be treated with care if they are allowed in the field-value's
    535535   payload. Typically, components that might contain a comma are protected with
    536    double-quotes using the quoted-string ABNF production (&field-rules;).
     536   double-quotes using the quoted-string ABNF production (&field-components;).
    537537</t>
    538538<t>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1514 r1518  
    1818  <!ENTITY architecture             "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1919  <!ENTITY notation                 "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    20   <!ENTITY notation-abnf            "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY abnf-extension           "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2121  <!ENTITY acks                     "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    22   <!ENTITY basic-rules              "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    23   <!ENTITY field-rules              "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     22  <!ENTITY whitespace               "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     23  <!ENTITY field-components         "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2424  <!ENTITY caching-neg-resp         "<xref target='Part6' x:rel='#caching.negotiated.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY header-transfer-encoding "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    312312  <x:anchor-alias value="VCHAR"/>
    313313<t>
    314   This specification uses the ABNF syntax defined in &notation; (which
    315   extends the syntax defined in <xref target="RFC5234"/> with a list rule).
    316   <xref target="collected.abnf"/> shows the collected ABNF, with the list
    317   rule expanded.
     314   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     315   of <xref target="RFC5234"/> with the list rule extension defined in
     316   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     317   with the list rule expanded.
    318318</t>
    319319<t>
    … …  
    335335</t>
    336336<figure><artwork type="abnf2616">
    337   <x:ref>OWS</x:ref>            = &lt;OWS, defined in &basic-rules;&gt;
    338   <x:ref>token</x:ref>          = &lt;token, defined in &field-rules;&gt;
    339   <x:ref>word</x:ref>           = &lt;word, defined in &field-rules;&gt;
     337  <x:ref>OWS</x:ref>            = &lt;OWS, defined in &whitespace;&gt;
     338  <x:ref>token</x:ref>          = &lt;token, defined in &field-components;&gt;
     339  <x:ref>word</x:ref>           = &lt;word, defined in &field-components;&gt;
    340340</artwork></figure>
    341341</section>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1514 r1518  
    1717  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1818  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    19   <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     19  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2020  <!ENTITY acks                       "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    21   <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    22   <!ENTITY field-rules                "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     21  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     22  <!ENTITY field-components           "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY header-date                "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2424  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    304304  <x:anchor-alias value="HTTP-date"/>
    305305<t>
    306   This specification uses the ABNF syntax defined in &notation; (which
    307   extends the syntax defined in <xref target="RFC5234"/> with a list rule).
    308   <xref target="collected.abnf"/> shows the collected ABNF, with the list
    309   rule expanded.
     306   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     307   of <xref target="RFC5234"/> with the list rule extension defined in
     308   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     309   with the list rule expanded.
    310310</t>
    311311<t>
    … …  
    323323</t>
    324324<figure><artwork type="abnf2616">
    325   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
    326   <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-rules;&gt;
     325  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     326  <x:ref>obs-text</x:ref>      = &lt;obs-text, defined in &field-components;&gt;
    327327  <x:ref>HTTP-date</x:ref>     = &lt;HTTP-date, defined in &http-date;&gt;
    328328</artwork></figure>

  • draft-ietf-httpbis/latest/p5-range.xml

    r1500 r1518  
    1717  <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1818  <!ENTITY notation                   "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    19   <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     19  <!ENTITY abnf-extension             "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2020  <!ENTITY acks                       "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    21   <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    22   <!ENTITY field-rules                "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     21  <!ENTITY whitespace                 "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     22  <!ENTITY field-components           "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY http-date                  "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2424  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    290290  <x:anchor-alias value="VCHAR"/>
    291291<t>
    292   This specification uses the ABNF syntax defined in &notation; (which
    293   extends the syntax defined in <xref target="RFC5234"/> with a list rule).
    294   <xref target="collected.abnf"/> shows the collected ABNF, with the list
    295   rule expanded.
     292   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     293   of <xref target="RFC5234"/> with the list rule extension defined in
     294   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     295   with the list rule expanded.
    296296</t>
    297297<t>
    … …  
    320320</t>
    321321<figure><artwork type="abnf2616">
    322   <x:ref>OWS</x:ref>        = &lt;OWS, defined in &basic-rules;&gt;
    323   <x:ref>token</x:ref>      = &lt;token, defined in &field-rules;&gt;
     322  <x:ref>OWS</x:ref>        = &lt;OWS, defined in &whitespace;&gt;
     323  <x:ref>token</x:ref>      = &lt;token, defined in &field-components;&gt;
    324324  <x:ref>HTTP-date</x:ref>  = &lt;HTTP-date, defined in &http-date;&gt;
    325325</artwork></figure>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1514 r1518  
    1515  <!ENTITY ID-MONTH "January">
    1616  <!ENTITY ID-YEAR "2012">
    17   <!ENTITY architecture               "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     17  <!ENTITY architecture                "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1818  <!ENTITY notation                    "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1919  <!ENTITY acks                        "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    20   <!ENTITY basic-rules                 "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    21   <!ENTITY field-rules                 "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY whitespace                  "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     21  <!ENTITY field-components            "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2222  <!ENTITY uri                         "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY effective-request-uri       "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    435435   <x:anchor-alias value="VCHAR"/>
    436436<t>
    437    This specification uses the ABNF syntax defined in &notation; (which
    438    extends the syntax defined in <xref target="RFC5234"/> with a list rule).
    439    <xref target="collected.abnf"/> shows the collected ABNF, with the list
    440    rule expanded.
     437   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     438   of <xref target="RFC5234"/> with the list rule extension defined in
     439   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     440   with the list rule expanded.
    441441</t>
    442442<t>
    … …  
    456456</t>
    457457<figure><artwork type="abnf2616">
    458   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
    459   <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-rules;&gt;
    460   <x:ref>token</x:ref>         = &lt;token, defined in &field-rules;&gt;
     458  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     459  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-components;&gt;
     460  <x:ref>token</x:ref>         = &lt;token, defined in &field-components;&gt;
    461461</artwork></figure>
    462462</section>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1500 r1518  
    1818  <!ENTITY architecture                 "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1919  <!ENTITY notation                     "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    20   <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     20  <!ENTITY abnf-extension               "<xref target='Part1' x:rel='#abnf.extension' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2121  <!ENTITY acks                         "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    22   <!ENTITY basic-rules                  "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    23   <!ENTITY field-rules                  "<xref target='Part1' x:rel='#field.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     22  <!ENTITY whitespace                   "<xref target='Part1' x:rel='#whitespace' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     23  <!ENTITY field-components             "<xref target='Part1' x:rel='#field.components' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2424  <!ENTITY effective-request-uri        "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    25   <!ENTITY msg-orient-and-buffering     "<xref target='Part1' x:rel='#message-orientation-and-buffering' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     25  <!ENTITY msg-orient-and-buffering     "<xref target='Part1' x:rel='#intermediaries' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2626  <!ENTITY end-to-end.and-hop-by-hop    "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2727  <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    275275  <x:anchor-alias value="SP"/>
    276276<t>
    277   This specification uses the ABNF syntax defined in &notation; (which
    278   extends the syntax defined in <xref target="RFC5234"/> with a list rule).
    279   <xref target="collected.abnf"/> shows the collected ABNF, with the list
    280   rule expanded.
     277   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     278   of <xref target="RFC5234"/> with the list rule extension defined in
     279   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     280   with the list rule expanded.
    281281</t>
    282282<t>
    … …  
    299299</t>
    300300<figure><artwork type="abnf2616">
    301   <x:ref>BWS</x:ref>           = &lt;BWS, defined in &basic-rules;&gt;
    302   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt;
    303   <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-rules;&gt;
    304   <x:ref>token</x:ref>         = &lt;token, defined in &field-rules;&gt;
     301  <x:ref>BWS</x:ref>           = &lt;BWS, defined in &whitespace;&gt;
     302  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     303  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-components;&gt;
     304  <x:ref>token</x:ref>         = &lt;token, defined in &field-components;&gt;
    305305</artwork></figure>
    306306</section>
    … …  
    492492    <x:lt>
    493493    <t>
    494       Authentication schemes need to be compatible with the inherent
    495       constraints of HTTP; for instance, that messages need to keep their
    496       semantics when inspected in isolation, thus an authentication scheme
    497       can not bind information to the TCP session over which the message
    498       was received (see &msg-orient-and-buffering;).
     494      HTTP authentication is presumed to be stateless: all of the information
     495      necessary to authenticate a request &MUST; be provided in the request,
     496      rather than be dependent on the server remembering prior requests.
     497      Authentication based on, or bound to, the underlying connection is
     498      outside the scope of this specification and inherently flawed unless
     499      steps are taken to ensure that the connection cannot be used by any
     500      party other than the authenticated user
     501      (see &msg-orient-and-buffering;).
    499502    </t>
    500503    </x:lt>
Note: See TracChangeset for help on using the changeset viewer.