At 10:56 PM 6/5/2011 +0200, Xavier Noria wrote:
[snip] I mean. If it is true that Passenger should dechunk (as William says),
but it is not doing that, but the client still gets the chunked
response, I wondered whether it worked by luck rather than by all
the pieces following the contracts. Alway
On Sun, Jun 5, 2011 at 11:51 PM, Eric Covener wrote:
> On Sun, Jun 5, 2011 at 5:40 PM, Xavier Noria wrote:
>> On Sun, Jun 5, 2011 at 11:36 PM, Eric Covener wrote:
>>
If Passenger has to dechunk, and we want a chunked compressed
response, and Apache is the one responsible for doing tha
On Sun, Jun 5, 2011 at 5:40 PM, Xavier Noria wrote:
> On Sun, Jun 5, 2011 at 11:36 PM, Eric Covener wrote:
>
>>> If Passenger has to dechunk, and we want a chunked compressed
>>> response, and Apache is the one responsible for doing that, how should
>>> we signal Apache that we want compression a
On Sun, Jun 5, 2011 at 11:36 PM, Eric Covener wrote:
>> If Passenger has to dechunk, and we want a chunked compressed
>> response, and Apache is the one responsible for doing that, how should
>> we signal Apache that we want compression and streaming for that
>> particular response.
>
> This is t
> If Passenger has to dechunk, and we want a chunked compressed
> response, and Apache is the one responsible for doing that, how should
> we signal Apache that we want compression and streaming for that
> particular response.
This is the main path of just configuring mod_deflate. Nothing else
re
On Sun, Jun 5, 2011 at 9:54 PM, William A. Rowe Jr. wrote:
>> So I understand from your reply that httpd is the only one resposible
>> for chunked responses, compressed or otherwise. Is that correct?
>
> Thanks for the info. You are sort-of correct. The backend can possibly
> optimize things by
On Sun, Jun 5, 2011 at 10:47 PM, Stormy wrote:
> Ah, interesting... that you say it's an Apache module. Maybe Messrs Hongli
> Lai & Ninh Bui could help you with your compression and chunking challenges?
> 'Cos when you suggest that Apache is functioning "Guess that works by luck"
> I might be te
At 09:15 PM 6/5/2011 +0200, Xavier Noria wrote:
On Sun, Jun 5, 2011 at 8:16 PM, William A. Rowe Jr.
wrote:
> httpd (conditionally) handles the chunking... the app generator's
> chunking is never used. Â What *module* is installed in httpd? Â I'm
> not familiar with the above.
>
> Only the entry
On 6/5/2011 2:15 PM, Xavier Noria wrote:
>
> Ah, interesting.
>
> Phusion Passenger is an Apache module itself:
>
> http://www.modrails.com/
>
> Passenger is the most used solution for production deployments in Ruby
> on Rails nowadays.
>
> So I understand from your reply that httpd is the
On Sun, Jun 5, 2011 at 8:16 PM, William A. Rowe Jr. wrote:
> On 6/5/2011 12:31 PM, Xavier Noria wrote:
>
> httpd (conditionally) handles the chunking... the app generator's
> chunking is never used. What *module* is installed in httpd? I'm
> not familiar with the above.
>
> Only the entry point
On 6/5/2011 12:31 PM, Xavier Noria wrote:
>
> I am testing this with Phusion Passenger and Unicorn.
>
> They are going to implement compression for chunked responses. That
> is, they are going to dechunk, compress, and chunk again, mod_deflate
> won't be involved for these responses.
httpd (cond
Oh by the way. Sorry for not being specific enough in my question. I
am not really familiar with Apache modules (except for some mod_perl
experience) and do not know how to word my question correctly.
I guess my original question was whether mod_deflate dechunks and
compresses on the fly. Response
On Sun, Jun 5, 2011 at 7:01 PM, William A. Rowe Jr. wrote:
> you need to be more specific.
>
> HTTP 2.x has a filtering schema which applies -protocol- filters
> after all -content-. Modules are presumed to generate content
> unless they manipulate the filter stack.
>
> mod_proxy dechunks the ba
On 6/5/2011 11:47 AM, Xavier Noria wrote:
>
> Also, it is clear that mod_deflate does not understand chunked
> encoding coming from the app server. It compresses the payload.
Xavier,
you need to be more specific.
HTTP 2.x has a filtering schema which applies -protocol- filters
after all -conten
I think that's definitely not correct. Browsers do inflate and process
the HTML on the fly, they do not wait for the entire payload.
Chrome seems to have a buffer of 256 bytes, and Firefox has none.
I have used this server for testing this:
https://gist.github.com/1009108
and monitored when
> In my case, it appears Apache selects the chunked encoding automagically
> when the size of the page goes over a certain size. Apache doesn't seem
> to set the smaller pages to the chunked encoding (even though they are
> gzipped).
No, this was wrong. Mod_file_cache was tricking me (again).
> Can you provide some more information to be able
> to reproduce your test over here?
Just make a web page like the one described. Enable mod_deflate and load the
page in your favorite browser that has debugging
(Firebug, IE9, Chrome, etc). In my case, it appears Apache selects the chunked
e
Thanks a lot Geoff. Can you provide some more information to be able
to reproduce your test over here? And how many chunks did the response
contain?
In addition to that, if someone with first-hand knowledge of Apache or
browser internals could shed a light I'd really appreciate it. Reverse
enginee
> My test showed (according to Firebug) that the 15 MB
> page downloaded in 618ms.
Should clarify that on disk, the page was 14,254,523 bytes but after deflating,
I downloaded a mere 314 bytes of headers
(uncompressed) plus the 41,841 byte response body (compressed) for a total
payload of 42,
> Goal is to get the HEAD of HTML documents in the client side as soon
> as possible ...thus having a more responsive page...
Agreed!
> Can anyone confirm or deny this...
+1
I ran a quick test on a 10MB file that looks like this:
About 15 megabytes of dummy ascii text here...
And my FF4
On Tue, May 31, 2011 at 11:54 AM, Geoff Millikan
wrote:
>> ...is it possible that mod_deflate works by chunks...
>
> Why are you doing this? It's not to increase client-side performance because
> correct me if I'm wrong here but it's been my
> understanding that the web browser cannot start dec
> ...is it possible that mod_deflate works by chunks...
Why are you doing this? It's not to increase client-side performance because
correct me if I'm wrong here but it's been my
understanding that the web browser cannot start decompressing the page until it
receives the final chunk. Based on
22 matches
Mail list logo
