Ignore:
Timestamp:
15/09/13 01:06:52 (8 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.xml

    r2400 r2401  
    10721072   (i.e., ignore the entire line, along with any subsequent lines preceded
    10731073   by whitespace, until a properly formed header field is received or the
    1074    header block is terminated).
     1074   header section is terminated).
    10751075</t>
    10761076<t>
     
    14141414<t>
    14151415   HTTP does not place a pre-defined limit on the length of each header field
    1416    or on the length of the header block as a whole, as described in
     1416   or on the length of the header section as a whole, as described in
    14171417   <xref target="conformance"/>. Various ad-hoc limitations on individual
    14181418   header field length are found in practice, often depending on the specific
     
    17011701   Aside from the cases defined above, in the absence of Transfer-Encoding,
    17021702   an origin server &SHOULD; send a Content-Length header field when the
    1703    payload body size is known prior to sending the complete header block.
     1703   payload body size is known prior to sending the complete header section.
    17041704   This will allow downstream recipients to measure transfer progress,
    17051705   know when a received message is complete, and potentially reuse the
     
    18741874</t>
    18751875<t>
    1876    If a response terminates in the middle of the header block (before the
     1876   If a response terminates in the middle of the header section (before the
    18771877   empty line is received) and the status code might rely on header fields to
    18781878   convey the full meaning of the response, then the client cannot assume
     
    18881888   transfer coding nor Content-Length is terminated by closure of the
    18891889   connection, and thus is considered complete regardless of the number of
    1890    message body octets received, provided that the header block was received
     1890   message body octets received, provided that the header section was received
    18911891   intact.
    18921892</t>
     
    20322032   check, digital signature, or post-processing status. The trailer fields are
    20332033   identical to header fields, except they are sent in a chunked trailer
    2034    instead of the message header block.
     2034   instead of the message's header section.
    20352035</t>
    20362036<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/>
     
    38223822   recommendations for minimum size limits on request-line
    38233823   (<xref target="request.line"/>)
    3824    and blocks of header fields (<xref target="header.fields"/>). These are
     3824   and header fields (<xref target="header.fields"/>). These are
    38253825   minimum recommendations, chosen to be supportable even by implementations
    38263826   with limited resources; it is expected that most implementations will
Note: See TracChangeset for help on using the changeset viewer.