Ignore:
Timestamp:
15/09/13 01:06:52 (7 years ago)
Author:
fielding@…
Message:

uniform terminology for header section instead of header block; this and [2400] addresses #234

File:
1 edited

Legend:

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

    r2400 r2401  
    11671167         and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore
    11681168         the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received
    1169          or the header block is terminated).
     1169         or the header section is terminated).
    11701170      </p>
    11711171      <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing
     
    13241324      </p>
    13251325      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>
    1326       <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole,
     1326      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header section as a whole,
    13271327         as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
    13281328         semantics.
     
    14521452      <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    14531453      </p>
    1454       <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header block. This will
    1455          allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
     1454      <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This
     1455         will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
    14561456         the connection for additional requests.
    14571457      </p>
     
    15411541         a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    15421542      </p>
    1543       <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely
    1544          on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
     1543      <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might
     1544         rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
    15451545         the client might need to repeat the request in order to determine what action to take next.
    15461546      </p>
     
    15481548         not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response
    15491549         that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered
    1550          complete regardless of the number of message body octets received, provided that the header block was received intact.
     1550         complete regardless of the number of message body octets received, provided that the header section was received intact.
    15511551      </p>
    15521552      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
     
    16211621      <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that
    16221622         might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
    1623          status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message
    1624          header block.
     1623         status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's
     1624         header section.
    16251625      </p>
    16261626      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.75"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
     
    26382638         a Denial of Service against implementations that accept fields with unlimited lengths.
    26392639      </p>
    2640       <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
     2640      <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
    26412641         that most implementations will choose substantially higher limits.
    26422642      </p>
Note: See TracChangeset for help on using the changeset viewer.