C-L filter buffering snafu

[Joe Orton <jo...@redhat.com>]

https://bz.apache.org/bugzilla/show_bug.cgi?id=61222

I may be missing something here, ap_content_length_filter looks broken. 
Currently it implements an unlimited size buffer, by trying to morph 
every indeterminate length bucket into the heap.  It has the standard 
"read till it blocks then flush" logic, but this isn't a defence against 
RAM consumption!

If the (e.g) CGI script is fast enough that read()s never block it just 
keeps on sucking up HEAP buckets, as the simple repro case in the bug 
shows.

1. am I being stupid here?

2. otherwise, is there a good defence of why that filter should buffer 
to try to compute a C-L - exactly how much it should buffer & why?!

Regards, Joe

AW: C-L filter buffering snafu

[Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>]

Just put a reply in bugzilla (https://bz.apache.org/bugzilla/show_bug.cgi?id=61222#c4),
plus a patch proposal. Reilly weird that we have not been hit by this for such a long
time. I think we should not buffer.

Regards

Rüdiger

> -----Ursprüngliche Nachricht-----
> Von: Joe Orton [mailto:jorton@redhat.com]
> Gesendet: Montag, 11. September 2017 19:33
> An: dev@httpd.apache.org
> Betreff: C-L filter buffering snafu
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61222
> 
> I may be missing something here, ap_content_length_filter looks broken.
> Currently it implements an unlimited size buffer, by trying to morph
> every indeterminate length bucket into the heap.  It has the standard
> "read till it blocks then flush" logic, but this isn't a defence against
> RAM consumption!
> 
> If the (e.g) CGI script is fast enough that read()s never block it just
> keeps on sucking up HEAP buckets, as the simple repro case in the bug
> shows.
> 
> 1. am I being stupid here?
> 
> 2. otherwise, is there a good defence of why that filter should buffer
> to try to compute a C-L - exactly how much it should buffer & why?!
> 
> Regards, Joe