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-L
Bill Moseley wrote:
André, thanks for the response:
On Thu, Jul 4, 2013 at 4:06 AM, André Warnier wrote:
Bill Moseley wrote:
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?
Looking
André, thanks for the response:
On Thu, Jul 4, 2013 at 4:06 AM, André Warnier wrote:
>
> Bill Moseley wrote:
>
>>
>> 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?
>>
>
Looking at
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 indee
On 03/07/2013 23:42, Joseph Schaefer wrote:
> 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 dat
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
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 impleme
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 c
On Wed, Jul 3, 2013 at 4:31 PM, Jim Schueler wrote:
> 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 stream
without any
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 f
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.
Th
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 call
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 wrote:
> I played around with chunking recently in the context of media streaming:
> The client is only requesting a "chunk" of da
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 y
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 da
15 matches
Mail list logo