aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt
diff options
context:
space:
mode:
Diffstat (limited to 'vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt')
-rw-r--r--vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt1512
1 files changed, 1512 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt
new file mode 100644
index 000000000..1ef7b0946
--- /dev/null
+++ b/vendor/sabre/dav/docs/draft-ietf-httpbis-p5-range-11.txt
@@ -0,0 +1,1512 @@
+
+
+
+HTTPbis Working Group R. Fielding, Ed.
+Internet-Draft Day Software
+Obsoletes: 2616 (if approved) J. Gettys
+Intended status: Standards Track Alcatel-Lucent
+Expires: February 5, 2011 J. Mogul
+ HP
+ H. Frystyk
+ Microsoft
+ L. Masinter
+ Adobe Systems
+ P. Leach
+ Microsoft
+ T. Berners-Lee
+ W3C/MIT
+ Y. Lafon, Ed.
+ W3C
+ J. Reschke, Ed.
+ greenbytes
+ August 4, 2010
+
+
+ HTTP/1.1, part 5: Range Requests and Partial Responses
+ draft-ietf-httpbis-p5-range-11
+
+Abstract
+
+ 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.
+
+Editorial Note (To be removed by RFC Editor)
+
+ 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://tools.ietf.org/wg/httpbis/trac/report/3> and related
+ documents (including fancy diffs) can be found at
+ <http://tools.ietf.org/wg/httpbis/>.
+
+ The changes in this draft are summarized in Appendix D.12.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 1]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ 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."
+
+ This Internet-Draft will expire on February 5, 2011.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 2]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
+ 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
+ 1.2.2. ABNF Rules defined in other Parts of the
+ Specification . . . . . . . . . . . . . . . . . . . . 6
+ 2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6
+ 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
+ 3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
+ 3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8
+ 4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12
+ 5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15
+ 6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
+ 6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
+ Appendix A. Internet Media Type multipart/byteranges . . . . . . 17
+ Appendix B. Compatibility with Previous Versions . . . . . . . . 20
+ B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
+ Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 20
+ Appendix D. Change Log (to be removed by RFC Editor before
+ publication) . . . . . . . . . . . . . . . . . . . . 21
+ D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
+ D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 21
+ D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22
+ D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22
+ D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 22
+ D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 22
+ D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 22
+ D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23
+ D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 23
+ D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 23
+ D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 23
+ D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 23
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 3]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 4]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+1. Introduction
+
+ 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.
+
+1.1. Requirements
+
+ 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".
+
+1.2. Syntax Notation
+
+ This specification uses the ABNF syntax defined in Section 1.2 of
+ [Part1] (which extends the syntax defined in [RFC5234] with a list
+ rule). Appendix C shows the collected ABNF, with the list rule
+ expanded.
+
+ The following core rules are included by reference, as defined in
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 5]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
+ (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
+ HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
+ sequence of data), SP (space), VCHAR (any visible USASCII character),
+ and WSP (whitespace).
+
+1.2.1. Core Rules
+
+ The core rules below are defined in Section 1.2.2 of [Part1]:
+
+ token = <token, defined in [Part1], Section 1.2.2>
+ OWS = <OWS, defined in [Part1], Section 1.2.2>
+
+1.2.2. ABNF Rules defined in other Parts of the Specification
+
+ The ABNF rules below are defined in other parts:
+
+ HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
+
+
+ entity-tag = <entity-tag, defined in [Part4], Section 2>
+
+2. Range Units
+
+ HTTP/1.1 allows a client to request that only part (a range of) the
+ representation be included within the response. HTTP/1.1 uses range
+ units in the Range (Section 5.4) and Content-Range (Section 5.2)
+ header fields. A representation can be broken down into subranges
+ according to various structural units.
+
+ range-unit = bytes-unit / other-range-unit
+ bytes-unit = "bytes"
+ other-range-unit = token
+
+ HTTP/1.1 has been designed to allow implementations of applications
+ that do not depend on knowledge of ranges. The only range unit
+ defined by HTTP/1.1 is "bytes". Additional specifiers can be defined
+ as described in Section 2.1.
+
+ If a range unit is not understood in a request, a server MUST ignore
+ the whole Range header (Section 5.4). If a range unit is not
+ understood in a response, an intermediary SHOULD pass the response to
+ the client; a client MUST fail.
+
+2.1. Range Specifier Registry
+
+ The HTTP Ranger Specifier Registry defines the name space for the
+ range specifier names.
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 6]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ Registrations MUST include the following fields:
+
+ o Name
+
+ o Description
+
+ o Pointer to specification text
+
+ Values to be added to this name space are subject to IETF review
+ ([RFC5226], Section 4.1).
+
+ The registry itself is maintained at
+ <http://www.iana.org/assignments/http-range-specifiers>.
+
+3. Status Code Definitions
+
+3.1. 206 Partial Content
+
+ The server has fulfilled the partial GET request for the resource.
+ The request MUST have included a Range header field (Section 5.4)
+ indicating the desired range, and MAY have included an If-Range
+ header field (Section 5.3) to make the request conditional.
+
+ The response MUST include the following header fields:
+
+ o Either a Content-Range header field (Section 5.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.
+
+ o Date
+
+ o Cache-Control, ETag, Expires, Content-Location, Last-Modified,
+ and/or Vary, if the header field would have been sent in a 200
+ response to the same request
+
+ If the 206 response is the result of an If-Range request, the
+ response SHOULD NOT include other representation header fields.
+ Otherwise, the response MUST include all of the representation header
+ fields 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 4.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 7]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ A cache that does not support the Range and Content-Range headers
+ MUST NOT cache 206 (Partial Content) responses. Furthermore, if a
+ response uses a range unit that is not understood by the cache, then
+ it MUST NOT be cached either.
+
+3.2. 416 Requested Range Not Satisfiable
+
+ A server SHOULD return a response with this status code if a request
+ included a Range request-header field (Section 5.4), and none of the
+ ranges-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 (Section 5.3). (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 header field specifying the
+ current length of the representation (see Section 5.2). This
+ response MUST NOT use the multipart/byteranges content-type.
+
+4. Combining Ranges
+
+ A response might transfer only a subrange of a representation, either
+ because the request included one or more Range specifications, or
+ because a connection closed prematurely. After several such
+ transfers, a cache might have received several ranges of the same
+ representation.
+
+ If a cache has a stored non-empty set of subranges for a
+ representation, 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:
+
+ o Both the incoming response and the cache entry have a cache
+ validator.
+
+ o The two cache validators match using the strong comparison
+ function (see Section 4 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.
+
+5. Header Field Definitions
+
+ This section defines the syntax and semantics of HTTP/1.1 header
+ fields related to range requests and partial responses.
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 8]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+5.1. Accept-Ranges
+
+ The "Accept-Ranges" response-header field allows a resource to
+ indicate its acceptance of range requests.
+
+ Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
+ Accept-Ranges-v = acceptable-ranges
+ acceptable-ranges = 1#range-unit / "none"
+
+ Origin servers that accept byte-range requests MAY send
+
+ Accept-Ranges: bytes
+
+ but are not required to do so. Clients MAY generate range requests
+ without having received this header for the resource involved. Range
+ units are defined in Section 2.
+
+ Servers that do not accept any kind of range request for a resource
+ MAY send
+
+ Accept-Ranges: none
+
+ to advise the client not to attempt a range request.
+
+5.2. Content-Range
+
+ The "Content-Range" header field is sent with a partial
+ representation to specify where in the full representation the
+ payload body is intended to be applied.
+
+ Range units are defined in Section 2.
+
+ Content-Range = "Content-Range" ":" OWS Content-Range-v
+ Content-Range-v = content-range-spec
+
+ content-range-spec = byte-content-range-spec
+ / other-content-range-spec
+ byte-content-range-spec = bytes-unit SP
+ byte-range-resp-spec "/"
+ ( instance-length / "*" )
+
+ byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
+ / "*"
+
+ instance-length = 1*DIGIT
+
+ other-content-range-spec = other-range-unit SP
+ other-range-resp-spec
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 9]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ other-range-resp-spec = *CHAR
+
+ The header SHOULD indicate the total length of the full
+ representation, unless this length is unknown or difficult to
+ determine. The asterisk "*" character means that the instance-length
+ is unknown at the time when the response was generated.
+
+ Unlike byte-ranges-specifier values (see Section 5.4.1), a byte-
+ range-resp-spec MUST only specify one range, and MUST contain
+ absolute byte positions for both the first and last byte of the
+ range.
+
+ A byte-content-range-spec with a byte-range-resp-spec whose last-
+ byte-pos value is less than its first-byte-pos value, or whose
+ instance-length value is less than or equal to its last-byte-pos
+ value, is invalid. The recipient of an invalid byte-content-range-
+ spec MUST ignore it and any content transferred along with it.
+
+ In the case of a byte range request: A server sending a response with
+ status code 416 (Requested range not satisfiable) SHOULD include a
+ Content-Range field with a byte-range-resp-spec of "*". The
+ instance-length specifies the current length of the selected
+ resource. A response with status code 206 (Partial Content) MUST NOT
+ include a Content-Range field with a byte-range-resp-spec of "*".
+
+ Examples of byte-content-range-spec values, assuming that the
+ representation contains a total of 1234 bytes:
+
+ o The first 500 bytes:
+
+ bytes 0-499/1234
+
+ o The second 500 bytes:
+
+ bytes 500-999/1234
+
+ o All except for the first 500 bytes:
+
+ bytes 500-1233/1234
+
+ o The last 500 bytes:
+
+ bytes 734-1233/1234
+
+ When an HTTP message includes the content of a single range (for
+ example, a response to a request for a single range, or to a request
+ for a set of ranges that overlap without any holes), this content is
+ transmitted with a Content-Range header, and a Content-Length header
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 10]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ showing the number of bytes actually transferred. 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-Range: bytes 21010-47021/47022
+ Content-Length: 26012
+ Content-Type: image/gif
+
+ When an HTTP message includes the content of multiple ranges (for
+ example, a response to a request for multiple non-overlapping
+ ranges), these are transmitted as a multipart message. The multipart
+ media type used for this purpose is "multipart/byteranges" as defined
+ in Appendix A.
+
+ A response to a request for a single range MUST NOT be sent using the
+ multipart/byteranges media type. A response to a request for
+ multiple ranges, whose result is a single range, MAY be sent as a
+ multipart/byteranges media type with one part. A client that cannot
+ decode a multipart/byteranges message MUST NOT ask for multiple
+ ranges in a single request.
+
+ When a client requests multiple ranges in one request, the server
+ SHOULD return them in the order that they appeared in the request.
+
+ If the server ignores a byte-range-spec because it is syntactically
+ invalid, the server SHOULD treat the request as if the invalid Range
+ header field did not exist. (Normally, this means return a 200
+ response containing the full representation).
+
+ If the server receives a request (other than one including an If-
+ Range request-header field) with an unsatisfiable Range request-
+ header field (that is, all of whose byte-range-spec values have a
+ first-byte-pos value greater than the current length of the selected
+ resource), it SHOULD return a response code of 416 (Requested range
+ not satisfiable) (Section 3.2).
+
+ Note: Clients cannot depend on servers to send a 416 (Requested
+ range not satisfiable) response instead of a 200 (OK) response for
+ an unsatisfiable Range request-header, since not all servers
+ implement this request-header.
+
+5.3. If-Range
+
+ If a client has a partial copy of a representation in its cache, and
+ wishes to have an up-to-date copy of the entire representation in its
+ cache, it could use the Range request-header with a conditional GET
+ (using either or both of If-Unmodified-Since and If-Match.) However,
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 11]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ if the condition fails because the representation has been modified,
+ the client would then have to make a second request to obtain the
+ entire current representation.
+
+ The "If-Range" request-header field allows a client to "short-
+ circuit" the second request. Informally, its meaning is "if the
+ representation is unchanged, send me the part(s) that I am missing;
+ otherwise, send me the entire new representation".
+
+ If-Range = "If-Range" ":" OWS If-Range-v
+ If-Range-v = entity-tag / HTTP-date
+
+ If the client has no entity-tag for a representation, but does have a
+ Last-Modified date, it MAY use that date in an If-Range header. (The
+ server can distinguish between a valid HTTP-date and any form of
+ entity-tag by examining no more than two characters.) The If-Range
+ header SHOULD only be used together with a Range header, and MUST be
+ ignored if the request does not include a Range header, or if the
+ server does not support the sub-range operation.
+
+ If the entity-tag given in the If-Range header matches the current
+ cache validator for the representation, then the server SHOULD
+ provide the specified sub-range of the representation using a 206
+ (Partial Content) response. If the cache validator does not match,
+ then the server SHOULD return the entire representation using a 200
+ (OK) response.
+
+5.4. Range
+
+5.4.1. Byte Ranges
+
+ Since all HTTP representations are transferred as sequences of bytes,
+ the concept of a byte range is meaningful for any HTTP
+ representation. (However, not all clients and servers need to
+ support byte-range operations.)
+
+ Byte range specifications in HTTP apply to the sequence of bytes in
+ the representation body (not necessarily the same as the message-
+ body).
+
+ A byte range operation MAY specify a single range of bytes, or a set
+ of ranges within a single representation.
+
+ byte-ranges-specifier = bytes-unit "=" byte-range-set
+ byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
+ byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
+ first-byte-pos = 1*DIGIT
+ last-byte-pos = 1*DIGIT
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 12]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ The first-byte-pos value in a byte-range-spec gives the byte-offset
+ of the first byte in a range. The last-byte-pos value gives the
+ byte-offset of the last byte in the range; that is, the byte
+ positions specified are inclusive. Byte offsets start at zero.
+
+ If the last-byte-pos value is present, it MUST be greater than or
+ equal to the first-byte-pos in that byte-range-spec, or the byte-
+ range-spec is syntactically invalid. The recipient of a byte-range-
+ set that includes one or more syntactically invalid byte-range-spec
+ values MUST ignore the header field that includes that byte-range-
+ set.
+
+ If the last-byte-pos value is absent, or if the value is greater than
+ or equal to the current length of the representation body, last-byte-
+ pos is taken to be equal to one less than the current length of the
+ representation in bytes.
+
+ By its choice of last-byte-pos, a client can limit the number of
+ bytes retrieved without knowing the size of the representation.
+
+ suffix-byte-range-spec = "-" suffix-length
+ suffix-length = 1*DIGIT
+
+ A suffix-byte-range-spec is used to specify the suffix of the
+ representation body, of a length given by the suffix-length value.
+ (That is, this form specifies the last N bytes of a representation.)
+ If the representation is shorter than the specified suffix-length,
+ the entire representation is used.
+
+ If a syntactically valid byte-range-set includes at least one byte-
+ range-spec whose first-byte-pos is less than the current length of
+ the representation, or at least one suffix-byte-range-spec with a
+ non-zero suffix-length, then the byte-range-set is satisfiable.
+ Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
+ set is unsatisfiable, the server SHOULD return a response with a 416
+ (Requested range not satisfiable) status code. Otherwise, the server
+ SHOULD return a response with a 206 (Partial Content) status code
+ containing the satisfiable ranges of the representation.
+
+ Examples of byte-ranges-specifier values (assuming a representation
+ of length 10000):
+
+ o The first 500 bytes (byte offsets 0-499, inclusive):
+
+ bytes=0-499
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 13]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ o The second 500 bytes (byte offsets 500-999, inclusive):
+
+ bytes=500-999
+
+ o The final 500 bytes (byte offsets 9500-9999, inclusive):
+
+ bytes=-500
+
+ Or:
+
+ bytes=9500-
+
+ o The first and last bytes only (bytes 0 and 9999):
+
+ bytes=0-0,-1
+
+ o Several legal but not canonical specifications of the second 500
+ bytes (byte offsets 500-999, inclusive):
+
+ bytes=500-600,601-999
+ bytes=500-700,601-999
+
+5.4.2. Range Retrieval Requests
+
+ The "Range" request-header field defines the GET method (conditional
+ or not) to request one or more sub-ranges of the response
+ representation body, instead of the entire representation body.
+
+ Range = "Range" ":" OWS Range-v
+ Range-v = byte-ranges-specifier
+ / other-ranges-specifier
+ other-ranges-specifier = other-range-unit "=" other-range-set
+ other-range-set = 1*CHAR
+
+ A server MAY ignore the Range header. However, HTTP/1.1 origin
+ servers and intermediate caches ought to support byte ranges when
+ possible, since Range supports efficient recovery from partially
+ failed transfers, and supports efficient partial retrieval of large
+ representations.
+
+ If the server supports the Range header and the specified range or
+ ranges are appropriate for the representation:
+
+ o The presence of a Range header in an unconditional GET modifies
+ what is returned if the GET is otherwise successful. In other
+ words, the response carries a status code of 206 (Partial Content)
+ instead of 200 (OK).
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 14]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ o The presence of a Range header in a conditional GET (a request
+ using one or both of If-Modified-Since and If-None-Match, or one
+ or both of If-Unmodified-Since and If-Match) modifies what is
+ returned if the GET is otherwise successful and the condition is
+ true. It does not affect the 304 (Not Modified) response returned
+ if the conditional is false.
+
+ In some cases, it might be more appropriate to use the If-Range
+ header (see Section 5.3) in addition to the Range header.
+
+ If a proxy that supports ranges receives a Range request, forwards
+ the request to an inbound server, and receives an entire
+ representation in reply, it SHOULD only return the requested range to
+ its client. It SHOULD store the entire received response in its
+ cache if that is consistent with its cache allocation policies.
+
+6. IANA Considerations
+
+6.1. Status Code Registration
+
+ The HTTP Status Code Registry located at
+ <http://www.iana.org/assignments/http-status-codes> shall be updated
+ with the registrations below:
+
+ +-------+---------------------------------+-------------+
+ | Value | Description | Reference |
+ +-------+---------------------------------+-------------+
+ | 206 | Partial Content | Section 3.1 |
+ | 416 | Requested Range Not Satisfiable | Section 3.2 |
+ +-------+---------------------------------+-------------+
+
+6.2. Header Field Registration
+
+ The Message Header Field Registry located at <http://www.iana.org/
+ assignments/message-headers/message-header-index.html> shall be
+ updated with the permanent registrations below (see [RFC3864]):
+
+ +-------------------+----------+----------+-------------+
+ | Header Field Name | Protocol | Status | Reference |
+ +-------------------+----------+----------+-------------+
+ | Accept-Ranges | http | standard | Section 5.1 |
+ | Content-Range | http | standard | Section 5.2 |
+ | If-Range | http | standard | Section 5.3 |
+ | Range | http | standard | Section 5.4 |
+ +-------------------+----------+----------+-------------+
+
+ The change controller is: "IETF (iesg@ietf.org) - Internet
+ Engineering Task Force".
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 15]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+6.3. Range Specifier Registration
+
+ The registration procedure for HTTP Range Specifiers is defined by
+ Section 2.1 of this document.
+
+ The HTTP Range Specifier Registry shall be created at
+ <http://www.iana.org/assignments/http-range-specifiers> and be
+ populated with the registrations below:
+
+ +----------------------+-------------------+----------------------+
+ | Range Specifier Name | Description | Reference |
+ +----------------------+-------------------+----------------------+
+ | bytes | a range of octets | (this specification) |
+ +----------------------+-------------------+----------------------+
+
+ The change controller is: "IETF (iesg@ietf.org) - Internet
+ Engineering Task Force".
+
+7. Security Considerations
+
+ No additional security considerations have been identified beyond
+ those applicable to HTTP in general [Part1].
+
+8. Acknowledgments
+
+ 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.
+
+9. References
+
+9.1. Normative References
+
+ [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", draft-ietf-httpbis-p1-messaging-11
+ (work in progress), August 2010.
+
+ [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", draft-ietf-httpbis-p4-conditional-11 (work in
+ progress), August 2010.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 16]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ [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.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+9.2. Informative References
+
+ [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.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+Appendix A. Internet Media Type multipart/byteranges
+
+ 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], Section 5.1). The media type for this purpose is
+ called "multipart/byteranges". The following is to be registered
+ with IANA [RFC4288].
+
+ Note: Despite the name "multipart/byteranges" is not limited to
+ the byte ranges only.
+
+ The multipart/byteranges media type includes one 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.
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 17]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 18]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ 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--
+
+ Other example:
+
+ HTTP/1.1 206 Partial Content
+ Date: Tue, 14 Nov 1995 06:25:24 GMT
+ Last-Modified: Tue, 14 July 04:58:08 GMT
+ Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
+ --THIS_STRING_SEPARATES
+ Content-type: video/example
+ Content-range: exampleunit 1.2-4.3/25
+
+ ...the first range...
+ --THIS_STRING_SEPARATES
+ Content-type: video/example
+ Content-range: exampleunit 11.2-14.3/25
+
+ ...the second range
+ --THIS_STRING_SEPARATES--
+
+ Notes:
+
+ 1. Additional CRLFs MAY precede the first boundary string in the
+ body.
+
+ 2. Although [RFC2046] permits the boundary string to be quoted, some
+ existing implementations handle a quoted boundary string
+ incorrectly.
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 19]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ 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.
+
+Appendix B. Compatibility with Previous Versions
+
+B.1. Changes from RFC 2616
+
+ Clarify that it is not ok to use a weak cache validator in a 206
+ response. (Section 3.1)
+
+ Clarify that multipart/byteranges can consist of a single part.
+ (Appendix A)
+
+Appendix C. Collected ABNF
+
+ Accept-Ranges = "Accept-Ranges:" OWS Accept-Ranges-v
+ Accept-Ranges-v = acceptable-ranges
+
+ Content-Range = "Content-Range:" OWS Content-Range-v
+ Content-Range-v = content-range-spec
+
+ HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
+
+ If-Range = "If-Range:" OWS If-Range-v
+ If-Range-v = entity-tag / HTTP-date
+
+ OWS = <OWS, defined in [Part1], Section 1.2.2>
+
+ Range = "Range:" OWS Range-v
+ Range-v = byte-ranges-specifier / other-ranges-specifier
+
+ acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
+ range-unit ] ) ) / "none"
+
+ byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" (
+ instance-length / "*" )
+ byte-range-resp-spec = ( first-byte-pos "-" last-byte-pos ) / "*"
+ byte-range-set = ( *( "," OWS ) byte-range-spec ) / (
+ suffix-byte-range-spec *( OWS "," [ ( OWS byte-range-spec ) /
+ suffix-byte-range-spec ] ) )
+ byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
+ byte-ranges-specifier = bytes-unit "=" byte-range-set
+ bytes-unit = "bytes"
+
+ content-range-spec = byte-content-range-spec /
+ other-content-range-spec
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 20]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ entity-tag = <entity-tag, defined in [Part4], Section 2>
+
+ first-byte-pos = 1*DIGIT
+
+ instance-length = 1*DIGIT
+
+ last-byte-pos = 1*DIGIT
+
+ other-content-range-spec = other-range-unit SP other-range-resp-spec
+ other-range-resp-spec = *CHAR
+ other-range-set = 1*CHAR
+ other-range-unit = token
+ other-ranges-specifier = other-range-unit "=" other-range-set
+
+ range-unit = bytes-unit / other-range-unit
+
+ suffix-byte-range-spec = "-" suffix-length
+ suffix-length = 1*DIGIT
+
+ token = <token, defined in [Part1], Section 1.2.2>
+
+ ABNF diagnostics:
+
+ ; Accept-Ranges defined but not used
+ ; Content-Range defined but not used
+ ; If-Range defined but not used
+ ; Range defined but not used
+
+Appendix D. Change Log (to be removed by RFC Editor before publication)
+
+D.1. Since RFC2616
+
+ Extracted relevant partitions from [RFC2616].
+
+D.2. Since draft-ietf-httpbis-p5-range-00
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
+ validators in 206 responses"
+ (<http://purl.org/NET/http-errata#ifrange206>)
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
+ Informative references"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
+ to-date references"
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 21]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+D.3. Since draft-ietf-httpbis-p5-range-01
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
+ RFC4288"
+
+ Ongoing work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Add explicit references to BNF syntax and rules imported from
+ other parts of the specification.
+
+D.4. Since draft-ietf-httpbis-p5-range-02
+
+ Ongoing work on IANA Message Header Registration
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
+
+ o Reference RFC 3984, and update header registrations for headers
+ defined in this document.
+
+D.5. Since draft-ietf-httpbis-p5-range-03
+
+D.6. Since draft-ietf-httpbis-p5-range-04
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
+ byteranges minimum number of parts"
+
+ Ongoing work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Use "/" instead of "|" for alternatives.
+
+ o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
+ whitespace ("OWS") and required whitespace ("RWS").
+
+ o Rewrite ABNFs to spell out whitespace rules, factor out header
+ value format definitions.
+
+D.7. Since draft-ietf-httpbis-p5-range-05
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/142>: "State base
+ for *-byte-pos and suffix-length"
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 22]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ Ongoing work on Custom Ranges
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
+
+ o Remove bias in favor of byte ranges; allow custom ranges in ABNF.
+
+ Final work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Add appendix containing collected and expanded ABNF, reorganize
+ ABNF introduction.
+
+D.8. Since draft-ietf-httpbis-p5-range-06
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
+ numeric protocol elements"
+
+D.9. Since draft-ietf-httpbis-p5-range-07
+
+ Closed issues:
+
+ o Fixed discrepancy in the If-Range definition about allowed
+ validators.
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/150>: "multipart/
+ byteranges for custom range units"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/151>: "range unit
+ missing from other-ranges-specifier in Range header"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
+ registrations for optional status codes"
+
+D.10. Since draft-ietf-httpbis-p5-range-08
+
+ No significant changes.
+
+D.11. Since draft-ietf-httpbis-p5-range-09
+
+ No significant changes.
+
+D.12. Since draft-ietf-httpbis-p5-range-10
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
+ 'Requested Variant'"
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 23]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
+ entity / representation / variant terminology"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
+ removing the 'changes from 2068' sections"
+
+ Ongoing work on Custom Ranges
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/85>):
+
+ o Add IANA registry.
+
+Index
+
+ 2
+ 206 Partial Content (status code) 7
+
+ 4
+ 416 Requested Range Not Satisfiable (status code) 8
+
+ A
+ Accept-Ranges header 9
+
+ C
+ Content-Range header 9
+
+ G
+ Grammar
+ Accept-Ranges 9
+ Accept-Ranges-v 9
+ acceptable-ranges 9
+ byte-content-range-spec 9
+ byte-range-resp-spec 9
+ byte-range-set 12
+ byte-range-spec 12
+ byte-ranges-specifier 12
+ bytes-unit 6
+ Content-Range 9
+ content-range-spec 9
+ Content-Range-v 9
+ first-byte-pos 12
+ If-Range 12
+ If-Range-v 12
+ instance-length 9
+ last-byte-pos 12
+ other-range-unit 6
+ Range 14
+ range-unit 6
+ ranges-specifier 12
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 24]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ suffix-byte-range-spec 13
+ suffix-length 13
+
+ H
+ Headers
+ Accept-Ranges 9
+ Content-Range 9
+ If-Range 11
+ Range 12
+
+ I
+ If-Range header 11
+
+ M
+ Media Type
+ multipart/byteranges 17
+ multipart/x-byteranges 20
+ multipart/byteranges Media Type 17
+ multipart/x-byteranges Media Type 20
+
+ R
+ Range header 12
+
+ S
+ Status Codes
+ 206 Partial Content 7
+ 416 Requested Range Not Satisfiable 8
+
+Authors' Addresses
+
+ Roy T. Fielding (editor)
+ Day Software
+ 23 Corporate Plaza DR, Suite 280
+ Newport Beach, CA 92660
+ USA
+
+ Phone: +1-949-706-5300
+ Fax: +1-949-706-5305
+ EMail: fielding@gbiv.com
+ URI: http://roy.gbiv.com/
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 25]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ Jim Gettys
+ Alcatel-Lucent Bell Labs
+ 21 Oak Knoll Road
+ Carlisle, MA 01741
+ USA
+
+ EMail: jg@freedesktop.org
+ URI: http://gettys.wordpress.com/
+
+
+ Jeffrey C. Mogul
+ Hewlett-Packard Company
+ HP Labs, Large Scale Systems Group
+ 1501 Page Mill Road, MS 1177
+ Palo Alto, CA 94304
+ USA
+
+ EMail: JeffMogul@acm.org
+
+
+ Henrik Frystyk Nielsen
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ EMail: henrikn@microsoft.com
+
+
+ Larry Masinter
+ Adobe Systems, Incorporated
+ 345 Park Ave
+ San Jose, CA 95110
+ USA
+
+ EMail: LMM@acm.org
+ URI: http://larry.masinter.net/
+
+
+ Paul J. Leach
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+
+ EMail: paulle@microsoft.com
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 26]
+
+Internet-Draft HTTP/1.1, Part 5 August 2010
+
+
+ Tim Berners-Lee
+ World Wide Web Consortium
+ MIT Computer Science and Artificial Intelligence Laboratory
+ The Stata Center, Building 32
+ 32 Vassar Street
+ Cambridge, MA 02139
+ USA
+
+ EMail: timbl@w3.org
+ URI: http://www.w3.org/People/Berners-Lee/
+
+
+ Yves Lafon (editor)
+ World Wide Web Consortium
+ W3C / ERCIM
+ 2004, rte des Lucioles
+ Sophia-Antipolis, AM 06902
+ France
+
+ EMail: ylafon@w3.org
+ URI: http://www.raubacapeu.net/people/yves/
+
+
+ Julian F. Reschke (editor)
+ greenbytes GmbH
+ Hafenweg 16
+ Muenster, NW 48155
+ Germany
+
+ Phone: +49 251 2807760
+ Fax: +49 251 2807761
+ EMail: julian.reschke@greenbytes.de
+ URI: http://greenbytes.de/tech/webdav/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 27]
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-29 00:37:49 +0000