It's more efficient. A stat syscall can get you the file-size of a
local file before attempting to do anything else. You can't do the
equivalent with an unknown request that gets streamed in from a backend
server. You could check, but I think the content-length indicates the
uncompressed content
Yep, I think it got lost nick. I'd go along with the filter idea after
deflate if it does what I need. Are you referring to mod_filter based
directives such as FilterProvider/FilterProtocol?
The client/partner/vendor isn't requiring it to support HTTP, but to
support their services.
-Tony
---
Yep, that's what I said, should. It doesn't require it and I understand
why I's chunking and streaming it for speed of sending. But why should
it send the content-length out properly for static files and not use
chunked encoding, and fail to do the same for my tomcat content and use
chunked encodin
Sorry, CDN is Content Delivery Network. Akamai, Limelight, etc..
While the CDN supports chunked transfer fine for actually delivering
data, to utilize its caching services (which is the whole point of the
CDN obviously) it wants the content-length header from my servers. It's
stupid, yes, but getti
On Thu, 2009-07-16 at 10:20 -0600, Anthony J. Biacco wrote:
> We're not violating the specs, we're following them. The HTTP spec
> states that you should send out a content-length header with the correct
> trasnfer length, and mod_deflate in this case is not doing that.
>
> -Tony
No it doesn't; i
I'm not familiar with the CDN acronym. I could be mistaken, but I'm
fairly certain that HTTP 1.1 required support for chunked transfer
(which implies Content-Length would NOT be required for anything HTTP
1.1 compliant). Additionally, I thought the content-length referenced
the contents of the fi
Looks like this got lost in the ether ...
Begin forwarded message:
On 15 Jul 2009, at 23:39, Anthony J. Biacco wrote:
I'm trying to use mod_deflate to compress data coming out of tomcat
through mod_jk and need the proper content-length header set for the
COMPRESSED data, but can't do this be
I can get the compressed content, that's not a problem. My thing is, I'm
trying to cache said response at my CDN. The CDN requires a
content-length header (among other things) to do this. And with the
chunked encoding I'm not getting one (fyi, I'm not doing chunked from
tomcat, I'm actually sending
On Thu, Jul 16, 2009 at 00:39, Anthony J.
Biacco wrote:
> I'm trying to use mod_deflate to compress data coming out of tomcat
> through mod_jk and need the proper content-length header set for the
> COMPRESSED data, but can't do this because the data is streamed and sent
> after the headers are set
We're not violating the specs, we're following them. The HTTP spec
states that you should send out a content-length header with the correct
trasnfer length, and mod_deflate in this case is not doing that.
-Tony
---
Manager, IT Operations
Format Dynamics, Inc.
303-573-1800x2
I don't understand why standard mod_deflate functionality won't work.
If you violate the specs and muck with content-length, it's not going to
work right in a browser, anyhow.
Thanks,
Rick Houser
Auto-Owners Insurance
Systems Support
(517)703-2580
-Original Message-
From: Anthony J. Bi
11 matches
Mail list logo
