Ignore:
Timestamp:
Mar 10, 2011, 10:45:30 PM (9 years ago)
Author:
fielding@…
Message:

Remove header field classifications.

Addresses #224 and #104

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

Legend:

Unmodified
Added
Removed

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

    r1161 r1163  
    3131  <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3232  <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    33   <!ENTITY request-header-fields  "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    34   <!ENTITY response-header-fields "<xref target='Part2' x:rel='#response.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3533  <!ENTITY status-codes           "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3634  <!ENTITY status-100             "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    517515</section>
    518516
    519 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
    520   <x:anchor-alias value="request-header"/>
    521   <x:anchor-alias value="response-header"/>
    522   <x:anchor-alias value="Cache-Control"/>
    523   <x:anchor-alias value="Pragma"/>
    524   <x:anchor-alias value="Warning"/>
    525   <x:anchor-alias value="MIME-Version"/>
    526 <t>
    527   The ABNF rules below are defined in other parts:
    528 </t>
    529 <figure><!-- Part2--><artwork type="abnf2616">
    530   <x:ref>request-header</x:ref>  = &lt;request-header, defined in &request-header-fields;&gt;
    531   <x:ref>response-header</x:ref> = &lt;response-header, defined in &response-header-fields;&gt;
    532 </artwork></figure>
    533 <figure><!-- Part3--><artwork type="abnf2616">
    534   <x:ref>MIME-Version</x:ref>    = &lt;MIME-Version, defined in &header-mime-version;&gt;
    535 </artwork></figure>
    536 <figure><!-- Part6--><artwork type="abnf2616">
    537   <x:ref>Cache-Control</x:ref>   = &lt;Cache-Control, defined in &header-pragma;&gt;
    538   <x:ref>Pragma</x:ref>          = &lt;Pragma, defined in &header-pragma;&gt;
    539   <x:ref>Warning</x:ref>         = &lt;Warning, defined in &header-warning;&gt;
    540 </artwork></figure>
    541 </section>
    542 
    543517</section>
    544518</section>
    … …  
    10951069   are never "public" and thus are ineligible for shared caching.
    10961070   Their default is "private" and might be further constrained via use
    1097    of the Cache-Control header field.
     1071   of the Cache-Control header field (&header-cache-control;).
    10981072</t>
    10991073<t>
    … …  
    15561530  <c>Connection</c> <c><xref target="header.connection"/></c>
    15571531  <c>Date</c> <c><xref target="header.date"/></c>
    1558   <c>Pragma</c> <c>&header-pragma;</c>
    15591532  <c>Trailer</c> <c><xref target="header.trailer"/></c>
    15601533  <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
    15611534  <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
    15621535  <c>Via</c> <c><xref target="header.via"/></c>
    1563   <c>Warning</c> <c>&header-warning;</c>
    1564   <c>MIME-Version</c> <c>&header-mime-version;</c>
    15651536</texttable>
    1566 <t>
    1567    General-header field names can be extended reliably only in
    1568    combination with a change in the protocol version. However, new or
    1569    experimental header fields might be given the semantics of general
    1570    header fields if all parties in the communication recognize them to
    1571    be general-header fields.
    1572 </t>
    15731537</section>
    15741538</section>
    … …  
    27732737    <t>
    27742738        If a client will wait for a 100 (Continue) response before
    2775         sending the request body, it &MUST; send an Expect request-header
     2739        sending the request body, it &MUST; send an Expect header
    27762740        field (&header-expect;) with the "100-continue" expectation.
    27772741    </t>
    27782742    <t>
    2779         A client &MUST-NOT; send an Expect request-header field (&header-expect;)
     2743        A client &MUST-NOT; send an Expect header field (&header-expect;)
    27802744        with the "100-continue" expectation if it does not intend
    27812745        to send a request body.
    … …  
    27952759   Requirements for HTTP/1.1 origin servers:
    27962760  <list style="symbols">
    2797     <t> Upon receiving a request which includes an Expect request-header
     2761    <t> Upon receiving a request which includes an Expect header
    27982762        field with the "100-continue" expectation, an origin server &MUST;
    27992763        either respond with 100 (Continue) status code and continue to read
    … …  
    28062770    </t>
    28072771    <t> An origin server &SHOULD-NOT;  send a 100 (Continue) response if
    2808         the request message does not include an Expect request-header
     2772        the request message does not include an Expect header
    28092773        field with the "100-continue" expectation, and &MUST-NOT; send a
    28102774        100 (Continue) response if such a request comes from an HTTP/1.0
    … …  
    28122776        compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)
    28132777        status code in response to an HTTP/1.1 PUT or POST request that does
    2814         not include an Expect request-header field with the "100-continue"
     2778        not include an Expect header field with the "100-continue"
    28152779        expectation. This exception, the purpose of which is
    28162780        to minimize any client processing delays associated with an
    … …  
    28292793    </t>
    28302794    <t> If an origin server receives a request that does not include an
    2831         Expect request-header field with the "100-continue" expectation,
     2795        Expect header field with the "100-continue" expectation,
    28322796        the request includes a request body, and the server responds
    28332797        with a final status code before reading the entire request body
    … …  
    28452809   Requirements for HTTP/1.1 proxies:
    28462810  <list style="symbols">
    2847     <t> If a proxy receives a request that includes an Expect request-header
     2811    <t> If a proxy receives a request that includes an Expect header
    28482812        field with the "100-continue" expectation, and the proxy
    28492813        either knows that the next-hop server complies with HTTP/1.1 or
    … …  
    28612825    <t> A proxy &MUST-NOT; forward a 100 (Continue) response if the
    28622826        request message was received from an HTTP/1.0 (or earlier)
    2863         client and did not include an Expect request-header field with
     2827        client and did not include an Expect header field with
    28642828        the "100-continue" expectation. This requirement overrides the
    28652829        general rule for forwarding of 1xx responses (see &status-1xx;).
    … …  
    28722836<t>
    28732837   If an HTTP/1.1 client sends a request which includes a request body,
    2874    but which does not include an Expect request-header field with the
     2838   but which does not include an Expect header field with the
    28752839   "100-continue" expectation, and if the client is not directly
    28762840   connected to an HTTP/1.1 origin server, and if the client sees the
    … …  
    28842848    </t>
    28852849    <t>
    2886       Transmit the request-header fields
     2850      Transmit the request-line, header fields, and the CRLF that
     2851      indicates the end of header fields.
    28872852    </t>
    28882853    <t>
    … …  
    29722937  <x:anchor-alias value="Connection-v"/>
    29732938<t>
    2974    The "Connection" general-header field allows the sender to specify
     2939   The "Connection" header field allows the sender to specify
    29752940   options that are desired for that particular connection and &MUST-NOT;
    29762941   be communicated by proxies over further connections.
    … …  
    29962961<t>
    29972962   Message header fields listed in the Connection header field &MUST-NOT; include
    2998    end-to-end header fields, such as Cache-Control.
     2963   end-to-end header fields, such as Cache-Control (&header-cache-control;).
    29992964</t>
    30002965<t>
    … …  
    30793044  <x:anchor-alias value="Date-v"/>
    30803045<t>
    3081    The "Date" general-header field represents the date and time at which
     3046   The "Date" header field represents the date and time at which
    30823047   the message was originated, having the same semantics as the Origination
    30833048   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
    … …  
    31553120  <x:anchor-alias value="Host-v"/>
    31563121<t>
    3157    The "Host" request-header field specifies the Internet host and port
     3122   The "Host" header field specifies the Internet host and port
    31583123   number of the resource being requested, allowing the origin server or
    31593124   gateway to differentiate between internally-ambiguous URLs, such as the root
    … …  
    32073172  <x:anchor-alias value="te-ext"/>
    32083173<t>
    3209    The "TE" request-header field indicates what extension transfer-codings
     3174   The "TE" header field indicates what extension transfer-codings
    32103175   it is willing to accept in the response, and whether or not it is
    32113176   willing to accept trailer fields in a chunked transfer-coding.
    … …  
    32883253  <x:anchor-alias value="Trailer-v"/>
    32893254<t>
    3290    The "Trailer" general-header field indicates that the given set of
     3255   The "Trailer" header field indicates that the given set of
    32913256   header fields is present in the trailer of a message encoded with
    32923257   chunked transfer-coding.
    … …  
    33243289  <x:anchor-alias value="Transfer-Encoding-v"/>
    33253290<t>
    3326    The "Transfer-Encoding" general-header field indicates what transfer-codings
     3291   The "Transfer-Encoding" header field indicates what transfer-codings
    33273292   (if any) have been applied to the message body. It differs from
    33283293   Content-Encoding (&content-codings;) in that transfer-codings are a property
    … …  
    33593324  <x:anchor-alias value="Upgrade-v"/>
    33603325<t>
    3361    The "Upgrade" general-header field allows the client to specify what
     3326   The "Upgrade" header field allows the client to specify what
    33623327   additional communication protocols it would like to use, if the server
    33633328   chooses to switch protocols. Servers can use it to indicate what protocols
    … …  
    34713436  <x:anchor-alias value="Via-v"/>
    34723437<t>
    3473    The "Via" general-header field &MUST; be used by gateways and proxies to
     3438   The "Via" header field &MUST; be used by gateways and proxies to
    34743439   indicate the intermediate protocols and recipients between the user
    34753440   agent and the server on requests, and between the origin server and
    … …  
    49224887<section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
    49234888<t>
    4924    The requirements that clients and servers support the Host request-header
     4889   The requirements that clients and servers support the Host header
    49254890   field (<xref target="header.host"/>), report an error if it is
    49264891   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    … …  
    49454910   requirements:
    49464911  <list style="symbols">
    4947      <t>Both clients and servers &MUST; support the Host request-header field.</t>
     4912     <t>Both clients and servers &MUST; support the Host header field.</t>
    49484913
    49494914     <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t>
    49504915
    49514916     <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1
    4952         request does not include a Host request-header field.</t>
     4917        request does not include a Host header field.</t>
    49534918
    49544919     <t>Servers &MUST; accept absolute URIs.</t>
    … …  
    50545019<x:ref>BWS</x:ref> = OWS
    50555020
    5056 <x:ref>Cache-Control</x:ref> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
    50575021<x:ref>Chunked-Body</x:ref> = *chunk last-chunk trailer-part CRLF
    50585022<x:ref>Connection</x:ref> = "Connection:" OWS Connection-v
    … …  
    50755039<x:ref>Host-v</x:ref> = uri-host [ ":" port ]
    50765040
    5077 <x:ref>MIME-Version</x:ref> = &lt;MIME-Version, defined in [Part3], Appendix A.1&gt;
    50785041<x:ref>Method</x:ref> = token
    50795042
    50805043<x:ref>OWS</x:ref> = *( [ obs-fold ] WSP )
    5081 
    5082 <x:ref>Pragma</x:ref> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
    50835044
    50845045<x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
    … …  
    51075068 ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
    51085069 ] )
    5109 
    5110 <x:ref>Warning</x:ref> = &lt;Warning, defined in [Part6], Section 3.6&gt;
    51115070
    51125071<x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
    … …  
    52035162<x:ref>received-protocol</x:ref> = [ protocol-name "/" ] protocol-version
    52045163<x:ref>relative-part</x:ref> = &lt;relative-part, defined in [RFC3986], Section 4.2&gt;
    5205 <x:ref>request-header</x:ref> = &lt;request-header, defined in [Part2], Section 3&gt;
    52065164<x:ref>request-target</x:ref> = "*" / absolute-URI / ( path-absolute [ "?" query ] )
    52075165 / authority
    5208 <x:ref>response-header</x:ref> = &lt;response-header, defined in [Part2], Section 5&gt;
    52095166<x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
    52105167<x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT
    … …  
    52385195</figure>
    52395196<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline">
    5240 ; Cache-Control defined but not used
    52415197; Chunked-Body defined but not used
    52425198; Connection defined but not used
    … …  
    52455201; HTTP-message defined but not used
    52465202; Host defined but not used
    5247 ; MIME-Version defined but not used
    5248 ; Pragma defined but not used
    52495203; Request defined but not used
    52505204; Response defined but not used
    … …  
    52555209; Upgrade defined but not used
    52565210; Via defined but not used
    5257 ; Warning defined but not used
    52585211; http-URI defined but not used
    52595212; https-URI defined but not used
    52605213; partial-URI defined but not used
    5261 ; request-header defined but not used
    5262 ; response-header defined but not used
    52635214; special defined but not used
    52645215</artwork></figure></section>

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

    r1161 r1163  
    246246   that defines the protocol referred to as "HTTP/1.1" and, taken together,
    247247   obsoletes RFC 2616.  Part 2 defines the semantics of HTTP messages
    248    as expressed by request methods, request-header fields, response status codes,
    249    and response-header fields.
     248   as expressed by request methods, request header fields, response status codes,
     249   and response header fields.
    250250</t>
    251251</abstract>
    … …  
    282282   In particular, the sections will be ordered according to the typical
    283283   processing of an HTTP request message (after message parsing): resource
    284    mapping, general header fields, methods, request modifiers, response
    285    status, and resource metadata.  The current mess reflects how widely
    286    dispersed these topics and associated requirements had become in
    287    <xref target="RFC2616"/>.
     284   mapping, methods, request modifying header fields, response status,
     285   status modifying header fields, and resource metadata.  The current mess
     286   reflects how widely dispersed these topics and associated requirements
     287   had become in <xref target="RFC2616"/>.
    288288</t>
    289289
    … …  
    530530  <x:anchor-alias value="request-header"/>
    531531<t>
    532    The request-header fields allow the client to pass additional
     532   The request header fields allow the client to pass additional
    533533   information about the request, and about the client itself, to the
    534534   server. These fields act as request modifiers, with semantics
    … …  
    560560  <c>User-Agent</c> <c><xref target="header.user-agent"/></c>
    561561</texttable>
    562 <t>
    563    Request-header field names can be extended reliably only in
    564    combination with a change in the protocol version. However, new or
    565    experimental header fields &MAY; be given the semantics of request-header
    566    fields if all parties in the communication recognize them to
    567    be request-header fields.
    568 </t>
    569562</section>
    570563
    … …  
    723716  <x:anchor-alias value="response-header"/>
    724717<t>
    725    The response-header fields allow the server to pass additional
     718   The response header fields allow the server to pass additional
    726719   information about the response which cannot be placed in the Status-Line.
    727720   These header fields give information about the server and about
    … …  
    729722</t>
    730723<texttable align="left">
    731   <ttcol>Method Name</ttcol><ttcol>Defined in...</ttcol>
     724  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
    732725
    733726  <c>Accept-Ranges</c> <c>&header-accept-ranges;</c>
    … …  
    742735  <c>WWW-Authenticate</c> <c>&header-www-authenticate;</c>
    743736</texttable>
    744 <t>
    745    Response-header field names can be extended reliably only in
    746    combination with a change in the protocol version. However, new or
    747    experimental header fields &MAY; be given the semantics of response-header
    748    fields if all parties in the communication recognize them to
    749    be response-header fields.
    750 </t>
    751737</section>
    752738
    … …  
    911897</t>
    912898<t>
    913    The Max-Forwards request-header field &MAY; be used to target a
     899   The Max-Forwards header field &MAY; be used to target a
    914900   specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    915901   If no Max-Forwards field is present in the request, then the forwarded
    … …  
    19671953  </rdf:Description>
    19681954<t>
    1969    The precondition given in one or more of the request-header fields
     1955   The precondition given in one or more of the header fields
    19701956   evaluated to false when it was tested on the server, as defined in
    19711957   &status-412;.
    … …  
    20222008  </rdf:Description>
    20232009<t>
    2024    The request included a Range request-header field (&header-range;) and none of
     2010   The request included a Range header field (&header-range;) and none of
    20252011   the range-specifier values in this field overlap the current extent
    20262012   of the selected resource. See &status-416;.
    … …  
    20322018  <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/>
    20332019<t>
    2034    The expectation given in an Expect request-header field (see <xref target="header.expect"/>)
     2020   The expectation given in an Expect header field (see <xref target="header.expect"/>)
    20352021   could not be met by this server, or, if the server is a proxy,
    20362022   the server has unambiguous evidence that the request could not be met
    … …  
    21712157  <x:anchor-alias value="Allow-v"/>
    21722158<t>
    2173    The "Allow" response-header field lists the set of methods advertised as
     2159   The "Allow" header field lists the set of methods advertised as
    21742160   supported by the target resource. The purpose of this field is strictly to
    21752161   inform the recipient of valid request methods associated with the resource.
    … …  
    22052191  <x:anchor-alias value="expect-params"/>
    22062192<t>
    2207    The "Expect" request-header field is used to indicate that particular
     2193   The "Expect" header field is used to indicate that particular
    22082194   server behaviors are required by the client.
    22092195</t>
    … …  
    22402226   return a 417 (Expectation Failed) status code if it receives a request
    22412227   with an expectation that it cannot meet. However, the Expect
    2242    request-header field itself is end-to-end; it &MUST; be forwarded if the
     2228   header field itself is end-to-end; it &MUST; be forwarded if the
    22432229   request is forwarded.
    22442230</t>
    … …  
    22592245  <x:anchor-alias value="mailbox"/>
    22602246<t>
    2261    The "From" request-header field, if given, &SHOULD; contain an Internet
     2247   The "From" header field, if given, &SHOULD; contain an Internet
    22622248   e-mail address for the human user who controls the requesting user
    22632249   agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
    … …  
    23072293  <x:anchor-alias value="Location-v"/>
    23082294<t>
    2309    The "Location" response-header field is used to identify a newly created
     2295   The "Location" header field is used to identify a newly created
    23102296   resource, or to redirect the recipient to a different location for
    23112297   completion of the request.
    … …  
    23692355  <x:anchor-alias value="Max-Forwards-v"/>
    23702356<t>
    2371    The "Max-Forwards" request-header field provides a mechanism with the
     2357   The "Max-Forwards" header field provides a mechanism with the
    23722358   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    23732359   methods to limit the number of times that the request is forwarded by
    … …  
    24042390  <x:anchor-alias value="Referer-v"/>
    24052391<t>
    2406    The "Referer" [sic] request-header field allows the client to specify the
     2392   The "Referer" [sic] header field allows the client to specify the
    24072393   URI of the resource from which the effective request URI was obtained (the
    24082394   "referrer", although the header field is misspelled.).
    … …  
    24452431  <x:anchor-alias value="Retry-After-v"/>
    24462432<t>
    2447    The response-header "Retry-After" field can be used with a 503 (Service
     2433   The header "Retry-After" field can be used with a 503 (Service
    24482434   Unavailable) response to indicate how long the service is expected to
    24492435   be unavailable to the requesting client. This field &MAY; also be used
    … …  
    24852471  <x:anchor-alias value="Server-v"/>
    24862472<t>
    2487    The "Server" response-header field contains information about the
     2473   The "Server" header field contains information about the
    24882474   software used by the origin server to handle the request.
    24892475</t>
    … …  
    25072493<t>
    25082494   If the response is being forwarded through a proxy, the proxy
    2509    application &MUST-NOT; modify the Server response-header field. Instead, it
     2495   application &MUST-NOT; modify the Server header field. Instead, it
    25102496   &MUST; include a Via field (as described in &header-via;).
    25112497</t>
    … …  
    25272513  <x:anchor-alias value="User-Agent-v"/>
    25282514<t>
    2529    The "User-Agent" request-header field contains information about the user
     2515   The "User-Agent" header field contains information about the user
    25302516   agent originating the request. User agents &SHOULD; include this field with
    25312517   requests.

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

    r1161 r1163  
    908908</t>
    909909<t>
    910    HTTP/1.1 includes the following request-header fields for enabling
     910   HTTP/1.1 includes the following header fields for enabling
    911911   server-driven negotiation through description of user agent
    912912   capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
    … …  
    914914   (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
    915915   However, an origin server is not limited to these dimensions and &MAY; vary
    916    the response based on any aspect of the request, including information
    917    outside the request-header fields or within extension header fields
    918    not defined by this specification.
     916   the response based on any aspect of the request, including aspects
     917   of the connection (e.g., IP address) or information within extension
     918   header fields not defined by this specification.
    919919</t>
    920920<x:note>
    … …  
    983983  <x:anchor-alias value="media-range"/>
    984984<t>
    985    The "Accept" request-header field can be used by user agents to specify
     985   The "Accept" header field can be used by user agents to specify
    986986   response media types that are acceptable. Accept header fields can be used to
    987987   indicate that the request is specifically limited to a small set of desired
    … …  
    11081108  <x:anchor-alias value="Accept-Charset-v"/>
    11091109<t>
    1110    The "Accept-Charset" request-header field can be used by user agents to
     1110   The "Accept-Charset" header field can be used by user agents to
    11111111   indicate what response character sets are acceptable. This field allows
    11121112   clients capable of understanding more comprehensive or special-purpose
    … …  
    11531153  <x:anchor-alias value="codings"/>
    11541154<t>
    1155    The "Accept-Encoding" request-header field can be used by user agents to
     1155   The "Accept-Encoding" header field can be used by user agents to
    11561156   indicate what response content-codings (<xref target="content.codings"/>)
    11571157   are acceptable in the response.
    … …  
    12431243  <x:anchor-alias value="language-range"/>
    12441244<t>
    1245    The "Accept-Language" request-header field can be used by user agents to
     1245   The "Accept-Language" header field can be used by user agents to
    12461246   indicate the set of natural languages that are preferred in the response.
    12471247   Language tags are defined in <xref target="language.tags"/>.
    … …  
    17361736<section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
    17371737<t>
    1738    Accept request-headers fields can reveal information about the user to all
     1738   Accept headers fields can reveal information about the user to all
    17391739   servers which are accessed. The Accept-Language header field in particular
    17401740   can reveal information the user would consider to be of a private
    … …  
    17501750   to omit the sending of Accept-Language header fields by default, and to ask
    17511751   the user whether or not to start sending Accept-Language header fields to a
    1752    server if it detects, by looking for any Vary response-header fields
     1752   server if it detects, by looking for any Vary header fields
    17531753   generated by the server, that such sending could improve the quality
    17541754   of service.
    … …  
    25262526<t>
    25272527   HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;
    2528    include a single MIME-Version general-header field to indicate what
     2528   include a single MIME-Version header field to indicate what
    25292529   version of the MIME protocol was used to construct the message. Use
    25302530   of the MIME-Version header field indicates that the message is in

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

    r1161 r1163  
    229229   A future draft will reorganize the sections to better reflect the content.
    230230   In particular, the sections on resource metadata will be discussed first
    231    and then followed by each conditional request-header field, concluding with a
     231   and then followed by each conditional request header field, concluding with a
    232232   definition of precedence and the expectation of ordering strong validator
    233233   checks before weak validator checks.  It is likely that more content from
    … …  
    442442  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
    443443<t>
    444    The precondition given in one or more of the request-header fields
     444   The precondition given in one or more of the header fields
    445445   evaluated to false when it was tested on the server. This response
    446446   code allows the client to place preconditions on the current resource
    … …  
    730730  <x:anchor-alias value="ETag-v"/>
    731731<t>
    732    The "ETag" response-header field provides the current value of the
     732   The "ETag" header field provides the current value of the
    733733   entity-tag (see <xref target="entity.tags"/>) for one representation of
    734734   the target resource.  An entity-tag
    … …  
    774774  <x:anchor-alias value="If-Match-v"/>
    775775<t>
    776    The "If-Match" request-header field is used to make a request method
     776   The "If-Match" header field is used to make a request method
    777777   conditional. A client that has one or more representations previously
    778778   obtained from the resource can verify that one of those representations is
    … …  
    844844  <x:anchor-alias value="If-Modified-Since-v"/>
    845845<t>
    846    The "If-Modified-Since" request-header field is used to make a request
     846   The "If-Modified-Since" header field is used to make a request
    847847   method conditional by date: if the representation that would have been
    848848   transferred in a 200 response to a GET request has not been modified since
    … …  
    885885   information with a minimum amount of transaction overhead.
    886886  <list><t>
    887       <x:h>Note:</x:h> The Range request-header field modifies the meaning of If-Modified-Since;
     887      <x:h>Note:</x:h> The Range header field modifies the meaning of If-Modified-Since;
    888888      see &header-range; for full details.
    889889    </t><t>
    … …  
    929929  <x:anchor-alias value="If-None-Match-v"/>
    930930<t>
    931    The "If-None-Match" request-header field is used to make a request method
     931   The "If-None-Match" header field is used to make a request method
    932932   conditional. A client that has one or more representations previously
    933933   obtained from the resource can verify that none of those representations is
    … …  
    10081008  <x:anchor-alias value="If-Unmodified-Since-v"/>
    10091009<t>
    1010    The "If-Unmodified-Since" request-header field is used to make a request
     1010   The "If-Unmodified-Since" header field is used to make a request
    10111011   method conditional.  If the representation that would have been transferred
    10121012   in a 200 response to a GET request on the same resource has not been modified

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

    r1145 r1163  
    417417<t>
    418418   A server &SHOULD; return a response with this status code if a request
    419    included a Range request-header field (<xref target="header.range"/>), and none of
     419   included a Range header field (<xref target="header.range"/>), and none of
    420420   the ranges-specifier values in this field overlap the current extent
    421421   of the selected resource, and the request did not include an If-Range
    422    request-header field (<xref target="header.if-range"/>). (For byte-ranges,
     422   header field (<xref target="header.if-range"/>). (For byte-ranges,
    423423   this means that the first-byte-pos of all of the byte-range-spec values were
    424424   greater than the current length of the selected resource.)
    … …  
    474474  <x:anchor-alias value="acceptable-ranges"/>
    475475<t>
    476    The "Accept-Ranges" response-header field allows a resource to indicate
     476   The "Accept-Ranges" header field allows a resource to indicate
    477477   its acceptance of range requests.
    478478</t>
    … …  
    643643<t>
    644644   If the server receives a request (other than one including an If-Range
    645    request-header field) with an unsatisfiable Range request-header
     645   header field) with an unsatisfiable Range header
    646646   field (that is, all of whose byte-range-spec values have a
    647647   first-byte-pos value greater than the current length of the selected
    … …  
    653653    <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested
    654654    range not satisfiable) response instead of a 200 (OK) response for
    655     an unsatisfiable Range request-header field, since not all servers
    656     implement this request-header field.
     655    an unsatisfiable Range header field, since not all servers
     656    implement this header field.
    657657  </t>
    658658</x:note>
    … …  
    667667   If a client has a partial copy of a representation in its cache, and wishes
    668668   to have an up-to-date copy of the entire representation in its cache, it
    669    could use the Range request-header field with a conditional GET (using
     669   could use the Range header field with a conditional GET (using
    670670   either or both of If-Unmodified-Since and If-Match.) However, if the
    671671   condition fails because the representation has been modified, the client
    … …  
    674674</t>
    675675<t>
    676    The "If-Range" request-header field allows a client to "short-circuit" the second
     676   The "If-Range" header field allows a client to "short-circuit" the second
    677677   request. Informally, its meaning is "if the representation is unchanged, send
    678678   me the part(s) that I am missing; otherwise, send me the entire new
    … …  
    826826  <x:anchor-alias value="other-range-set"/>
    827827<t>
    828    The "Range" request-header field defines the GET method (conditional or
     828   The "Range" header field defines the GET method (conditional or
    829829   not) to request one or more sub-ranges of the response representation body, instead
    830830   of the entire representation body.

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

    r1145 r1163  
    522522      <t>the request method associated with the stored response allows it to
    523523      be used for the presented request, and</t>
    524       <t>selecting request-header fields nominated by the stored response (if any)
     524      <t>selecting header fields nominated by the stored response (if any)
    525525      match those presented (see <xref target="caching.negotiated.responses"
    526526      />), and</t>
    … …  
    690690<section anchor="age.calculations" title="Calculating Age">
    691691<t>
    692    HTTP/1.1 uses the Age response-header field to convey the estimated age of the
     692   HTTP/1.1 uses the Age header field to convey the estimated age of the
    693693   response message when obtained from a cache. The Age field value is the
    694694   cache's estimate of the amount of time since the response was generated or
    … …  
    940940   When a cache receives a request that can be satisfied by a stored response
    941941   that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT;
    942    use that response unless all of the selecting request-header fields nominated by
     942   use that response unless all of the selecting header fields nominated by
    943943   the Vary header field match in both the original request (i.e., that associated
    944944   with the stored response), and the presented request.
    945945</t>
    946946<t>
    947    The selecting request-header fields from two requests are defined to match if and
     947   The selecting header fields from two requests are defined to match if and
    948948   only if those in the first request can be transformed to those in the
    949949   second request by applying any of the following:
    … …  
    953953      </t>
    954954      <t>
    955          combining multiple message-header fields with the same field name
     955         combining multiple header fields with the same field name
    956956         (see &header-fields;)
    957957      </t>
    … …  
    975975</t>
    976976<t>
    977    The stored response with matching selecting request-header fields is known as the
     977   The stored response with matching selecting header fields is known as the
    978978   selected response.
    979979</t>
    … …  
    10401040   <x:anchor-alias value="age-value"/>
    10411041<t>
    1042    The "Age" response-header field conveys the sender's estimate of the amount
     1042   The "Age" header field conveys the sender's estimate of the amount
    10431043   of time since the response was generated or successfully validated at the
    10441044   origin server. Age values are calculated as specified in <xref
    … …  
    10811081   <x:anchor-alias value="cache-response-directive"/>
    10821082<t>
    1083    The "Cache-Control" general-header field is used to specify directives for
     1083   The "Cache-Control" header field is used to specify directives for
    10841084   caches along the request/response chain. Such cache directives are
    10851085   unidirectional in that the presence of a directive in a request does not
    … …  
    15061506   <x:anchor-alias value="pragma-directive"/>
    15071507<t>
    1508    The "Pragma" general-header field is used to include
     1508   The "Pragma" header field is used to include
    15091509   implementation-specific directives that might apply to any recipient along
    15101510   the request/response chain. All pragma directives specify optional behavior
    … …  
    15321532   <t>
    15331533      <x:h>Note:</x:h> Because the meaning of "Pragma: no-cache" as a
    1534       response-header field is not actually specified, it does not provide a
     1534      header field is not actually specified, it does not provide a
    15351535      reliable replacement for "Cache-Control: no-cache" in a response.
    15361536   </t>
    … …  
    15481548   <x:anchor-alias value="Vary-v"/>
    15491549<t>
    1550    The "Vary" response-header field conveys the set of request-header fields
     1550   The "Vary" header field conveys the set of header fields
    15511551   that were used to select the representation.
    15521552</t>
    … …  
    15691569<t>
    15701570   The set of header fields named by the Vary field value is known as the
    1571    selecting request-header fields.
     1571   selecting header fields.
    15721572</t>
    15731573<t>
    … …  
    15831583<t>
    15841584   A Vary field value of "*" signals that unspecified parameters not limited
    1585    to the request-header fields (e.g., the network address of the client), play a
     1585   to the header fields (e.g., the network address of the client), play a
    15861586   role in the selection of the response representation; therefore, a cache
    15871587   cannot determine whether this response is appropriate. A proxy &MUST-NOT;
    … …  
    15891589</t>
    15901590<t>
    1591    The field-names given are not limited to the set of standard request-header
     1591   The field-names given are not limited to the set of standard header
    15921592   fields defined by this specification. Field names are case-insensitive.
    15931593</t>
    … …  
    16051605   <x:anchor-alias value="warn-text"/>
    16061606<t>
    1607    The "Warning" general-header field is used to carry additional information
     1607   The "Warning" header field is used to carry additional information
    16081608   about the status or transformation of a message that might not be reflected
    16091609   in the message. This information is typically used to warn about possible

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

    r1145 r1163  
    469469  <x:anchor-alias value="Authorization-v"/>
    470470<t>
    471    The "Authorization" request-header field allows a user agent to authenticate
     471   The "Authorization" header field allows a user agent to authenticate
    472472   itself with a server &mdash; usually, but not necessarily, after receiving a 401
    473473   (Unauthorized) response. Its value consists of credentials containing
    … …  
    499499         subsequent request. But (if the specified maximum age has
    500500         passed) a proxy cache &MUST; first revalidate it with the origin
    501          server, using the request-header fields from the new request to allow
     501         server, using the header fields from the new request to allow
    502502         the origin server to authenticate the new request. (This is the
    503503         defined behavior for s-maxage.) If the response includes "s-maxage=0",
    … …  
    509509         subsequent request. But if the response is stale, all caches
    510510         &MUST; first revalidate it with the origin server, using the
    511          request-header fields from the new request to allow the origin server
     511         header fields from the new request to allow the origin server
    512512         to authenticate the new request.</t>
    513513
    … …  
    524524  <x:anchor-alias value="Proxy-Authenticate-v"/>
    525525<t>
    526    The "Proxy-Authenticate" response-header field consists of a challenge that
     526   The "Proxy-Authenticate" header field consists of a challenge that
    527527   indicates the authentication scheme and parameters applicable to the proxy
    528528   for this effective request URI (&effective-request-uri;). It &MUST; be included as part
    … …  
    550550  <x:anchor-alias value="Proxy-Authorization-v"/>
    551551<t>
    552    The "Proxy-Authorization" request-header field allows the client to
     552   The "Proxy-Authorization" header field allows the client to
    553553   identify itself (or its user) to a proxy which requires
    554554   authentication. Its value consists of
    … …  
    579579  <x:anchor-alias value="WWW-Authenticate-v"/>
    580580<t>
    581    The "WWW-Authenticate" response-header field consists of at least one
     581   The "WWW-Authenticate" header field consists of at least one
    582582   challenge that indicates the authentication scheme(s) and parameters
    583583   applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401
Note: See TracChangeset for help on using the changeset viewer.