perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Protocol Philosophy
Date Fri, 10 Mar 2006 00:26:23 GMT
Chris Werner wrote:
>>You lost it here, Chris. Input filters feed the protocol handler, not >
> the other way around. 
> Maybe, but that's why I ask questions... Now read what you write:
>>... the protocol handlers simply ask the last input filter to give it >
> data ...
> Still, the protocol handler creates the BB object that the input filters
> populate. 
> And the filter populates that data in the BB created and supplied by the
> protocol handler. Or can a filter create a BB on it's own and somehow manage
> to get that data to a protocol handler that does not create a BB?
> I think the confusion here is the difference between data flow and object
> creation and data request. Perhaps you would be so kind as to spell out your
> best understanding of these topics?

Exactly. The limitation is due to the design of the filter stack/code.

Pretty much all I've learned about http2 filters is explained here:

The particular question of flow/data is explained here:

You're more than welcome to try to improve the documentation if you find 
it confusing. Just ask questions, get the answers and then make the docs 
more clear.

>>Certainly. Take SSI for example...
> OK, now there is an example of a filter complex enough to warrent state
> machine logic... considering that I am cerian there are others. I would
> still ask: Is decoding an encrypted stream doing the work of the protocol
> implementation?

Yes and no. You could do it in the protocol, but it's not the right place, 
since it requires that you change the logic of your app to do something 
that it shouldn't be really doing. mod_deflate for example does 
compression and decompression of the data - why would you complicate the 
logic of your application (i.e. protocol handler) to do this thing? A 
filter is a perfect location for this. It's also more efficient, since it 
does the most efficient chunking and buffering.

I think talks 
quite a lot about the reasoning for using filters, I agree it's a huge 
document so you may need to read it more than once before you can grasp it 
all. It took me a very long time to wrap my head around it.

>>... what if your ...[output?]... files live in a database?
> Sure, then the protocol handler passes a token to the output filter which
> looks up the proper response, and passes the contents out. A valid example
> of a data base lookup in a filter, but not exactly what I was referring
> too...

OK, mind to refine your question?

> ???

TMTOWTDI=There's More Than One Way To Do It

Stas Bekman
MailChannels: Assured Messaging(TM)
The "Practical mod_perl" book

View raw message