You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/17 19:08:54 UTC
RE: cvs commit: httpd-2.0/modules/http http_protocol.c
Ryan, 1st, the response of 10-20/* is valid if we don't
know the segment. 2nd, is this one-way, eg. if the user
requests 20-30,0-19 will we die if the input is a pipe
bucket, for example?
I'm not against a sort-merge function in 2.0 (in 1.3, I
believe it's overkill.)
> -----Original Message-----
> From: rbb@locus.apache.org [mailto:rbb@locus.apache.org]
> Sent: Sunday, December 17, 2000 12:04 PM
> To: httpd-2.0-cvs@apache.org
> Subject: cvs commit: httpd-2.0/modules/http http_protocol.c
>
>
> rbb 00/12/17 10:04:14
>
> Modified: . CHANGES
> modules/http http_protocol.c
> Log:
> Get byterange requests working with data that is generated by a handler
> that does not add a content-length. For example, mod_autoindex doesn't
> set a content-length, but the byterange filter requires one. We fix this
> by computing the content-length in the byterange filter.
RE: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by rb...@covalent.net.
> > > I'm not against a sort-merge function in 2.0 (in 1.3, I believe it's
> > > overkill.)
> >
> > A sort-merge function is wrong. According to the spec, we SHOULD keep the
> > response in the same order as the ranges were requested.
>
> In order? Perhaps. Merging consecutive overlapping or consecutive
> ranges? My reading indicates it's allowed.
It may be allowed, but it is still overkill. I personally suggest we just
return exactly what is asked for. It will work, and it is what we have
always done. We are protocol correct without trying to merge the
requested bytes.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Sunday, December 17, 2000 12:29 PM
>
> > I'm not against a sort-merge function in 2.0 (in 1.3, I believe it's
> > overkill.)
>
> A sort-merge function is wrong. According to the spec, we SHOULD keep the
> response in the same order as the ranges were requested.
In order? Perhaps. Merging consecutive overlapping or consecutive
ranges? My reading indicates it's allowed.
RE: cvs commit: httpd-2.0/modules/http http_protocol.c
Posted by rb...@covalent.net.
> Ryan, 1st, the response of 10-20/* is valid if we don't
> know the segment. 2nd, is this one-way, eg. if the user
> requests 20-30,0-19 will we die if the input is a pipe
> bucket, for example?
1) I'm not convinced that ever worked in Apache. I will need to look
closer. My initial impression is that because we need to check the
ranges, we need to have the c-l.
2) This does work with 20-30,0-19 if the input is a pipe. We get the
whole content, then we parse it to find the ranges. This is why we have
to keep the whole request in memory to do byteranges.
> I'm not against a sort-merge function in 2.0 (in 1.3, I believe it's
> overkill.)
A sort-merge function is wrong. According to the spec, we SHOULD keep the
response in the same order as the ranges were requested.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------