For requests that are chunked (Transfer-Encoding: chunked and no Content-Length header) calling $r->read returns *unchunked* data from the socket.
That's indeed handy. Is that mod_perl doing that un-chunking or is it Apache? 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 mose...@hank.org
