[Mod_gzip] Mod_gzip and location: headers

Tue, 17 Feb 2004 03:31:38 EST

--part1_46.471880d3.2d632b6a_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Jann...
This is Kevin Kiley...

> earlier it was stated that some people are having issues when you use 
> mod_gzip and some places on your site forward the user to another page 
> using a Location: header.

Didn't see those messages but I believe you.

> Essentially mod_gzip eats the entire request and the browser never gets 
> the Location: request.

About the only way I can think of that this might happen is if the 
Server is brain-dead enough to actually make it look like it's
going to deliver the real content but sends just a "Location:" 
header instead of the real data.

What I mean is... if the Server puts together an actual '200' response
and it also adds a valid "Content-type:" header but then just tacks
on a "Location:" header then ANY 'content filter' you might be running
is going to have a problem with that. It will think that data is supposed
to be coming ( of 'Content-type: X' ) but nothing ever comes from
the Server.

> Anyone know of a workaround or solution (short of NOT using Location: 
> headers).

Sure...

mod_gzip_item_exclude rspheader "Location: *"

Just make sure mod_gzip doesn't try to compress something
when nothing is going to be sent by the Server.

In all cases when 'certain' response header fields should automatically
exclude a response from being 'touched' by mod_gzip the solution
is to add an 'exclusion' record that uses the 'rspheader' keyword.

That's what it's there for.

Later...
Kevin

PS: Do you have a good capture of a response with a "Location:" header
in it that doesn't work? I'd be curious to see exactly what OTHER fields
the Server is putting out along with the "Location:" header. If it's a 200
response that also has a valid "Content-type:" and that content-type
is being included in the list of things to be 'compressed' then that
could be the problem right there.

PPS: We ARE talking about "Location:" header and not "Content-Location:",
right? They are 2 different animals... but even if "Content-Location:" was
causing weirdness the solution would be the same 'exclusion' using
rspheader keyword.

In a message dated 2/17/2004 12:08:05 AM Central Standard Time, jann@jann.com 
writes:

> earlier it was stated that some people are having issues when you use 
> mod_gzip and some places on your site forward the user to another page 
> using a Location: header.
> 
> Essentially mod_gzip eats the entire request and the browser never gets 
> the Location: request.
> 
> HLP!
> 
> Anyone know of a workaround or solution (short of NOT using Location: 
> headers).
> 
> 
> 
> 
> Mr. Jann Linder
> DinnerBroker
> San Francisco, CA
> 888.432.8288 x5249
> 
> _______________________________________________
> mod_gzip mailing list
> mod_gzip@lists.over.net
> http://lists.over.net/mailman/listinfo/mod_gzip
> 

--part1_46.471880d3.2d632b6a_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML><FONT FACE=3Darial,helvetica><HTML><FONT  SIZE=3D2 PTSIZE=3D10><BR>
Hi Jann...<BR>
This is Kevin Kiley...<BR>
<BR>
&gt; earlier it was stated that some people are having issues when you use <=
BR>
&gt; mod_gzip and some places on your site forward the user to another page=20=
<BR>
&gt; using a Location: header.<BR>
<BR>
Didn't see those messages but I believe you.<BR>
<BR>
&gt; Essentially mod_gzip eats the entire request and the browser never gets=
 <BR>
&gt; the Location: request.<BR>
<BR>
About the only way I can think of that this might happen is if the <BR>
Server is brain-dead enough to actually make it look like it's<BR>
going to deliver the real content but sends just a "Location:" <BR>
header instead of the real data.<BR>
<BR>
What I mean is... if the Server puts together an actual '200' response<BR>
and it also adds a valid "Content-type:" header but then just tacks<BR>
on a "Location:" header then ANY 'content filter' you might be running<BR>
is going to have a problem with that. It will think that data is supposed<BR=
>
to be coming ( of 'Content-type: X' ) but nothing ever comes from<BR>
the Server.<BR>
<BR>
&gt; Anyone know of a workaround or solution (short of NOT using Location: <=
BR>
&gt; headers).<BR>
<BR>
Sure...<BR>
<BR>
mod_gzip_item_exclude rspheader "Location: *"<BR>
<BR>
Just make sure mod_gzip doesn't try to compress something<BR>
when nothing is going to be sent by the Server.<BR>
<BR>
In all cases when 'certain' response header fields should automatically<BR>
exclude a response from being 'touched' by mod_gzip the solution<BR>
is to add an 'exclusion' record that uses the 'rspheader' keyword.<BR>
<BR>
That's what it's there for.<BR>
<BR>
Later...<BR>
Kevin<BR>
<BR>
PS: Do you have a good capture of a response with a "Location:" header<BR>
in it that doesn't work? I'd be curious to see exactly what OTHER fields<BR>
the Server is putting out along with the "Location:" header. If it's a 200<B=
R>
response that also has a valid "Content-type:" and that content-type<BR>
is being included in the list of things to be 'compressed' then that<BR>
could be the problem right there.<BR>
<BR>
PPS: We ARE talking about "Location:" header and not "Content-Location:",<BR=
>
right? They are 2 different animals... but even if "Content-Location:" was<B=
R>
causing weirdness the solution would be the same 'exclusion' using<BR>
rspheader keyword.<BR>
<BR>
In a message dated 2/17/2004 12:08:05 AM Central Standard Time, jann@jann.co=
m writes:<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">earlier it was stated that some=
 people are having issues when you use <BR>
mod_gzip and some places on your site forward the user to another page <BR>
using a Location: header.<BR>
<BR>
Essentially mod_gzip eats the entire request and the browser never gets <BR>
the Location: request.<BR>
<BR>
HLP!<BR>
<BR>
Anyone know of a workaround or solution (short of NOT using Location: <BR>
headers).<BR>
<BR>
<BR>
<BR>
<BR>
Mr. Jann Linder<BR>
DinnerBroker<BR>
San Francisco, CA<BR>
888.432.8288 x5249<BR>
<BR>
_______________________________________________<BR>
mod_gzip mailing list<BR>
mod_gzip@lists.over.net<BR>
http://lists.over.net/mailman/listinfo/mod_gzip<BR>
</BLOCKQUOTE><BR>
<BR>
</FONT></HTML>
--part1_46.471880d3.2d632b6a_boundary--