httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: The Byterange filter -- a new design -- feel free to rip it to shreds
Date Tue, 13 Jul 2004 13:04:08 GMT


Graham Leggett wrote:
> Geoffrey Young wrote:
> 
>> while I'm all for reducing server overhead (who isn't :) playing these
>> kind
>> of games with the filter API seems like such a bad idea.  what we have
>> now
>> is a modular design that is simple and works - content handlers
>> generate a
>> response, while various filters adjust that response based on interesting
>> criteria.  requiring that one know anything about the other breaks that
>> model and has the potential to get us into a hole from which it is
>> difficult
>> to escape.
> 
> 
> Which is a point I made in part of the post that you didn't quote above.

ok, sorry :)

please take the rest of this as just a friendly discussion - I don't want it
to turn into some kind of bickering match, since that's definitely not what
I have in mind :)

> 
> To try and make my point again more clearly:
> 
> Content is generated in compliance with the HTTP/1.1 specification. This
> HTTP/1.1 compliant content is then fed through several filters, which
> potentially alter the data in compliance with the HTTP/1.1
> specification. Eventually the filtered content is sent out over the
> network in compliance with the HTTP/1.1 specification.

ok, that isn't the idea I had about output filters at all.  my own concept
of how this all worked (or should work) is that content handlers are
supposed to just generate content.  specifically, they should not care at
all about RFC compliance - this is why we have a separate header filter,
byterange filter, and so on (and why I think ap_set_last_modified foo should
be in its own filter ;)

everyone else here is much more intimate with how filters came to be, so
I'll accept that I was wrong with that assumption, but a number of factors
brought me to that conclusion, such as the removal of the
ap_set_byterange/ap_each_byterange API, the C-L filter, etc - all of these
things make it possible for content handlers to focus on the simple job of
generating content, while relying on core features to make the complete
response RFC compliant.

> 
> If the byte range filter is not capable of receiving and intelligently
> handling a 206 Partial Content from a content handler, then the byte
> range filter is not compliant with HTTP/1.1, and is therefore broken.

clearly.

> 
> If any other filter is not capable of processing data that has come from
> a 206 Partial Content response, AND that filter does not either a)
> remove itself from the filter stack, or b) remove the Range header from
> the request, then that filter is not compliant with the HTTP/1.1
> specification, and is therefore broken.

that's true if I'm wrong about the assumption above.  but in my mind, the
filter API is the most useful if content handlers (and content-altering
filters) can remain ignorant of 206 responses and the byterange filter can
bat cleanup.

> 
> Up until now it has been simplistically assumed that ALL content
> handlers will only ever generate full responses, and so filters and
> certain content handlers have ignored the Range part of RFC2616.

well, I assumed that was by design for the reason mentioned above, namely
that the API set/each_byterange API we used to use in 1.3 was replaced with
the byterange filter.

> With
> the existance of mod_proxy, mod_jk, mod_backhand (etc) taking this
> shortcut does not make sense.

I don't grok what you're trying to say here, unless you mean that it doesn't
make sense to take the long way around, with content handlers always
producing the full response (as you have indicated elsewhere).

> 
> Nowhere in the above is any requirement laid down that one module must
> depend on another one. The only requirement is that content handlers and
> filters must behave in a way that is compliant with the HTTP/1.1
> specification.

sure :)  I guess where we have different ideas, then, is in who exactly
should be responsible for RFC compliance.  I had always assumed that there
was (or should be) very little that a content handler needed to worry about
in this respect, and that it was the job of the core server engine (via
various early or late-running filters) to take care of things like HEAD
requests, HTTP/0.9 requests/responses, chunked encoding, range requests, etc.

anyway, again, I'm not trying to be belligerant - the main reason I'm trying
to flesh this all out (even if I'm the only one who doesn't know it already
:) is that if the ideas behind the current API design are clear to me then I
can help design the Perl interface to the C API so that it matches the real
intent here.

--Geoff

Mime
View raw message