W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: New byteranges

From: Brian Behlendorf <brian@organic.com>
Date: Fri, 17 Nov 1995 03:17:23 -0800 (PST)
To: Larry Masinter <masinter@parc.xerox.com>
Cc: luotonen@netscape.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.SGI.3.91.951117030702.19474y-100000@fully.organic.com>
On Thu, 16 Nov 1995, Larry Masinter wrote:
> I've never been able to figure out how the client knows what byte
> range to ask for in a PDF document. This is just a mystery part of the
> proposal. (Is it some trade secret? My PDF book doesn't say anything
> about byte ranges that I can find.)

I suggest that mention of specific media types be stricken from the ID to 
avoid confusion.  Larry - I think we can address the general issue of 
subaddressing at a different time, perhaps in the URI group instead since 
it's more an issue for naming and resolution than it is for HTTP.  How 
does an HTTP server know what "chapters 5-7" of a PDF file is?  Or 
"frames 300-350" of an MPEG movie?  This is a bigger issue.

Right now the biggest win the byte range proposal can give is for 
resumption of interrupted transmissions.  Let's define it with that 
context, and the fact that it will be used as a way to obtain a 
particular part of a larger object concerns me about as much as the fact 
that people use tables for layout rather than just tabular data.  

When we nail the subaddressing problem, I'm sure the PDF folk will be 
very happy.  

> Should the response to a 'range:' request still include a
> content-type: header? It better be the same as the content-type of the
> previous range request, no? In fact, maybe instead of a new 'range:'
> response header, you should just say
> 
>  content-type: application/range-response; range="chapters 6-9/12"
> 
> or something, since the content of the actual body of the message
> isn't the type of the whole.

Or, we could define that the Content-type in a 406 response maps to the 
Content-type of the whole document the response was extracted from.

> >   the fragments in sync. Conditional GET (the GET request with the If-
> >   modified-since header) works as expected with byte ranges.
> 
> I think we've established that 'as expected' varies wildly from one
> person to another. Could you please explain in this document exactly
> how YOU expect conditional GET to work with byte ranges?

I would presume he means that the defined semantics for a conditional GET 
do not change whether a Range: is specified or not.  I would consider it 
highly unlikely that a conditional GET would include a range, but that 
behavior (which is the default behavior for servers unaware of the Range: 
header anyways) seems perfectly valid.

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/
Received on Friday, 17 November 1995 04:17:35 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:36 EDT