perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Moseley <>
Subject mod_perl and Transfer-Encoding: chunked
Date Tue, 02 Jul 2013 15:20:45 GMT
For requests that are chunked (Transfer-Encoding: chunked and no
Content-Length header) calling $r->read returns *unchunked* data from the

That's indeed handy.  Is that mod_perl doing that un-chunking or is it

But, it leads to some questions.

First, if $r->read reads unchunked data then why is there a
Transfer-Encoding header saying that the content is chunked?   Shouldn't
that header be removed?   How does one know if the content is chunked or
not, otherwise?

Second, if there's no Content-Length header then how does one know how much
data to read using $r->read?

One answer is until $r->read returns zero bytes, of course.  But, is
that guaranteed to always be the case, even for, say, pipelined requests?
My guess is yes because whatever is de-chunking the request knows to stop
after reading the last chunk, trailer and empty line.   Can
anyone elaborate on how Apache/mod_perl is doing this?

Perhaps I'm approaching this incorrectly, but this is all a bit untidy.

I'm using Catalyst and Catalyst needs a Content-Length.  So, I have a Plack
Middleware component that creates a temporary file writing the buffer from
$r->read( my $buffer, 64 * 1024 ) until that returns zero bytes.  I pass
this file handle onto Catalyst.

Then, for some content-types, Catalyst (via HTTP::Body) writes the body to *
another* temp file.    I don't know how Apache/mod_perl does its
de-chunking, but I can call $r->read with a huge buffer length and Apache
returns that.  So, maybe Apache is buffering to disk, too.

In other words, for each tiny chunked JSON POST or PUT I'm creating two (or
three?) temp files which doesn't seem ideal.

Bill Moseley

View raw message