Re: [squid-users] Content-encoding header lost when getting a "304 Not Modified" reply

It's pretty easy to test using squidclient or another simple HTTP tool

1. squidclient -h webserver -p 80 http://domain/path/to/file

2. squidclient -H "Accept-Encoding: gzip\n" -h webserver -p 80
http://domain/path/to/file

Things you should look for in the responses:

a) That the first isn't compressed

b) If the second is then there should be an Vary header listing
Accept-Encoding.

c) If there is an ETag header then it must differ between the compressed
and uncompressed variants.

If either test fails then the cache will not be able to learn the
correct variance of the object and the first cached will be given to all
clients regardless if they support compression or not.

* first is compressed

* second is compressed but there is no Vary header

* or the two responses differ in compression but share the same ETag
header

Regards
Henrik

On tis, 2007-12-11 at 03:55 -0800, Johan Sarnstrom wrote:
> Changing To: so that all interested can see this.
>
> I know that they have MS ISA doing reverse proxy in front of the SAP Portal. But sadly no access there either..
> And even though we are working on a parallell test-environment, we can't just restart it either..
>
> They are just about to disable compression on the SAP end, and I've talked to MS support to get the KB321722 fix which has to do with compressed data and Expires headers.
>
> Just hoping to get this problem sorted out so i can take vacation tomorrow :)
>
> /Johan
>
>
> ----- Original Message ----
> From: Neil A. Hillard <neil.hillard@agustawestland.com>
> To: Johan Sarnstrom <j_sarnstrom@yahoo.com>
> Sent: Tuesday, December 11, 2007 12:18:14 PM
> Subject: Re: [squid-users] Content-encoding header lost when getting a "304 Not Modified" reply
>
> Johan,
>
> my reply was meant to go to the list but seems I didn't change to 'To:'
> address like normal!
>
> Do you have access to one of the proxies? If so you could make a packet
> capture there.
>
> We use SAP Portal, with an Apache reverse proxy in front. We disable
> compression because we perform HTML rewriting on the Apache machine. I
> think I have our external portal set to recompress after the rewriting
> but I'm not 100% sure!
>
> ATB,
>
>
> Neil.
>
> Johan Sarnstrom wrote:
> > Hi Neil
> >
> > Thanks for your reply.
> > The origin server is physically in another country, outsourced to another company, so sadly i'm not allowed to capture the packets there.
> > I looked into IE, and it seems it has some problem too. http://www.sitepoint.com/forums/showthread.php?threadid=158442
> >
> > I'm trying to install IE7 on one client i'm testing with to see if it solves the problem.
> > Still the company does not want to interfere or put too many demands on the customers infrastructure or clients, so it still seems like we are forced to disable compression...
> >
> >
> > /Johan
> >
> >
> > ----- Original Message ----
> > From: Neil A. Hillard <neil.hillard@agustawestland.com>
> > To: Johan Sarnstrom <j_sarnstrom@yahoo.com>
> > Sent: Tuesday, December 11, 2007 11:41:19 AM
> > Subject: Re: [squid-users] Content-encoding header lost when getting a "304 Not Modified" reply
> >
> > Johan,
> >
> >> I'm having problems with a SAP Netweaver portal. For 99% of the users it works fine, but for a few users it's just the top information of the page that loads.
> >> Some of these users are having Squid proxies, but different versions..
> >> The problem seems to be related to some proxies not sending HTTP 1.1 requests.
> >> I've looked at the headers and noticed that some .js are referred to at least two times.
> >> The first reply correctly states that the content is compressed, but the second reply tells the client to use the locally cached copy, and does not give the "content-encoding: gzip". This causes Internet Explorer to try to use the compressed locally stored file, but not uncompressing it.
> >> Has anyone had this problem before?
> >>
> >> What's the solution? Not using compression at all?
> >> Sadly i don't have the possibility to check the exact replies from the server.. Guess that would tell me who's really the bad guy here :)
> >
> > A 304 shouldn't set a content encoding as there isn't any content to
> > encode! If IE expects one to be set then I would suspect it is at fault.
> >
> > Are you not able to packet capture the data between the proxy and the
> > origin server?
> >
> >
> > Neil.
> >
>
>