You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2000/11/02 23:35:35 UTC
Re: [PATCH] byterange handling with filters
On Thu, Nov 02, 2000 at 03:26:44PM -0800, rbb@covalent.net wrote:
>
> I am pretty sure that this is incorrect, and that the correct solution is
> a filter, but this is at least an attempt at getting byte-ranges working
> with filters. This is completely untested, so feel free to yell and
> scream at me. :-)
1) yell and scream: stop submitting code that you believe is broken. let's
keep apache working, rather than knowingly breaking it
2) comment: what are the ap_rflush() calls doing in there?
3) comment: it does appear that it will work fine
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] byterange handling with filters
Posted by rb...@covalent.net.
On Thu, 2 Nov 2000, Greg Stein wrote:
> On Thu, Nov 02, 2000 at 03:43:01PM -0800, rbb@covalent.net wrote:
> > On Thu, 2 Nov 2000, Greg Stein wrote:
> >...
> > > 2) comment: what are the ap_rflush() calls doing in there?
> >
> > If we don't flush the data that we have already sent, then the byte-range
> > information will end up at the wrong point in the response. This is why I
> > am not sure that the code will actually work, and I think this should be a
> > filter.
>
> Euh. I must have missed something (and I've deleted the message). Are you
> sending the byterange stuff to the connection (output) filters rather than
> the content filters? Eek.
>
> I can understand why that may be the case, but it will break. The FLUSH
> bucket is only advisory, IIRC. A filter may need to continue to hold onto
> some of the output.
Yeah, that's what I was thinking too. We have to send the byte-range
stuff directly to the connection filters, because it isn't content that
can be modified. I guess I'll toss this implementation, which is why I
posted it, I wanted/needed some in depth thought/feedback on this.
> I think you're right: punt on this implementation and make it a filter. It
> is the only way that we can be sure that we get the proper semantics and
> ordering.
Yep, implementing now.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: [PATCH] byterange handling with filters
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Nov 02, 2000 at 03:43:01PM -0800, rbb@covalent.net wrote:
> On Thu, 2 Nov 2000, Greg Stein wrote:
>...
> > 2) comment: what are the ap_rflush() calls doing in there?
>
> If we don't flush the data that we have already sent, then the byte-range
> information will end up at the wrong point in the response. This is why I
> am not sure that the code will actually work, and I think this should be a
> filter.
Euh. I must have missed something (and I've deleted the message). Are you
sending the byterange stuff to the connection (output) filters rather than
the content filters? Eek.
I can understand why that may be the case, but it will break. The FLUSH
bucket is only advisory, IIRC. A filter may need to continue to hold onto
some of the output.
> > 3) comment: it does appear that it will work fine
hrm. I was just looking at the bucket/brigade construction. If it bypasses
the output filters then we could have a problem.
I think you're right: punt on this implementation and make it a filter. It
is the only way that we can be sure that we get the proper semantics and
ordering.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PATCH] byterange handling with filters
Posted by rb...@covalent.net.
On Thu, 2 Nov 2000, Greg Stein wrote:
> On Thu, Nov 02, 2000 at 03:26:44PM -0800, rbb@covalent.net wrote:
> >
> > I am pretty sure that this is incorrect, and that the correct solution is
> > a filter, but this is at least an attempt at getting byte-ranges working
> > with filters. This is completely untested, so feel free to yell and
> > scream at me. :-)
>
> 1) yell and scream: stop submitting code that you believe is broken. let's
> keep apache working, rather than knowingly breaking it
Did I commit the code? No. I submitted it for review because I wanted
people to review it. If you don't want to review untested code, then hit
delete as soon as you read that I haven't tested it yet. :-)
> 2) comment: what are the ap_rflush() calls doing in there?
If we don't flush the data that we have already sent, then the byte-range
information will end up at the wrong point in the response. This is why I
am not sure that the code will actually work, and I think this should be a
filter.
> 3) comment: it does appear that it will work fine
Cool. I'm hoping to be able to test it before I commit tomorrow.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------