Broken connection filters (was: Transforming request to HTTP/1.1)

[Radoslaw Zielinski <ra...@pld-linux.org>]

Radoslaw Zielinski <ra...@pld-linux.org> [31-07-2006 18:20]:
[...]
> But... this doesn't quite work.  $r->protocol for these requests
> contains "HTTP/0.9".  The difference is: HTTP headers are neither
[...]
> I know I could get it done using filters, but writing them is a pain...

Well, I wrote a connection filter eventually, but it doesn't work either.

There seems to be a bug concerning filters.  Try writing an input filter
which would work like mod_ssl; a simple example I've used is uudecode:

  echo -n "GET / HTTP/1.1\r\nContent-length: 3\r\nHost: a\r\n\r\nXX\n" \
    | uuencode -

This will get you a perfectly fine HTTP/1.1 request, just uuencoded.
I have wasted $plenty of time trying to write a filter for decoding
something like this properly.  Failed.


I have used the example from user/handlers/filters.pod, section "Handling
Data Underruns" (requesting more brigades in one filter call) with
some minor modifications (like the split_buffer() function and changing
$f->r->connection to $f->c).

After passing the result of uudecode as buckets, PerlResponseHandler is
called, but $r->protocol is "HTTP/0.9".

The filter never gets an EOS bucket, just HEAP (and IMMORTAL when the
client closes the connection).  Endless loop, $f->next->get_brigade
returns empty brigades.

I have tried an other approach than the one presented in the example
from "Handling Data Underruns": just read and $b->delete the buckets,
then store their content in $f->ctx until there is enough data.  $bb is
left empty.  Filter has been called only for the first line of input.
Passing an empty bucket fixes it:

  $bb->insert_head(APR::Bucket->new($bb->bucket_alloc, ''));


Conclusion: one can't really write connection filters with mod_perl.  At
least not with v2.0.2.


I can post the handlers if someone wishes to investigate.

-- 
Radosław Zieliński <ra...@pld-linux.org>