- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Thu, 22 Feb 1996 02:00:17 -0800
- To: Ari Luotonen <luotonen@netscape.com>
- Cc: http-caching@pa.dec.com
Well, aside from the fact that If-Valid, If-Invalid, and
Unless-Modified-Since are three of
those preconditions that I won't allow in the protocol without
proof that they, when combined with the three other proposals, are more
efficient than a single extensible syntax ....
> 2. Accept-Ranges HTTP response header ....................... 3
Is completely unnecessary and should be removed. The Introduction is
also antiquated in its arguments about the PDF junk which do not
apply to this proposal.
> B) Insertion Range Retrieval
> C) Tentative Range Retrieval
This is just a non-intuitive hack in order to make three different
conditions do something which would be better handled by a single
syntax. Given that none of these conditionals exist now, there is no
excuse for the hack. Instead, just put something in Range that says
which response you would prefer on failure, or use a more generic
syntax for the precondition, like
Condition: 306 if {eq {last-modified "Wed, 21 Feb 1996 01:20:17 GMT"}}
> ...
> If the request includes multiple ranges, the response is sent back as
> a multipart MIME message, with content-type multipart/x-byteranges.
> A server may, but is not required to, send also a single byte range
> as a multipart message.
No "x-" type will be allowed in the HTTP/1.1 RFC. If you want to do this,
you must register the type first.
> 4.3. Multiple Ranges as Multipart MIME Messages
>
> Multipart MIME is defined in [RFC-1521]. With byteranges, the
> multipart MIME message uses content-type multipart/x-byteranges, with
> a boundary parameter.
>
> Example:
>
> Content-type: multipart/x-byteranges; boundary=THIS_STRING_SEPARATES
>
> --THIS_STRING_SEPARATES
> Content-type: application/x-pdf
> Content-range: bytes 500-999/8000
That is wrong -- the type would have to be application/octet-stream,
since the contents are not a valid PDF (or whatever) document until
they are joined together.
Section 5.1 is invalid -- you don't separate multiple field values with
semicolons -- that is what commas are for. Given the syntax chosen,
multiple Range headers would be forbidden (which is probably just as well).
Finally, although I appreciate the acknowledgement, please do not include
my e-mail address.
......Roy
Received on Thursday, 22 February 1996 10:18:43 UTC