Mailing List Archive: Apache: Users

GZIP DEFLATE and HTTPD

Index | Next | Previous | View Threaded

akash.delhite at gmail

Aug 7, 2013, 12:48 PM

Post #1 of 8 (55 views)
Permalink

GZIP DEFLATE and HTTPD

We had a weird issue of Akamai not caching static content like JS, CSS etc.
On debugging, they reported that we are sending "Vary:Accept Encoding" is
causing issue.
But I think that mod_deflate automatically sends that (for proxies)

However, I have explicitly unset that header so that Akamai can cache. Are
there any downsides of this ?
Also do I need to turn off the compression also in case the same compressed
file is not returned by HTTPD for the same uncompressed file.

Thanks,
Akash

covener at gmail

Aug 7, 2013, 12:53 PM

Post #2 of 8 (54 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

On Wed, Aug 7, 2013 at 3:48 PM, Akash Jain <akash.delhite [at] gmail> wrote:
> We had a weird issue of Akamai not caching static content like JS, CSS etc.
> On debugging, they reported that we are sending "Vary:Accept Encoding" is
> causing issue.
> But I think that mod_deflate automatically sends that (for proxies)
>
> However, I have explicitly unset that header so that Akamai can cache. Are
> there any downsides of this ?

If someone requests a file from a browser not capable of gzip
compression, they'll get an unreadable file, because it will be served
out of the cache in gzipped form.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

akash.delhite at gmail

Aug 7, 2013, 1:02 PM

Post #3 of 8 (54 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

But all modern browsers support it, right ?
Are there any downsides for not using Vary:Accept Encoding with
mod_deflate?

On Thu, Aug 8, 2013 at 1:23 AM, Eric Covener <covener [at] gmail> wrote:

> On Wed, Aug 7, 2013 at 3:48 PM, Akash Jain <akash.delhite [at] gmail>
> wrote:
> > We had a weird issue of Akamai not caching static content like JS, CSS
> etc.
> > On debugging, they reported that we are sending "Vary:Accept Encoding" is
> > causing issue.
> > But I think that mod_deflate automatically sends that (for proxies)
> >
> > However, I have explicitly unset that header so that Akamai can cache.
> Are
> > there any downsides of this ?
>
> If someone requests a file from a browser not capable of gzip
> compression, they'll get an unreadable file, because it will be served
> out of the cache in gzipped form.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe [at] httpd
> For additional commands, e-mail: users-help [at] httpd
>
>

nick at webthing

Aug 7, 2013, 1:39 PM

Post #4 of 8 (53 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

On 7 Aug 2013, at 21:02, Akash Jain wrote:

> But all modern browsers support it, right ?
> Are there any downsides for not using Vary:Accept Encoding with mod_deflate?

If you omit a Vary header, you're telling the cache you can't supply
other variants. That leaves the cache the choice of returning the
wrong contents to some clients, or returning an error. Or perhaps
ignoring the HTTP spec and asking the backend every time,
which would undermine all the benefits of HTTP cacheing.

Sounds like akamai is broken. Or rather, not configured to cache
negotiated contents. Does it also refuse to cache multilingual pages?

--
Nick Kew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

ben at reser

Aug 7, 2013, 1:45 PM

Post #5 of 8 (54 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

On Wed, Aug 7, 2013 at 1:39 PM, Nick Kew <nick [at] webthing> wrote:
> If you omit a Vary header, you're telling the cache you can't supply
> other variants. That leaves the cache the choice of returning the
> wrong contents to some clients, or returning an error. Or perhaps
> ignoring the HTTP spec and asking the backend every time,
> which would undermine all the benefits of HTTP cacheing.
>
> Sounds like akamai is broken. Or rather, not configured to cache
> negotiated contents. Does it also refuse to cache multilingual pages?

It's been a while but I'm pretty sure Akamai can properly handle these cases.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

akash.delhite at gmail

Aug 7, 2013, 1:59 PM

Post #6 of 8 (54 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

Per Akamai Guy, Vary shows akamai that content can vary so akamai is not
caching, and this leading akamai to make requests to our webversion ...
We mostly just use JS and CSS to be served from akamai ..

On Thu, Aug 8, 2013 at 2:09 AM, Nick Kew <nick [at] webthing> wrote:

>
> On 7 Aug 2013, at 21:02, Akash Jain wrote:
>
> > But all modern browsers support it, right ?
> > Are there any downsides for not using Vary:Accept Encoding with
> mod_deflate?
>
> If you omit a Vary header, you're telling the cache you can't supply
> other variants. That leaves the cache the choice of returning the
> wrong contents to some clients, or returning an error. Or perhaps
> ignoring the HTTP spec and asking the backend every time,
> which would undermine all the benefits of HTTP cacheing.
>
> Sounds like akamai is broken. Or rather, not configured to cache
> negotiated contents. Does it also refuse to cache multilingual pages?
>
> --
> Nick Kew
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe [at] httpd
> For additional commands, e-mail: users-help [at] httpd
>
>

ben at reser

Aug 7, 2013, 2:42 PM

Post #7 of 8 (48 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

On Wed, Aug 7, 2013 at 1:59 PM, Akash Jain <akash.delhite [at] gmail> wrote:
> Per Akamai Guy, Vary shows akamai that content can vary so akamai is not
> caching, and this leading akamai to make requests to our webversion ...
> We mostly just use JS and CSS to be served from akamai ..

I think whoever you're talking about at Akamai isn't being very
helpful. I know at a minimum you can simply not use compression
between you and Akamai and then turn on content-acceleration and Akmai
will do the compression for you. But I'm pretty sure they can also
support compression from the origin as well.

Using a random css file from Godady's website:
http://img2.wsimg.com/pc_css/1/gd_H_20130624_http.min.css

If I do the following with and without the --compressed I see that the
file is cached:
$ curl -H 'Pragma: akamai-x-cache-on, akamai-x-get-cache-key,
akamai-x-get-true-cache-key, akamai-x-serial-no' -v -o /dev/null
http://img2.wsimg.com/pc_css/1/gd_H_20130624_http.min.css
(note the X-Cache response with TCP_MEM_HIT).

Using the X-Cache-Key header you can find the origin server which is
images.secureserver.net in this case...

Hitting it like so:
$ curl --compressed -v -o /dev/null
http://img2.wsimg.com/pc_css/1/gd_H_20130624_http.min.css

I see that they are using Content-Encoding: gzip and Vary: Accept-Encoding.

I'm not sure if there's some config they have on their side to avoid
Akamai request compression or for their origin server to refuse to
give Akamai gzip. Unfortunately I don't have an Akamai setup anymore
to play with.

Thing is Akamai benefits from properly supporting this because their
bandwidth bill to retrieve data from the origin server goes down.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd

akash.delhite at gmail

Aug 8, 2013, 10:05 PM

Post #8 of 8 (37 views)
Permalink

Re: GZIP DEFLATE and HTTPD [In reply to]

Thanks a lot Ben. That helped.

On Thu, Aug 8, 2013 at 3:12 AM, Ben Reser <ben [at] reser> wrote:

> On Wed, Aug 7, 2013 at 1:59 PM, Akash Jain <akash.delhite [at] gmail>
> wrote:
> > Per Akamai Guy, Vary shows akamai that content can vary so akamai is not
> > caching, and this leading akamai to make requests to our webversion ...
> > We mostly just use JS and CSS to be served from akamai ..
>
> I think whoever you're talking about at Akamai isn't being very
> helpful. I know at a minimum you can simply not use compression
> between you and Akamai and then turn on content-acceleration and Akmai
> will do the compression for you. But I'm pretty sure they can also
> support compression from the origin as well.
>
> Using a random css file from Godady's website:
> http://img2.wsimg.com/pc_css/1/gd_H_20130624_http.min.css
>
> If I do the following with and without the --compressed I see that the
> file is cached:
> $ curl -H 'Pragma: akamai-x-cache-on, akamai-x-get-cache-key,
> akamai-x-get-true-cache-key, akamai-x-serial-no' -v -o /dev/null
> http://img2.wsimg.com/pc_css/1/gd_H_20130624_http.min.css
> (note the X-Cache response with TCP_MEM_HIT).
>
> Using the X-Cache-Key header you can find the origin server which is
> images.secureserver.net in this case...
>
> Hitting it like so:
> $ curl --compressed -v -o /dev/null
> http://img2.wsimg.com/pc_css/1/gd_H_20130624_http.min.css
>
> I see that they are using Content-Encoding: gzip and Vary: Accept-Encoding.
>
> I'm not sure if there's some config they have on their side to avoid
> Akamai request compression or for their origin server to refuse to
> give Akamai gzip. Unfortunately I don't have an Akamai setup anymore
> to play with.
>
> Thing is Akamai benefits from properly supporting this because their
> bandwidth bill to retrieve data from the origin server goes down.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe [at] httpd
> For additional commands, e-mail: users-help [at] httpd
>
>

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads