Ignore:
Timestamp:
07/09/10 11:46:12 (11 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r981 r994  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-09-01">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: March 5, 2011</td>
     436               <td class="left">Expires: March 11, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">September 1, 2010</td>
     489               <td class="right">September 7, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire on March 5, 2011.</p>
     516      <p>This Internet-Draft will expire on March 11, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    917917         </li>
    918918         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
    919             representation of the target (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    920          </li>
    921          <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
     919            representation of the target (see <a href="p6-cache.html#combining.responses" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     920         </li>
     921         <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
    922922            is a representation of the target resource.
    923923         </li>
    924          <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
     924         <li>If the response has a Content-Location header field, and that URI is not the same as the effective request URI, then the response
    925925            asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
    926926            cannot be trusted unless it can be verified by other means (not defined by HTTP).
    … …  
    10051005      <div id="rfc.iref.h.1"></div>
    10061006      <div id="rfc.iref.m.3"></div>
    1007       <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP headers in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
     1007      <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
    10081008         representation implied by the request without transferring the representation body. This method is often used for testing
    10091009         hypertext links for validity, accessibility, and recent modification.
    … …  
    10331033      </p>
    10341034      <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
    1035          a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    1036       </p>
    1037       <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
     1035         a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
     1036      </p>
     1037      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
    10381038      </p>
    10391039      <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
    … …  
    10511051         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    10521052      </p>
    1053       <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1053      <p id="rfc.section.7.6.p.3">If the target resource could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* header fields (headers starting with the prefix "Content-") that it does not understand or implement
     1054         and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    10541055      </p>
    10551056      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
    … …  
    11061107      <p id="rfc.section.8.p.1">Each Status-Code is described below, including any metadata required in the response.</p>
    11071108      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
    1108       <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is
    1109          terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any
    1110          1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     1109      <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional header fields,
     1110         and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did
     1111         not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    11111112      </p>
    11121113      <p id="rfc.section.8.1.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100
    … …  
    13611362      <div id="rfc.iref.s.24"></div>
    13621363      <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1363       <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
     1364      <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an Allow header field containing a list of valid methods for the requested resource.
    13641365      </p>
    13651366      <div id="rfc.iref.48"></div>
    … …  
    13671368      <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    13681369      <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    1369          not acceptable according to the accept headers sent in the request.
     1370         not acceptable according to the accept header fields sent in the request.
    13701371      </p>
    13711372      <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
    … …  
    13741375      </p>
    13751376      <div class="note" id="rfc.section.8.4.7.p.3">
    1376          <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.
    1377             In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the headers
    1378             of an incoming response to determine if it is acceptable.
     1377         <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept header fields sent in the
     1378            request. In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the
     1379            header fields of an incoming response to determine if it is acceptable.
    13791380         </p>
    13801381      </div>
    … …  
    14901491      <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
    14911492      <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication
    1492          is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
     1493         is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.
    14931494      </p>
    14941495      <div class="note" id="rfc.section.8.5.4.p.2">
    … …  
    15511552      </p>
    15521553      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the
    1553          Expect request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    1554       </p>
    1555       <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
     1554         Expect request-header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
     1555      </p>
     1556      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    15561557      <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
    15571558      </p>
    … …  
    15681569      <div id="rfc.figure.u.16"></div><pre class="text">  From: webmaster@example.org
    15691570</pre><p id="rfc.section.9.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    1570          on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving
     1571         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving
    15711572         end.
    15721573      </p>
    … …  
    15961597</pre><p id="rfc.section.9.4.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p>
    15971598      <ul>
    1598          <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li>
     1599         <li>With a 201 Created response, because in this usage the Location header field specifies the URI for the entire created resource.</li>
    15991600         <li>With 305 Use Proxy.</li>
    16001601      </ul>
    … …  
    16291630         URI was obtained (the "referrer", although the header field is misspelled.).
    16301631      </p>
    1631       <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc.
    1632          It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
     1632      <p id="rfc.section.9.6.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
     1633         etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
    16331634         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
    16341635      </p>
    … …  
    16731674</pre><p id="rfc.section.9.8.p.4">Example:</p>
    16741675      <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    1675 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1676</pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    16761677      </p>
    16771678      <div class="note" id="rfc.section.9.8.p.7">
    … …  
    20982099         they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any Via fields generated behind the firewall.
    20992100      </p>
    2100       <p id="rfc.section.11.1.p.4">The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power
    2101          can be abused if user details are not separated from the information contained in the Referer. Even when the personal information
    2102          has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.
     2101      <p id="rfc.section.11.1.p.4">The Referer header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its
     2102         power can be abused if user details are not separated from the information contained in the Referer. Even when the personal
     2103         information has been removed, the Referer header field might indicate a private document's URI whose publication would be
     2104         inappropriate.
    21032105      </p>
    21042106      <p id="rfc.section.11.1.p.5">The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and
    … …  
    21122114         has no better mechanism.
    21132115      </p>
    2114       <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request headers within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
    2115          data from the client.
     2116      <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request header fields within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other header fields that might be used
     2117         to collect data from the client.
    21162118      </p>
    21172119      <h2 id="rfc.section.11.2"><a href="#rfc.section.11.2">11.2</a>&nbsp;<a id="encoding.sensitive.information.in.uris" href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></h2>
    … …  
    21282130      </p>
    21292131      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
    2130       <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location headers in responses that are generated under control of said organizations
     2132      <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    21312133         to make sure that they do not attempt to invalidate resources over which they have no authority.
    21322134      </p>
    … …  
    22522254         was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;8.3.6</a>)
    22532255      </p>
    2254       <p id="rfc.section.A.p.5">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement
    2255          on the contents of the Allow header and remove requirement on clients to always trust the header value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.1</a>)
    2256       </p>
    2257       <p id="rfc.section.A.p.6">Correct syntax of Location header to allow URI references (including relative references and fragments), as referred symbol
    2258          "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
     2256      <p id="rfc.section.A.p.5">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
     2257         on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.1</a>)
     2258      </p>
     2259      <p id="rfc.section.A.p.6">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
     2260         symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    22592261         (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;9.4</a>)
    22602262      </p>
    2261       <p id="rfc.section.A.p.7">Allow Referer value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.6</a>)
    2262       </p>
    2263       <p id="rfc.section.A.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly
    2264          in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
     2263      <p id="rfc.section.A.p.7">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.6</a>)
     2264      </p>
     2265      <p id="rfc.section.A.p.8">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
     2266         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
    22652267      </p>
    22662268      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    24222424      </p>
    24232425      <ul>
    2424          <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header.</li>
     2426         <li>Move "Product Tokens" section (back) into Part 1, as "token" is used in the definition of the Upgrade header field.</li>
    24252427         <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li>
    24262428         <li>Copy definition of delta-seconds from Part6 instead of referencing it.</li>
    … …  
    24442446         </li>
    24452447      </ul>
    2446       <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     2448      <p id="rfc.section.C.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    24472449      </p>
    24482450      <ul>
    2449          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     2451         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    24502452      </ul>
    24512453      <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
    … …  
    24822484         <li>Use "/" instead of "|" for alternatives.</li>
    24832485         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    2484          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     2486         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    24852487      </ul>
    24862488      <h2 id="rfc.section.C.7"><a href="#rfc.section.C.7">C.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p2-semantics-05</a></h2>
Note: See TracChangeset for help on using the changeset viewer.