Ignore:
Timestamp:
08/07/12 18:15:03 (8 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1737 r1740  
    2727  <!ENTITY representation         "<xref target='Part2' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY header-cache-control   "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     29  <!ENTITY header-content-encoding    "<xref target='Part2' x:rel='#header.content-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     30  <!ENTITY header-content-range   "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY header-content-type    "<xref target='Part2' x:rel='#header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2932  <!ENTITY header-date            "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3033  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    609612   on security, since different applications of the protocol require
    610613   different error handling strategies.  For example, a Web browser might
    611    wish to transparently recover from a response where the Location header
    612    field doesn't parse according to the ABNF, whereas a systems control
     614   wish to transparently recover from a response where the <x:ref>Location</x:ref>
     615   header field doesn't parse according to the ABNF, whereas a systems control
    613616   client might consider any form of error recovery to be dangerous.
    614617</t>
     
    699702   the server incorrectly implements the HTTP specification, but only
    700703   after the client has attempted at least one normal request and determined
    701    from the response status or header fields (e.g., Server) that the
    702    server improperly handles higher request versions.
     704   from the response status or header fields (e.g., <x:ref>Server</x:ref>) that
     705   the server improperly handles higher request versions.
    703706</t>
    704707<t>
     
    720723   version of the protocol. Such protocol downgrades &SHOULD-NOT; be
    721724   performed unless triggered by specific client attributes, such as when
    722    one or more of the request header fields (e.g., User-Agent) uniquely
    723    match the values sent by a client known to be in error.
     725   one or more of the request header fields (e.g., <x:ref>User-Agent</x:ref>)
     726   uniquely match the values sent by a client known to be in error.
    724727</t>
    725728<t>
     
    11411144<t>
    11421145   The field-name token labels the corresponding field-value as having the
    1143    semantics defined by that header field.  For example, the Date header field
    1144    is defined in &header-date; as containing the origination
     1146   semantics defined by that header field.  For example, the <x:ref>Date</x:ref>
     1147   header field is defined in &header-date; as containing the origination
    11451148   timestamp for the message in which it appears.
    11461149</t>
     
    11671170   The order in which header fields with differing field names are
    11681171   received is not significant. However, it is "good practice" to send
    1169    header fields that contain control data first, such as Host on
    1170    requests and Date on responses, so that implementations can decide
    1171    when not to handle a message as early as possible.  A server &MUST;
    1172    wait until the entire header section is received before interpreting
     1172   header fields that contain control data first, such as <x:ref>Host</x:ref>
     1173   on requests and <x:ref>Date</x:ref> on responses, so that implementations
     1174   can decide when not to handle a message as early as possible.  A server
     1175   &MUST; wait until the entire header section is received before interpreting
    11731176   a request message, since later header fields might include conditionals,
    11741177   authentication credentials, or deliberately misleading duplicate
     
    15451548</t>
    15461549<t>
    1547    Unlike Content-Encoding (&content-codings;), Transfer-Encoding is a
    1548    property of the message, not of the payload, and thus &MAY; be added or
    1549    removed by any implementation along the request/response chain.
    1550    Additional information about the encoding parameters &MAY; be provided
    1551    by other header fields not defined by this specification.
     1550   Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;),
     1551   Transfer-Encoding is a property of the message, not of the payload, and thus
     1552   &MAY; be added or removed by any implementation along the request/response
     1553   chain. Additional information about the encoding parameters &MAY; be
     1554   provided by other header fields not defined by this specification.
    15521555</t>
    15531556<t>
     
    26212624   but it &MAY; add any of these fields if not already present. If an
    26222625   <x:ref>Expires</x:ref> header field is added, it &MUST; be given a
    2623    field-value identical to that of the Date header field in that response.
     2626   field value identical to that of the <x:ref>Date</x:ref> header field in
     2627   that response.
    26242628</t>
    26252629<t>
     
    26282632   any request:
    26292633  <list style="symbols">
    2630     <t>Content-Encoding</t>
    2631     <t>Content-Range</t>
    2632     <t>Content-Type</t>
     2634    <t><x:ref>Content-Encoding</x:ref> (&header-content-encoding;)</t>
     2635    <t><x:ref>Content-Range</x:ref> (&header-content-range;)</t>
     2636    <t><x:ref>Content-Type</x:ref> (&header-content-type;)</t>
    26332637  </list>
    26342638</t>
     
    28162820<t>
    28172821   Comments &MAY; be used in the Via header field to identify the software
    2818    of each recipient, analogous to the User-Agent and Server header fields.
    2819    However, all comments in the Via field are optional and &MAY; be removed
    2820    by any recipient prior to forwarding the message.
     2822   of each recipient, analogous to the <x:ref>User-Agent</x:ref> and
     2823   <x:ref>Server</x:ref> header fields. However, all comments in the Via field
     2824   are optional and &MAY; be removed by any recipient prior to forwarding the
     2825   message.
    28212826</t>
    28222827<t>
     
    31073112    <t>
    31083113        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    3109         sending the request body, it &MUST; send an Expect header
     3114        sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
    31103115        field (&header-expect;) with the "100-continue" expectation.
    31113116    </t>
    31123117    <t>
    3113         A client &MUST-NOT; send an Expect header field (&header-expect;)
    3114         with the "100-continue" expectation if it does not intend
    3115         to send a request body.
     3118        A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
     3119        the "100-continue" expectation if it does not intend to send a request
     3120        body.
    31163121    </t>
    31173122  </list>
     
    31293134   Requirements for HTTP/1.1 origin servers:
    31303135  <list style="symbols">
    3131     <t> Upon receiving a request which includes an Expect header
     3136    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
    31323137        field with the "100-continue" expectation, an origin server &MUST;
    31333138        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
     
    31403145    </t>
    31413146    <t> An origin server &SHOULD-NOT;  send a <x:ref>100 (Continue)</x:ref> response if
    3142         the request message does not include an Expect header
     3147        the request message does not include an <x:ref>Expect</x:ref> header
    31433148        field with the "100-continue" expectation, and &MUST-NOT; send a
    31443149        <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0
     
    31633168    </t>
    31643169    <t> If an origin server receives a request that does not include an
    3165         Expect header field with the "100-continue" expectation,
     3170        <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
    31663171        the request includes a request body, and the server responds
    31673172        with a final status code before reading the entire request body
     
    31793184   Requirements for HTTP/1.1 proxies:
    31803185  <list style="symbols">
    3181     <t> If a proxy receives a request that includes an Expect header
    3182         field with the "100-continue" expectation, and the proxy
     3186    <t> If a proxy receives a request that includes an <x:ref>Expect</x:ref>
     3187        header field with the "100-continue" expectation, and the proxy
    31833188        either knows that the next-hop server complies with HTTP/1.1 or
    31843189        higher, or does not know the HTTP version of the next-hop
     
    31953200    <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
    31963201        request message was received from an HTTP/1.0 (or earlier)
    3197         client and did not include an Expect header field with
     3202        client and did not include an <x:ref>Expect</x:ref> header field with
    31983203        the "100-continue" expectation. This requirement overrides the
    31993204        general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;).
     
    41344139    <x:defines>502 (Bad Gateway)</x:defines>
    41354140    <x:defines>505 (HTTP Version Not Supported)</x:defines>
     4141    <x:defines>Content-Encoding</x:defines>
     4142    <x:defines>Content-Type</x:defines>
     4143    <x:defines>Date</x:defines>
     4144    <x:defines>Expect</x:defines>
     4145    <x:defines>Location</x:defines>
     4146    <x:defines>Server</x:defines>
     4147    <x:defines>User-Agent</x:defines>
    41364148  </x:source>
    41374149</reference>
     
    41574169  <x:source basename="p4-conditional" href="p4-conditional.xml">
    41584170    <x:defines>304 (Not Modified)</x:defines>
     4171  </x:source>
     4172</reference>
     4173
     4174<reference anchor="Part5">
     4175  <front>
     4176    <title>HTTP/1.1, part 5: Range Requests and Partial Responses</title>
     4177    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
     4178      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
     4179      <address><email>fielding@gbiv.com</email></address>
     4180    </author>
     4181    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
     4182      <organization abbrev="W3C">World Wide Web Consortium</organization>
     4183      <address><email>ylafon@w3.org</email></address>
     4184    </author>
     4185    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
     4186      <organization abbrev="greenbytes">greenbytes GmbH</organization>
     4187      <address><email>julian.reschke@greenbytes.de</email></address>
     4188    </author>
     4189    <date month="&ID-MONTH;" year="&ID-YEAR;"/>
     4190  </front>
     4191  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>
     4192  <x:source href="p5-range.xml" basename="p5-range">
     4193    <x:defines>Content-Range</x:defines>
    41594194  </x:source>
    41604195</reference>
Note: See TracChangeset for help on using the changeset viewer.