Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-04.html below:

HTTP/1.1, part 5: Range Requests and Partial Responses

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.¶

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.¶

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.¶

This Internet-Draft will expire on March 2, 2009.¶

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 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.¶

Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues list is at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related documents (including fancy diffs) can be found at <http://www.tools.ietf.org/wg/httpbis/>.¶

The changes in this draft are summarized in Appendix C.4.¶

• 1.   Introduction
  • 1.1.   Requirements
• 2.   Notational Conventions and Generic Grammar
• 3.   Range Units
• 4.   Status Code Definitions
  • 4.1.   206 Partial Content
  • 4.2.   416 Requested Range Not Satisfiable
• 5.   Combining Byte Ranges
• 6.   Header Field Definitions
  • 6.1.   Accept-Ranges
  • 6.2.   Content-Range
  • 6.3.   If-Range
  • 6.4.   Range
    • 6.4.1.   Byte Ranges
    • 6.4.2.   Range Retrieval Requests
• 7.   IANA Considerations
  • 7.1.   Message Header Registration
• 8.   Security Considerations
• 9.   Acknowledgments
• 10.   References
  • 10.1.   Normative References
  • 10.2.   Informative References
• Appendix A.   Internet Media Type multipart/byteranges
• Appendix B.   Compatibility with Previous Versions
  • B.1.   Changes from RFC 2068
  • B.2.   Changes from RFC 2616
• Appendix C.   Change Log (to be removed by RFC Editor before publication)
  • C.1.   Since RFC2616
  • C.2.   Since draft-ietf-httpbis-p5-range-00
  • C.3.   Since draft-ietf-httpbis-p5-range-01
  • C.4.   Since draft-ietf-httpbis-p5-range-02
  • C.5.   Since draft-ietf-httpbis-p5-range-03
• Index
• Authors' Addresses
• Intellectual Property and Copyright Statements

HTTP clients often encounter interrupted data transfers as a result of cancelled requests or dropped connections. When a cache has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request rather than transfer the entire representation. There are also a number of Web applications that benefit from being able to request only a subset of a larger representation, such as a single page of a very large document or only part of an image to be rendered by a device with limited local storage.¶

This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. The protocol for range requests is an OPTIONAL feature of HTTP, designed so resources or recipients that do not implement this feature can respond as if it is a normal GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for full responses by intermediate caches that might not implement the feature.¶

Although the HTTP range request mechanism is designed to allow for extensible range types, this specification only defines requests for byte ranges.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."¶

This specification uses the ABNF syntax defined in Section 2.1 of [Part1] and the core rules defined in Section 2.2 of [Part1]: ¶

The ABNF rules below are defined in other parts:¶

HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (Section 6.4) and Content-Range (Section 6.2) header fields. An entity can be broken down into subranges according to various structural units.¶

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units.¶

HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.¶

The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (Section 6.4) indicating the desired range, and MAY have included an If-Range header field (Section 6.3) to make the request conditional.¶

The response MUST include the following header fields: ¶

• Either a Content-Range header field (Section 6.2) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.
• Date
• ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
• Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant

If the 206 response is the result of an If-Range request, the response SHOULD NOT include other entity-headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.¶

A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see Section 5.¶

A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses.¶

A server SHOULD return a response with this status code if a request included a Range request-header field (Section 6.4), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)¶

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see Section 6.2). This response MUST NOT use the multipart/byteranges content-type.¶

A response might transfer only a subrange of the bytes of an entity-body, either because the request included one or more Range specifications, or because a connection was broken prematurely. After several such transfers, a cache might have received several ranges of the same entity-body.¶

If a cache has a stored non-empty set of subranges for an entity, and an incoming response transfers another subrange, the cache MAY combine the new subrange with the existing set if both the following conditions are met: ¶

• Both the incoming response and the cache entry have a cache validator.
• The two cache validators match using the strong comparison function (see Section 5 of [Part4]).

If either requirement is not met, the cache MUST use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming response if these values are equal or missing), and MUST discard the other partial information.¶

No additional security considerations have been identified beyond those applicable to HTTP in general [Part1].¶

Most of the specification of ranges is based on work originally done by Ari Luotonen and John Franks, with additional input from Steve Zilles, Daniel W. Connolly, Roy T. Fielding, Jim Gettys, Martin Hamilton, Koen Holtman, Shel Kaplan, Paul Leach, Alex Lopez-Ortiz, Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi Rizzo, and Bill Weihl.¶

[Part1]

Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 1: URIs, Connections, and Message Parsing”, Internet-Draft draft-ietf-httpbis-p1-messaging-04 (work in progress), August 2008.

[Part3]

Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 3: Message Payload and Content Negotiation”, Internet-Draft draft-ietf-httpbis-p3-payload-04 (work in progress), August 2008.

[Part4]

Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 4: Conditional Requests”, Internet-Draft draft-ietf-httpbis-p4-conditional-04 (work in progress), August 2008.

[Part6]

Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 6: Caching”, Internet-Draft draft-ietf-httpbis-p6-cache-04 (work in progress), August 2008.

[RFC2046]

Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2616]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1”, RFC 2616, June 1999.

[RFC3864]

Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.

[RFC4288]

Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 4288, December 2005.

When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart message-body [RFC2046]. The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA [RFC4288].¶

The multipart/byteranges media type includes two or more parts, each with its own Content-Type and Content-Range fields. The required boundary parameter specifies the boundary string used to separate each body-part.¶

Type name:

multipart

Subtype name:

byteranges

Required parameters:

boundary

Optional parameters:

none

Encoding considerations:

only "7bit", "8bit", or "binary" are permitted

Security considerations:

none

Interoperability considerations:

none

Published specification:

This specification (see Appendix A).

Applications that use this media type:

 

Additional information:

 

Magic number(s):

none

File extension(s):

none

Macintosh file type code(s):

none

Person and email address to contact for further information:

See Authors Section.

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IESG

For example:

   HTTP/1.1 206 Partial Content
   Date: Wed, 15 Nov 1995 06:25:24 GMT
   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
   Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 500-999/8000

   ...the first range...
   --THIS_STRING_SEPARATES
   Content-type: application/pdf
   Content-range: bytes 7000-7999/8000

   ...the second range
   --THIS_STRING_SEPARATES--

Notes: ¶

1. Additional CRLFs may precede the first boundary string in the entity.
2. Although [RFC2046] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
3. A number of browsers and servers were coded to an early draft of the byteranges specification to use a media type of multipart/x-byteranges, which is almost, but not quite compatible with the version documented in HTTP/1.1.

Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are computed. (Section 6.2, see also [Part1], [Part3] and [Part6])¶

There are situations where a server (especially a proxy) does not know the full length of a response but is capable of serving a byterange request. We therefore need a mechanism to allow byteranges with a content-range not indicating the full length of the message. (Section 6.2)¶

Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send needed headers in a 206 response, this problem can be avoided. (Section 4.1 and 6.3)¶

Fix problem with unsatisfiable range requests; there are two cases: syntactic problems, and range doesn't exist in the document. The 416 status code was needed to resolve this ambiguity needed to indicate an error for a byte range request that falls outside of the actual contents of a document. (Section 4.2, 6.2)¶

Clarify that it is not ok to use a weak cache validator in a 206 response. (Section 4.1)¶

Extracted relevant partitions from [RFC2616].¶

2 4 A C G H I M P R S

• 2
  • 206 Partial Content (status code)  4.1, B.1, B.2
• 4
  • 416 Requested Range Not Satisfiable (status code)  4.2, 6.2, B.1
• A
  • Accept-Ranges header  6.1, 7.1
• C
  • Content-Range header  3, 4.1, 4.2, 6.2, 7.1, B.1, B.1, B.1
• G
  • Grammar  
    • Accept-Ranges  6.1
    • acceptable-ranges  6.1
    • byte-content-range-spec  6.2
    • byte-range-resp-spec  6.2
    • byte-range-set  6.4.1
    • byte-range-spec  6.4.1
    • byte-ranges-specifier  6.4.1
    • bytes-unit  3
    • Content-Range  6.2
    • content-range-spec  6.2
    • first-byte-pos  6.4.1
    • If-Range  6.3
    • instance-length  6.2
    • last-byte-pos  6.4.1
    • other-range-unit  3
    • Range  6.4.2
    • range-unit  3
    • ranges-specifier  6.4.1
    • suffix-byte-range-spec  6.4.1
    • suffix-length  6.4.1
• H
  • Headers  
    • Accept-Ranges  6.1, 7.1
    • Content-Range  3, 4.1, 4.2, 6.2, 7.1, B.1, B.1, B.1
    • If-Range  4.1, 6.3, 6.4.2, 7.1, B.1
    • Range  3, 4.1, 4.2, 6.4, 7.1
• I
  • If-Range header  4.1, 6.3, 6.4.2, 7.1, B.1
• M
  • Media Type  
    • multipart/byteranges  A
    • multipart/x-byteranges  A
  • multipart/byteranges Media Type  A
  • multipart/x-byteranges Media Type  A
• P
  • Part1  2, 2, 2, 2, 2, 2, 8, 10.1, B.1
    • Section 2.1  2
    • Section 2.2  2, 2, 2, 2
    • Section 3.3.1  2
  • Part3  10.1, B.1
  • Part4  2, 5, 10.1
    • Section 3  2
    • Section 5  5
  • Part6  10.1, B.1
• R
  • Range header  3, 4.1, 4.2, 6.4, 7.1
  • RFC2046  10.1, A, A
  • RFC2119  1.1, 10.1
  • RFC2616  10.2, C.1
  • RFC3864  7.1, 10.2
  • RFC4288  10.2, A
• S
  • Status Codes  
    • 206 Partial Content  4.1, B.1, B.2
    • 416 Requested Range Not Satisfiable  4.2, 6.2, B.1

Copyright © The IETF Trust (2008).¶

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.¶

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.¶

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.¶

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.¶

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.¶

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4