[Mod_gzip] Mod_gzip and location: headers

Tue, 17 Feb 2004 10:13:35 -0800

Hi Kevin:

First of all, thanks so much for the quick response.

The Location header was not what the error was.  (thanks, though--i 
found this out the hard way)... Let me explain quickly:

Using HTML::Embperl now, we are attempting to use mod_gzip as well.

i have the following setup:

<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_can_negotiate Yes
mod_gzip_command_version '/mod_gzip_status'
mod_gzip_temp_dir /tmp
mod_gzip_keep_workfiles No
mod_gzip_minimum_file_size 500
mod_gzip_maximum_file_size 500000
mod_gzip_maximum_inmem_size 60000
mod_gzip_min_http 1001
mod_gzip_handle_methods GET POST
mod_gzip_item_exclude reqheader "User-agent: Mozilla/4.0[678]"
mod_gzip_item_include file \.html$
mod_gzip_item_include mime ^text/html$
mod_gzip_item_include mime ^text/plain$
mod_gzip_item_include mime ^httpd/unix-directory$
mod_gzip_item_exclude mime ^image/
#mod_gzip_item_exclude rspheader "Location: .*"
mod_gzip_item_exclude file \.css$
mod_gzip_item_exclude file \.js$
mod_gzip_dechunk Yes
LogFormat "%h %l %u %t \"%V %r\" %<s %b mod_gzip: %{mod_gzip_result}n 
In:%{mod_gzip_input_size}n -< Out:%{mod_gzip_output_size}n = 
%{mod_gzip_compression_ratio}n pct." common_with_mod_gzip_info2
CustomLog /usr/local/apache/logs/mod_gzip_log common_with_mod_gzip_info2
mod_gzip_add_header_count Yes
mod_gzip_send_vary Yes

</IfModule>

The issue is that for authentication on the website, we use 
Apache::AuthCookie, which does the following:

When it hits: http://www1.dinnerbroker.com/my_account/this_url.html

Authcookie says: Hey, that area is protected:  Load up the 
corresponding login page using an internal redirect.

that page is: /membership/sign_in.html

THAT page submits to /LOGIN which AuthCookie uses to get the login 
info, sets a few cookies and forwards the user back to: 
/membership/sign_in.html using another internal redirect with all the 
cookies set.

This happens because Apache sets $rec_req->prev to the original url 
name (in this case /my_account/this_url.html) and the second time 
through, after the valid login, /membership/sign_in.html sees that 
$rec_req->prev has a value (again, in this case: 
/my_account/this_url.html).

One of the first lines in /membership/sign_in.html says:

if ($req_rec->prev)
{
	$uri = $req_rec->prev->uri. '?' .$req_rec->prev->args ;
}
else
{
	$uri = $fdat{destination} || '/home.html';
}

well... $req_rec->prev never is set... (and it IS set when i do NOT use 
mod_gzip)

i do not know why.

(ps: $req_rec is the HTML::Embperl variable holding the passed 
request_handler object)

Understand?  If so, can you tell me why this works when mod_gzip is not 
involved yet does not work WITH mod_gzip?

Thanks in advance for any help.

Mr. Jann Linder
DinnerBroker
San Francisco, CA
888.432.8288 x5249
On Feb 17, 2004, at 12:31 AM, TOKILEY@aol.com wrote:

>
>  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
>
>
>