On 04/07/13 17:48, Bill Moseley wrote:
Applications probably don't
need to care. They should receive the body -- so for mod_perl that means
reading data using $r-read until there's no more to read and then the app
should never need to look at the Transfer-Encoding header -- or
Content-Length
On 03/07/2013 21:53, Joseph Schaefer wrote:
When you read from the input filter chain as $r-read does, the http
input filter automatically handles the protocol and passes the dechunked
data up to the caller. It does not spool the stream at all.
You'd have to look at how mod perl implements
On 03/07/2013 23:26, Jim Schueler wrote:
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
Not disregarding the other answers to your questions, but I believe that maybe one aspect
has been neglected here.
Bill Moseley wrote:
For requests that are chunked (Transfer-Encoding: chunked and no
Content-Length header) calling $r-read returns *unchunked* data from the
socket.
That's
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove chunked from Transfer-Encoding
Apache/mod_perl is doing the first part but not updating the headers.
There's more
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove chunked from Transfer-Encoding
Apache/mod_perl is doing the first part but not updating
I played around with chunking recently in the context of media streaming:
The client is only requesting a chunk of data. Chunking is how media
players perform a seek. It was originally implemented for FTP
transfers: E.g, to transfer a large file in (say 10K) chunks. In the
case that you
Hi Jim,
This is the Transfer-Encoding: chunked I was writing about:
http://tools.ietf.org/html/rfc2616#section-3.6.1
On Wed, Jul 3, 2013 at 11:34 AM, Jim Schueler jschue...@eloquency.comwrote:
I played around with chunking recently in the context of media streaming:
The client is only
When you read from the input filter chain as $r-read does, the http input
filter automatically handles the protocol and passes the dechunked data up to
the caller. It does not spool the stream at all.
You'd have to look at how mod perl implements read to see if it loops its
ap_get_brigade
Thanks for the prompt response, but this is your question, not mine. I
hardly need an RTFM for my trouble.
I drew my conclusions using a packet sniffer. And as far-fetched as my
answer may seem, it's more plausible than your theory that Apache or
modperl is decoding a raw socket stream.
In light of Joe Schaefer's response, I appear to be outgunned. So, if
nothing else, can someone please clarify whether de-chunked means
re-assembled?
-Jim
On Wed, 3 Jul 2013, Jim Schueler wrote:
Thanks for the prompt response, but this is your question, not mine. I
hardly need an RTFM
On Wed, Jul 3, 2013 at 4:31 PM, Jim Schueler jschue...@eloquency.comwrote:
In light of Joe Schaefer's response, I appear to be outgunned. So, if
nothing else, can someone please clarify whether de-chunked means
re-assembled?
yes, where re-assembled means convert it back to the original data
Dechunked means it strips out the lines containing metadata about the next
block of raw data. The metadata is just the length of the next block of data.
Imagine a chunked stream is like having partial content length headers embedded
in the data stream.
The http filter embedded in httpd takes
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
14 matches
Mail list logo
