httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: 'Range: bytes=' request with starting byte greater than size of f ile
Date Tue, 14 Sep 1999 16:22:47 GMT


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

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

> > could be generalised with a function pointer
> > 
> >     (*send)(void *, request_rec *, off_t, off_t);
> 
> Umm, probably just being dense, but how is that to be invoked? Is that
> a callback for handlers to register with the core?

i was just suggesting a function which did the sending, byte range or
otherwise, by calling a supplied send function. 

Dean



Mime
View raw message