Changeset 1550 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 28/02/12 08:46:03 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1549 r1550 1586 1586 <x:anchor-alias value="Transfer-Encoding"/> 1587 1587 <t> 1588 When one or more transfer encodings are applied to a payload body in order1588 When one or more transfer codings are applied to a payload body in order 1589 1589 to form the message body, a Transfer-Encoding header field &MUST; be sent 1590 1590 in the message and &MUST; contain the list of corresponding 1591 1591 transfer-coding names in the same order that they were applied. 1592 Transfer encodings are defined in <xref target="transfer.codings"/>.1592 Transfer codings are defined in <xref target="transfer.codings"/>. 1593 1593 </t> 1594 1594 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/> … … 1619 1619 the message &MUST; be terminated by closing the connection. 1620 1620 </t> 1621 < t>1621 <figure><preamble> 1622 1622 For example, 1623 </t> 1624 <figure><artwork type="example"> 1625 Transfer-Encoding: chunked 1626 </artwork></figure> 1623 </preamble><artwork type="example"> 1624 Transfer-Encoding: gzip, chunked 1625 </artwork><postamble> 1626 indicates that the payload body has been compressed using the gzip 1627 coding and then chunked using the chunked coding while forming the 1628 message body. 1629 </postamble></figure> 1627 1630 <t> 1628 1631 If more than one Transfer-Encoding header field is present in a message, … … 1637 1640 Additional information about the encoding parameters &MAY; be provided 1638 1641 by other header fields not defined by this specification. 1642 </t> 1643 <t> 1644 Transfer-Encoding &MAY; be sent in a response to a HEAD request or in a 1645 304 response to a GET request, neither of which includes a message body, 1646 to indicate that the origin server would have applied a transfer coding 1647 to the message body if the request had been an unconditional GET. 1648 This indication is not required, however, because any recipient on 1649 the response chain (including the origin server) can remove transfer 1650 codings when they are not needed. 1639 1651 </t> 1640 1652 <t> … … 1661 1673 <x:anchor-alias value="Content-Length"/> 1662 1674 <t> 1663 The "Content-Length" header field indicates the size of the 1664 message body, in decimal number of octets, for any message other than 1665 a response to a HEAD request or a response with a status code of 304. 1675 When a message does not have a Transfer-Encoding header field and the 1676 payload body length can be determined prior to being transferred, a 1677 Content-Length header field &SHOULD; be sent to indicate the length of the 1678 payload body that is either present as the message body, for requests 1679 and non-HEAD responses other than 304, or would have been present had 1680 the request been an unconditional GET. The length is expressed as a 1681 decimal number of octets. 1682 </t> 1683 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/> 1684 <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref> 1685 </artwork></figure> 1686 <t> 1687 An example is 1688 </t> 1689 <figure><artwork type="example"> 1690 Content-Length: 3495 1691 </artwork></figure> 1692 <t> 1666 1693 In the case of a response to a HEAD request, Content-Length indicates 1667 1694 the size of the payload body (not including any potential transfer-coding) … … 1672 1699 response. 1673 1700 </t> 1674 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/> 1675 <x:ref>Content-Length</x:ref> = 1*<x:ref>DIGIT</x:ref> 1676 </artwork></figure> 1677 <t> 1678 An example is 1679 </t> 1680 <figure><artwork type="example"> 1681 Content-Length: 3495 1682 </artwork></figure> 1683 <t> 1684 Implementations &SHOULD; use this field to indicate the message body 1685 length when no transfer-coding is being applied and the 1686 payload's body length can be determined prior to being transferred. 1687 <xref target="message.body"/> describes how recipients determine the length 1688 of a message body. 1689 </t> 1690 <t> 1691 Any Content-Length greater than or equal to zero is a valid value. 1692 </t> 1693 <t> 1694 Note that the use of this field in HTTP is significantly different from 1695 the corresponding definition in MIME, where it is an optional field 1696 used within the "message/external-body" content-type. 1701 <t> 1702 Any Content-Length field value greater than or equal to zero is valid. 1703 Since there is no predefined limit to the length of an HTTP payload, 1704 recipients &SHOULD; anticipate potentially large decimal numerals and 1705 prevent parsing errors due to integer conversion overflows 1706 (<xref target="attack.protocol.element.size.overflows"/>). 1697 1707 </t> 1698 1708 <t> … … 1707 1717 field containing that decimal value prior to determining the message body 1708 1718 length. 1719 </t> 1720 <t> 1721 HTTP's use of Content-Length is significantly different from how it is 1722 used in MIME, where it is an optional field used only within the 1723 "message/external-body" media-type. 1709 1724 </t> 1710 1725 </section> … … 2694 2709 <t>End-to-end header fields, which are transmitted to the ultimate 2695 2710 recipient of a request or response. End-to-end header fields in 2696 responses MUSTbe stored as part of a cache entry and &MUST; be2711 responses &MUST; be stored as part of a cache entry and &MUST; be 2697 2712 transmitted in any response formed from a cache entry.</t> 2698 2713
Note: See TracChangeset
for help on using the changeset viewer.