Ignore:
Timestamp:
08/07/12 19:13:21 (10 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions (P1)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1740 r1741  
    3636  <!ENTITY header-pragma          "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3737  <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     38  <!ENTITY header-proxy-authenticate  "<xref target='Part7' x:rel='#header.proxy-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     39  <!ENTITY header-proxy-authorization "<xref target='Part7' x:rel='#header.proxy-authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3840  <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3941  <!ENTITY methods                "<xref target='Part2' x:rel='#methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    503505   that wishes to interoperate with third-party HTTP servers &MUST;
    504506   conform to HTTP user agent requirements on the gateway's inbound
    505    connection and &MUST; implement the Connection
    506    (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
    507    header fields for both connections.
     507   connection and &MUST; implement the <x:ref>Connection</x:ref>
     508   (<xref target="header.connection"/>) and <x:ref>Via</x:ref>
     509   (<xref target="header.via"/>) header fields for both connections.
    508510</t>
    509511<t><iref primary="true" item="tunnel"/>
    … …  
    662664   behavior of a recipient in the absence of such a field can change.
    663665   Unless specified otherwise, header fields defined in HTTP/1.1 are
    664    defined for all versions of HTTP/1.x.  In particular, the Host and
    665    Connection header fields ought to be implemented by all HTTP/1.x
    666    implementations whether or not they advertise conformance with HTTP/1.1.
     666   defined for all versions of HTTP/1.x.  In particular, the <x:ref>Host</x:ref>
     667   and <x:ref>Connection</x:ref> header fields ought to be implemented by all
     668   HTTP/1.x implementations whether or not they advertise conformance with
     669   HTTP/1.1.
    667670</t>
    668671<t>
    … …  
    674677   the message's HTTP version.  An unrecognized header field received
    675678   by a proxy &MUST; be forwarded downstream unless the header field's
    676    field-name is listed in the message's Connection header field
     679   field-name is listed in the message's <x:ref>Connection</x:ref> header field
    677680   (see <xref target="header.connection"/>).
    678681   These requirements allow HTTP's functionality to be enhanced without
    … …  
    11621165   to the procedures in &cons-new-header-fields;.
    11631166   Unrecognized header fields &MUST; be forwarded by a proxy unless the
    1164    field-name is listed in the Connection header field
     1167   field-name is listed in the <x:ref>Connection</x:ref> header field
    11651168   (<xref target="header.connection"/>) or the proxy is specifically
    11661169   configured to block or otherwise transform such fields.
    … …  
    14741477<t>
    14751478   The presence of a message body in a request is signaled by a
    1476    a Content-Length or Transfer-Encoding header field.
    1477    Request message framing is independent of method semantics,
     1479   a <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header
     1480   field. Request message framing is independent of method semantics,
    14781481   even if the method does not define any use for a message body.
    14791482</t>
    … …  
    14831486   status code (<xref target="status-code"/>).
    14841487   Responses to the HEAD request method never include a message body
    1485    because the associated response header fields (e.g., Transfer-Encoding,
    1486    Content-Length, etc.) only indicate what their values would have been
    1487    if the request method had been GET.
    1488    <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of
    1489    having a message body.
     1488   because the associated response header fields (e.g.,
     1489   <x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.) only
     1490   indicate what their values would have been if the request method had been
     1491   GET. <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel
     1492   mode instead of having a message body.
    14901493   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
    14911494   <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
    … …  
    15871590  <x:anchor-alias value="Content-Length"/>
    15881591<t>
    1589    When a message does not have a Transfer-Encoding header field and the
    1590    payload body length can be determined prior to being transferred, a
     1592   When a message does not have a <x:ref>Transfer-Encoding</x:ref> header field
     1593   and the payload body length can be determined prior to being transferred, a
    15911594   Content-Length header field &SHOULD; be sent to indicate the length of the
    15921595   payload body that is either present as the message body, for requests
    … …  
    16571660     Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request implies that the
    16581661     connection will become a tunnel immediately after the empty line that
    1659      concludes the header fields.  A client &MUST; ignore any Content-Length
    1660      or Transfer-Encoding header fields received in such a message.
     1662     concludes the header fields.  A client &MUST; ignore any
     1663     <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header
     1664     fields received in such a message.
    16611665    </t></x:lt>
    16621666    <x:lt><t>
    1663      If a Transfer-Encoding header field is present
     1667     If a <x:ref>Transfer-Encoding</x:ref> header field is present
    16641668     and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
    16651669     is the final encoding, the message body length is determined by reading
    … …  
    16681672    </t>
    16691673    <t>
    1670      If a Transfer-Encoding header field is present in a response and the
    1671      "chunked" transfer-coding is not the final encoding, the message body
    1672      length is determined by reading the connection until it is closed by
    1673      the server.
     1674     If a <x:ref>Transfer-Encoding</x:ref> header field is present in a
     1675     response and the "chunked" transfer-coding is not the final encoding, the
     1676     message body length is determined by reading the connection until it is
     1677     closed by the server.
    16741678     If a Transfer-Encoding header field is present in a request and the
    16751679     "chunked" transfer-coding is not the final encoding, the message body
    … …  
    16781682    </t>
    16791683    <t>
    1680      If a message is received with both a Transfer-Encoding header field
    1681      and a Content-Length header field, the Transfer-Encoding overrides
    1682      the Content-Length.
     1684     If a message is received with both a <x:ref>Transfer-Encoding</x:ref>
     1685     and a <x:ref>Content-Length</x:ref> header field, the
     1686     Transfer-Encoding overrides the Content-Length.
    16831687     Such a message might indicate an attempt to perform request or response
    16841688     smuggling (bypass of security-related checks on message routing or content)
    … …  
    16881692    </t></x:lt>
    16891693    <x:lt><t>
    1690      If a message is received without Transfer-Encoding and with either
    1691      multiple Content-Length header fields having differing field-values or
    1692      a single Content-Length header field having an invalid value, then the
    1693      message framing is invalid and &MUST; be treated as an error to
    1694      prevent request or response smuggling.
     1694     If a message is received without <x:ref>Transfer-Encoding</x:ref> and with
     1695     either multiple <x:ref>Content-Length</x:ref> header fields having
     1696     differing field-values or a single Content-Length header field having an
     1697     invalid value, then the message framing is invalid and &MUST; be treated
     1698     as an error to prevent request or response smuggling.
    16951699     If this is a request message, the server &MUST; respond with
    16961700     a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    … …  
    17021706    </t></x:lt>
    17031707    <x:lt><t>
    1704      If a valid Content-Length header field
    1705      is present without Transfer-Encoding, its decimal value defines the
     1708     If a valid <x:ref>Content-Length</x:ref> header field is present without
     1709     <x:ref>Transfer-Encoding</x:ref>, its decimal value defines the
    17061710     message body length in octets.  If the actual number of octets sent in
    17071711     the message is less than the indicated Content-Length, the recipient
    … …  
    17361740<t>
    17371741   A server &MAY; reject a request that contains a message body but
    1738    not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>.
     1742   not a <x:ref>Content-Length</x:ref> by responding with
     1743   <x:ref>411 (Length Required)</x:ref>.
    17391744</t>
    17401745<t>
    17411746   Unless a transfer-coding other than "chunked" has been applied,
    17421747   a client that sends a request containing a message body &SHOULD;
    1743    use a valid Content-Length header field if the message body length
    1744    is known in advance, rather than the "chunked" encoding, since some
     1748   use a valid <x:ref>Content-Length</x:ref> header field if the message body
     1749   length is known in advance, rather than the "chunked" encoding, since some
    17451750   existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    17461751   status code even though they understand the chunked encoding.  This
    … …  
    17511756<t>
    17521757   A client that sends a request containing a message body &MUST; include a
    1753    valid Content-Length header field if it does not know the server will
    1754    handle HTTP/1.1 (or later) requests; such knowledge can be in the form
    1755    of specific user configuration or by remembering the version of a prior
    1756    received response.
     1758   valid <x:ref>Content-Length</x:ref> header field if it does not know the
     1759   server will handle HTTP/1.1 (or later) requests; such knowledge can be in
     1760   the form of specific user configuration or by remembering the version of a
     1761   prior received response.
    17571762</t>
    17581763</section>
    … …  
    17771782   A message body that uses the chunked transfer encoding is
    17781783   incomplete if the zero-sized chunk that terminates the encoding has not
    1779    been received.  A message that uses a valid Content-Length is incomplete
    1780    if the size of the message body received (in octets) is less than the
    1781    value given by Content-Length.  A response that has neither chunked
     1784   been received.  A message that uses a valid <x:ref>Content-Length</x:ref> is
     1785   incomplete if the size of the message body received (in octets) is less than
     1786   the value given by Content-Length.  A response that has neither chunked
    17821787   transfer encoding nor Content-Length is terminated by closure of the
    17831788   connection, and thus is considered complete regardless of the number of
    … …  
    18661871   The HTTP Transfer Coding registry is defined in
    18671872   <xref target="transfer.coding.registry"/>.
    1868    HTTP/1.1 uses transfer-coding values in the TE header field
    1869    (<xref target="header.te"/>) and in the Transfer-Encoding header field
    1870    (<xref target="header.transfer-encoding"/>).
     1873   HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field
     1874   (<xref target="header.te"/>) and in the <x:ref>Transfer-Encoding</x:ref>
     1875   header field (<xref target="header.transfer-encoding"/>).
    18711876</t>
    18721877
    … …  
    19211926<t>
    19221927   The trailer allows the sender to include additional HTTP header
    1923    fields at the end of the message. The Trailer header field can be
    1924    used to indicate which header fields are included in a trailer (see
     1928   fields at the end of the message. The <x:ref>Trailer</x:ref> header field
     1929   can be used to indicate which header fields are included in a trailer (see
    19251930   <xref target="header.trailer"/>).
    19261931</t>
    … …  
    19301935   true:
    19311936  <list style="numbers">
    1932     <t>the request included a TE header field that indicates "trailers" is
    1933      acceptable in the transfer-coding of the  response, as described in
    1934     <xref target="header.te"/>; or,</t>
     1937    <t>the request included a <x:ref>TE</x:ref> header field that indicates
     1938    "trailers" is acceptable in the transfer-coding of the response, as
     1939    described in <xref target="header.te"/>; or,</t>
    19351940     
    19361941    <t>the trailer fields consist entirely of optional metadata, and the
    … …  
    20762081<t>
    20772082   The TE header field only applies to the immediate connection.
    2078    Therefore, the keyword &MUST; be supplied within a Connection header
    2079    field (<xref target="header.connection"/>) whenever TE is present in an HTTP/1.1 message.
     2083   Therefore, the keyword &MUST; be supplied within a <x:ref>Connection</x:ref>
     2084   header field (<xref target="header.connection"/>) whenever TE is present in
     2085   an HTTP/1.1 message.
    20802086</t>
    20812087<t>
    … …  
    21202126  <x:anchor-alias value="qvalue"/>
    21212127<t>
    2122    Both transfer codings (TE request header field, <xref target="header.te"/>)
    2123    and content negotiation (&content.negotiation;) use short "floating point"
    2124    numbers to indicate the relative importance ("weight") of various
    2125    negotiable parameters.  A weight is normalized to a real number in
    2126    the range 0 through 1, where 0 is the minimum and 1 the maximum
    2127    value. If a parameter has a quality value of 0, then content with
     2128   Both transfer codings (<x:ref>TE</x:ref> request header field,
     2129   <xref target="header.te"/>) and content negotiation (&content.negotiation;)
     2130   use short "floating point" numbers to indicate the relative importance
     2131   ("weight") of various negotiable parameters.  A weight is normalized to a
     2132   real number in the range 0 through 1, where 0 is the minimum and 1 the
     2133   maximum value. If a parameter has a quality value of 0, then content with
    21282134   this parameter is "not acceptable" for the client. HTTP/1.1
    21292135   applications &MUST-NOT; generate more than three digits after the
    … …  
    21712177   include the following header fields:
    21722178  <list style="symbols">
    2173     <t>Transfer-Encoding</t>
    2174     <t>Content-Length</t>
    2175     <t>Trailer</t>
     2179    <t><x:ref>Transfer-Encoding</x:ref></t>
     2180    <t><x:ref>Content-Length</x:ref></t>
     2181    <t><x:ref>Trailer</x:ref></t>
    21762182  </list>
    21772183</t>
    … …  
    22732279   If the target URI's path component is empty, then the client &MUST; send
    22742280   "/" as the path within the origin-form of request-target.
    2275    A Host header field is also sent, as defined in
     2281   A <x:ref>Host</x:ref> header field is also sent, as defined in
    22762282   <xref target="header.host"/>, containing the target URI's
    22772283   authority component (excluding any userinfo).
    … …  
    24282434   A server that receives an HTTP request message &MUST; reconstruct
    24292435   the user agent's original target URI, based on the pieces of information
    2430    learned from the request-target, Host, and connection context, in order
    2431    to identify the intended target resource and properly service the request.
    2432    The URI derived from this reconstruction process is referred to as the
    2433    "effective request URI".
     2436   learned from the request-target, <x:ref>Host</x:ref> header field, and
     2437   connection context, in order to identify the intended target resource and
     2438   properly service the request. The URI derived from this reconstruction
     2439   process is referred to as the "effective request URI".
    24342440</t>
    24352441<t>
    … …  
    24492455   If the request-target is in authority-form, then the effective
    24502456   request URI's authority component is the same as the request-target.
    2451    Otherwise, if a Host header field is supplied with a non-empty field-value,
    2452    then the authority component is the same as the Host field-value.
    2453    Otherwise, the authority component is the concatenation of the default
    2454    host name configured for the server, a colon (":"), and the connection's
    2455    incoming TCP port number in decimal form.
     2457   Otherwise, if a <x:ref>Host</x:ref> header field is supplied with a
     2458   non-empty field-value, then the authority component is the same as the
     2459   Host field-value. Otherwise, the authority component is the concatenation of
     2460   the default host name configured for the server, a colon (":"), and the
     2461   connection's incoming TCP port number in decimal form.
    24562462</t>
    24572463<t>
    … …  
    25032509<t>
    25042510   An origin server that does not allow resources to differ by requested
    2505    host &MAY; ignore the Host field-value and instead replace it with a
    2506    configured server name when constructing the effective request URI.
    2507 </t>
    2508 <t>
    2509    Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
    2510    attempt to use heuristics (e.g., examination of the URI path for
     2511   host &MAY; ignore the <x:ref>Host</x:ref> field-value and instead replace it
     2512   with a configured server name when constructing the effective request URI.
     2513</t>
     2514<t>
     2515   Recipients of an HTTP/1.0 request that lacks a <x:ref>Host</x:ref> header
     2516   field &MAY; attempt to use heuristics (e.g., examination of the URI path for
    25112517   something unique to a particular host) in order to guess the
    25122518   effective request URI's authority component.
    … …  
    25422548<t>
    25432549   Intermediaries that forward a message &MUST; implement the
    2544    Connection header field as specified in <xref target="header.connection"/>.
     2550   <x:ref>Connection</x:ref> header field as specified in
     2551   <xref target="header.connection"/>.
    25452552</t>
    25462553
    … …  
    25692576   The following HTTP/1.1 header fields are hop-by-hop header fields:
    25702577  <list style="symbols">
    2571       <t>Connection</t>
    2572       <t>Keep-Alive</t>
    2573       <t>Proxy-Authenticate</t>
    2574       <t>Proxy-Authorization</t>
    2575       <t>TE</t>
    2576       <t>Trailer</t>
    2577       <t>Transfer-Encoding</t>
    2578       <t>Upgrade</t>
     2578      <t><x:ref>Connection</x:ref></t>
     2579      <t>Keep-Alive (<xref target="RFC2068" x:fmt="of" x:sec="19.7.1.1"/>)</t>
     2580      <t><x:ref>Proxy-Authenticate</x:ref> (&header-proxy-authenticate;)</t>
     2581      <t><x:ref>Proxy-Authorization</x:ref> (&header-proxy-authorization;)</t>
     2582      <t><x:ref>TE</x:ref></t>
     2583      <t><x:ref>Trailer</x:ref></t>
     2584      <t><x:ref>Transfer-Encoding</x:ref></t>
     2585      <t><x:ref>Upgrade</x:ref></t>
    25792586  </list>
    25802587</t>
    … …  
    25832590</t>
    25842591<t>
    2585    Other hop-by-hop header fields &MUST; be listed in a Connection header field
    2586    (<xref target="header.connection"/>).
     2592   Other hop-by-hop header fields &MUST; be listed in a
     2593   <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>).
    25872594</t>
    25882595</section>
    … …  
    29302937   Persistent connections provide a mechanism by which a client and a
    29312938   server can signal the close of a TCP connection. This signaling takes
    2932    place using the Connection header field (<xref target="header.connection"/>). Once a close
    2933    has been signaled, the client &MUST-NOT; send any more requests on that
     2939   place using the <x:ref>Connection</x:ref> header field
     2940   (<xref target="header.connection"/>). Once a close has been signaled, the
     2941   client &MUST-NOT; send any more requests on that
    29342942   connection.
    29352943</t>
    … …  
    29382946<t>
    29392947   An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
    2940    maintain a persistent connection unless a Connection header field including
    2941    the connection option "close" was sent in the request. If the server
    2942    chooses to close the connection immediately after sending the
     2948   maintain a persistent connection unless a <x:ref>Connection</x:ref> header
     2949   field including the connection option "close" was sent in the request. If
     2950   the server chooses to close the connection immediately after sending the
    29432951   response, it &SHOULD; send a Connection header field including the
    29442952   connection option "close".
    … …  
    29472955   An HTTP/1.1 client &MAY; expect a connection to remain open, but would
    29482956   decide to keep it open based on whether the response from a server
    2949    contains a Connection header field with the connection option "close". In case
    2950    the client does not want to maintain a connection for more than that
    2951    request, it &SHOULD; send a Connection header field including the
     2957   contains a <x:ref>Connection</x:ref> header field with the connection option
     2958   "close". In case the client does not want to maintain a connection for more
     2959   than that request, it &SHOULD; send a Connection header field including the
    29522960   connection option "close".
    29532961</t>
    29542962<t>
    29552963   If either the client or the server sends the "close" option in the
    2956    Connection header field, that request becomes the last one for the
    2957    connection.
     2964   <x:ref>Connection</x:ref> header field, that request becomes the last one
     2965   for the connection.
    29582966</t>
    29592967<t>
    … …  
    32733281<t>
    32743282   The Upgrade header field only applies to the immediate connection.
    3275    Therefore, the upgrade keyword &MUST; be supplied within a Connection
    3276    header field (<xref target="header.connection"/>) whenever Upgrade is present in an
    3277    HTTP/1.1 message.
     3283   Therefore, the upgrade keyword &MUST; be supplied within a
     3284   <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>)
     3285   whenever Upgrade is present in an HTTP/1.1 message.
    32783286</t>
    32793287<t>
    … …  
    33763384   Furthermore, the header field-name "Close" shall be registered as
    33773385   "reserved", since using that name as an HTTP header field might
    3378    conflict with the "close" connection option of the "Connection"
     3386   conflict with the "close" connection option of the "<x:ref>Connection</x:ref>"
    33793387   header field (<xref target="header.connection"/>).
    33803388</t>
    … …  
    36393647<t>
    36403648   The HTTP Upgrade Token Registry defines the name space for protocol-name
    3641    tokens used to identify protocols in the Upgrade header field.
    3642    Each registered protocol-name is associated with contact information and
    3643    an optional set of specifications that details how the connection
     3649   tokens used to identify protocols in the <x:ref>Upgrade</x:ref> header
     3650   field. Each registered protocol name is associated with contact information
     3651   and an optional set of specifications that details how the connection
    36443652   will be processed after it has been upgraded.
    36453653</t>
    … …  
    42224230</reference>
    42234231
     4232<reference anchor="Part7">
     4233  <front>
     4234    <title>HTTP/1.1, part 7: Authentication</title>
     4235    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     4236      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     4237      <address><email>fielding@gbiv.com</email></address>
     4238    </author>
     4239    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
     4240      <organization abbrev="W3C">World Wide Web Consortium</organization>
     4241      <address><email>ylafon@w3.org</email></address>
     4242    </author>
     4243    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
     4244      <organization abbrev="greenbytes">greenbytes GmbH</organization>
     4245      <address><email>julian.reschke@greenbytes.de</email></address>
     4246    </author>
     4247    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
     4248  </front>
     4249  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;"/>
     4250  <x:source href="p7-auth.xml" basename="p7-auth">
     4251    <x:defines>Proxy-Authenticate</x:defines>
     4252    <x:defines>Proxy-Authorization</x:defines>
     4253  </x:source>
     4254</reference>
     4255
    42244256<reference anchor="RFC5234">
    42254257  <front>
    … …  
    48334865   Since HTTP/0.9 did not support header fields in a request,
    48344866   there is no mechanism for it to support name-based virtual
    4835    hosts (selection of resource by inspection of the Host header
     4867   hosts (selection of resource by inspection of the <x:ref>Host</x:ref> header
    48364868   field).  Any server that implements name-based virtual hosts
    48374869   ought to disable support for HTTP/0.9.  Most requests that
    … …  
    48504882<section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
    48514883<t>
    4852    The requirements that clients and servers support the Host header
    4853    field (<xref target="header.host"/>), report an error if it is
     4884   The requirements that clients and servers support the <x:ref>Host</x:ref>
     4885   header field (<xref target="header.host"/>), report an error if it is
    48544886   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    48554887   are among the most important changes defined by HTTP/1.1.
    … …  
    48594891   addresses and servers; there was no other established mechanism for
    48604892   distinguishing the intended server of a request than the IP address
    4861    to which that request was directed. The Host header field was
     4893   to which that request was directed. The <x:ref>Host</x:ref> header field was
    48624894   introduced during the development of HTTP/1.1 and, though it was
    48634895   quickly implemented by most HTTP/1.0 browsers, additional requirements
    … …  
    48814913   with a "Connection: keep-alive" request header field. However, some
    48824914   experimental implementations of HTTP/1.0 persistent connections are faulty;
    4883    for example, if a HTTP/1.0 proxy server doesn't understand Connection, it
    4884    will erroneously forward that header to the next inbound server, which
    4885    would result in a hung connection.
     4915   for example, if a HTTP/1.0 proxy server doesn't understand
     4916   <x:ref>Connection</x:ref>, it will erroneously forward that header to the
     4917   next inbound server, which would result in a hung connection.
    48864918</t>
    48874919<t>
    … …  
    49424974</t>
    49434975<t>
    4944   Require recipients to handle bogus Content-Length header fields as errors.
     4976  Require recipients to handle bogus <x:ref>Content-Length</x:ref> header
     4977  fields as errors.
    49454978  (<xref target="message.body"/>)
    49464979</t>
    … …  
    49805013</t>
    49815014<t>
    4982   Define the semantics of the "Upgrade" header field in responses other than
    4983   101 (this was incorporated from <xref target="RFC2817"/>).
     5015  Define the semantics of the <x:ref>Upgrade</x:ref> header field in responses
     5016  other than 101 (this was incorporated from <xref target="RFC2817"/>).
    49845017  (<xref target="header.upgrade"/>)
    49855018</t>
Note: See TracChangeset for help on using the changeset viewer.