Ignore:
Timestamp:
08/07/12 19:13:21 (8 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/p2-semantics.xml

    r1740 r1741  
    551551   future extensions to HTTP. Content negotiation &MAY; be used to select
    552552   the appropriate response format. If no response body is included, the
    553    response &MUST; include a Content-Length field with a field-value of
    554    "0".
     553   response &MUST; include a <x:ref>Content-Length</x:ref> field with a
     554   field-value of "0".
    555555</t>
    556556<t>
     
    881881   TRACE allows the client to see what is being received at the other
    882882   end of the request chain and use that data for testing or diagnostic
    883    information. The value of the Via header field (&header-via;) is of
    884    particular interest, since it acts as a trace of the request chain.
     883   information. The value of the <x:ref>Via</x:ref> header field (&header-via;)
     884   is of particular interest, since it acts as a trace of the request chain.
    885885   Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
    886886   limit the length of the request chain, which is useful for testing a chain of
     
    921921   The tunneled data from the server begins immediately after the blank line
    922922   that concludes the successful response's header block.
    923    A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
    924    header fields in a successful response.
     923</t>
     924<t>
     925   A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
     926   <x:ref>Content-Length</x:ref> header fields in a successful response.
    925927   A client &MUST; ignore any Content-Length or Transfer-Encoding header
    926928   fields received in a successful response.
     
    10561058    responses or requests, in all messages, only on responses to a particular
    10571059    request method.</t></x:lt>
    1058     <x:lt><t>Whether it is appropriate to list the field-name in the Connection header
    1059     (i.e., if the header is to be hop-by-hop, see &header-connection;).</t></x:lt>
     1060    <x:lt><t>Whether it is appropriate to list the field-name in the
     1061    <x:ref>Connection</x:ref> header field (i.e., if the header field is to
     1062    be hop-by-hop, see &header-connection;).</t></x:lt>
    10601063    <x:lt><t>Under what conditions intermediaries are allowed to modify the header
    10611064    field's value, insert or delete it.</t></x:lt>
     
    13471350  <x:anchor-alias value="101 (Switching Protocols)"/>
    13481351<t>
    1349    The server understands and is willing to comply with the client's
    1350    request, via the Upgrade message header field (&header-upgrade;), for a
    1351    change in the application protocol being used on this connection. The
    1352    server will switch protocols to those defined by the response's
    1353    Upgrade header field immediately after the empty line which
    1354    terminates the 101 response.
     1352   The server understands and is willing to comply with the client's request,
     1353   via the <x:ref>Upgrade</x:ref> message header field (&header-upgrade;), for
     1354   a change in the application protocol being used on this connection. The
     1355   server will switch protocols to those defined by the response's Upgrade
     1356   header field immediately after the empty line which terminates the 101
     1357   response.
    13551358</t>
    13561359<t>
     
    19841987  <x:anchor-alias value="411 (Length Required)"/>
    19851988<t>
    1986    The server refuses to accept the request without a defined Content-Length.
    1987    The client &MAY; repeat the request if it adds a valid
    1988    Content-Length header field containing the length of the message body
    1989    in the request message.
     1989   The server refuses to accept the request without a defined
     1990   <x:ref>Content-Length</x:ref>. The client &MAY; repeat the request if it
     1991   adds a valid Content-Length header field containing the length of the
     1992   message body in the request message.
    19901993</t>
    19911994</section>
     
    20532056<t>
    20542057   The request can not be completed without a prior protocol upgrade. This
    2055    response &MUST; include an Upgrade header field (&header-upgrade;)
    2056    specifying the required protocols.
     2058   response &MUST; include an <x:ref>Upgrade</x:ref> header field
     2059   (&header-upgrade;) specifying the required protocols.
    20572060</t>
    20582061<figure>
     
    26612664   A payload body is only present in a message when a message body is
    26622665   present, as described in &message-body;. The payload body is obtained
    2663    from the message body by decoding any Transfer-Encoding that might
    2664    have been applied to ensure safe and proper transfer of the message.
     2666   from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that
     2667   might have been applied to ensure safe and proper transfer of the message.
    26652668</t>
    26662669</section>
     
    27012704   A representation body is only present in a message when a message body is
    27022705   present, as described in &message-body;. The representation body is obtained
    2703    from the message body by decoding any Transfer-Encoding that might
    2704    have been applied to ensure safe and proper transfer of the message.
     2706   from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that
     2707   might have been applied to ensure safe and proper transfer of the message.
    27052708</t>
    27062709
     
    39383941</artwork></figure>
    39393942<t>
    3940    If the response is being forwarded through a proxy, the proxy
    3941    application &MUST-NOT; modify the Server header field. Instead, it
    3942    &MUST; include a Via field (as described in &header-via;).
     3943   If the response is being forwarded through a proxy, the proxy application
     3944   &MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it
     3945   &MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;).
    39433946</t>
    39443947<x:note>
     
    44784481   take special precautions regarding the transfer of header information
    44794482   that identifies the hosts behind the firewall. In particular, they
    4480    &SHOULD; remove, or replace with sanitized versions, any Via fields
    4481    generated behind the firewall.
     4483   &SHOULD; remove, or replace with sanitized versions, any <x:ref>Via</x:ref>
     4484   fields generated behind the firewall.
    44824485</t>
    44834486<t>
     
    46454648  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
    46464649  <x:source href="p1-messaging.xml" basename="p1-messaging">
     4650    <x:defines>Connection</x:defines>
    46474651    <x:defines>Content-Length</x:defines>
    46484652    <x:defines>Transfer-Encoding</x:defines>
     4653    <x:defines>Upgrade</x:defines>
    46494654    <x:defines>Via</x:defines>
    46504655  </x:source>
     
    54435448<section title="Introduction of Transfer-Encoding" anchor="introduction.of.transfer-encoding">
    54445449<t>
    5445    HTTP/1.1 introduces the Transfer-Encoding header field (&header-transfer-encoding;).
    5446    Proxies/gateways &MUST; remove any transfer-coding prior to
    5447    forwarding a message via a MIME-compliant protocol.
     5450   HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field
     5451   (&header-transfer-encoding;). Proxies/gateways &MUST; remove any
     5452   transfer-coding prior to forwarding a message via a MIME-compliant protocol.
    54485453</t>
    54495454</section>
Note: See TracChangeset for help on using the changeset viewer.