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
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
On Sun, Jun 5, 2011 at 7:01 PM, William A. Rowe Jr. wr...@rowe-clan.net 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
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.
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
On Sun, Jun 5, 2011 at 8:16 PM, William A. Rowe Jr. wr...@rowe-clan.net 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
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 only one
At 09:15 PM 6/5/2011 +0200, Xavier Noria wrote:
On Sun, Jun 5, 2011 at 8:16 PM, William A. Rowe Jr. wr...@rowe-clan.net
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.
On Sun, Jun 5, 2011 at 10:47 PM, Stormy storm...@stormy.ca 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
On Sun, Jun 5, 2011 at 9:54 PM, William A. Rowe Jr. wr...@rowe-clan.net 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
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
On Sun, Jun 5, 2011 at 11:36 PM, Eric Covener cove...@gmail.com 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.
On Sun, Jun 5, 2011 at 5:40 PM, Xavier Noria f...@hashref.com wrote:
On Sun, Jun 5, 2011 at 11:36 PM, Eric Covener cove...@gmail.com 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
On Sun, Jun 5, 2011 at 11:51 PM, Eric Covener cove...@gmail.com wrote:
On Sun, Jun 5, 2011 at 5:40 PM, Xavier Noria f...@hashref.com wrote:
On Sun, Jun 5, 2011 at 11:36 PM, Eric Covener cove...@gmail.com wrote:
If Passenger has to dechunk, and we want a chunked compressed
response, and
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.
...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
On Tue, May 31, 2011 at 11:54 AM, Geoff Millikan
gmilli...@t1shopper.com 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
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:
htmlhead
link rel=stylesheet href=broken_link_here.css
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
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
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
21 matches
Mail list logo
