httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Life is hard, and then you die." <ron...@innovation.ch>
Subject Re: 'Range: bytes=' request with starting byte greater than size of f ile
Date Wed, 15 Sep 1999 06:16:11 GMT
One day, Dean Gaudet wrote:
> 
> On Fri, 10 Sep 1999, Life is hard, and then you die. wrote:
> 
> > One day, Dean Gaudet wrote:
> > > 
> > > On Fri, 10 Sep 1999, Life is hard, and then you die. wrote:
> > > 
> > > > Apache already supports byte ranges on GET, as long as the resource
> > > > resolves to a file. For other things trying to support it in the core
> > > > becomes tricky at best. You'd have to invoke the handler and intercept
> > > > the output, possibly buffering it (think
> > > > "bytes=15000-20000,0-20,17000-23000" - well, ok, the ordering
> > > > constraint for the output is only a SHOULD so we could reorder the
> > > > ranges to be strictly increasing and merge overlapping ranges, and we'd
> > > > still be conditionally compliant).
> > > > 
> > > > Streams would make this easier, btw...
> > > 
> > > hmm, a layer sounds nifty, but it doesn't work -- streams are sequential,
> > > so at a minimum you'd be doing read() and skipping bytes.  But byte ranges
> > > don't have to be in increasing order, so you might need to go backwards...
> > > you really need seek().
> > 
> > No, that's why I said we could reorder and merge the ranges.
> 
> i wasn't aware HTTP/1.1 allowed you to reorder and merge ranges... you
> sure?  i can't find it in a brief reading of rfc2068... 

RFC-2616 is the current spec. Section 14.16 states:

   When a client requests multiple byte-ranges in one request, the
   server SHOULD return them in the order that they appeared in the
   request.

Like I said, it's a SHOULD, so... As far as merging goes: it isn't
explicitly stated in the spec, but it is implicitly allowed in a couple
places (and the discussions on the WG it was obivous that merging was
allowed):

   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
   showing the number of bytes actually transferred. ...

and

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

I.e. merging is not a problem, reordering is arguable.

> > If we reorder
> > the above to "bytes=0-20,15000-23000" then all we need is to skip the
> > unwanted bytes (there's no way of getting around that, unless you have
> > the handler handle the ranges). It's not perfect, but you would then get
> > *every* resource being capable of accepting byte-ranges. You're weighing
> > reduced network traffic and ease of handler implementation against
> > wasted cpu-cycles and disk-io. Handlers could always decide to optimize
> > and handle the ranges themselves, of course.
> 
> yeah, but how many range requests do you think you'll get against dynamic
> content?  most dynamic content doesn't have an etag or last-modified which
> could be used to make a range request.

Umm, ranges are independant of etag and last-modified. They are quite
useful in restarting aborted responses. This seems to me at least as
important as the update scenario.


  Cheers,

  Ronald


Mime
View raw message