- 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
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 UTC