Antwort: [Mod_gzip] Issues with 1.3.26.1a: TIFF corrupted (if excluded) and 'Go Back' broken on Win98

[Keith Waters]

Michael, thanks for your reply...    Sorry for the delay in getting back to
you.

> > 1) For some reason, MIME type image/tiff was being messed up by mod_gzip
> > unless I did a mod_gzip_include of it.
>
> How did you come to this conclusion?

My apologies - "Messed up" was the 'user view' (not neccesarily the data
itself) - ie, did the page display ('work') or not?   I did not go so far as
to check the actual data.    When it was 'excluded', it didnt work, and when
it was 'included', it worked!! :->

> I doubt very much that mod_gzip will "mess up" any file format, while
> it may well be possible that some browser may have problems decompres-
> sing gzipped content in certain situations.
>
> So which browser did you use, and did you compare the gzipped output
> of the TIFF image (which you will find in your browser's cache) with
> the gzipped output of the same image from the previous mod_gzip release?

I used IE5 and IE6 on win98 and WinXP.

> > (if I excluded the type, the image was getting corrupted somehow)
>
> I cannot believe your statement.

The "corrupted" part, or the fact that excluding image/tiff 'broke' the page
and including it made it 'work' ?

I replaced all my rules with a simple  "mod_gzip_item_include  uri
\.p?html?$" (as per somebody's suggestion), and it seemed to solve the TIFF
problem.

The 'problem page' was a PHP page sending a Header( "Content-type:
image/tiff"); followed by the actual TIFF data, by the way.

If you'd like me to do some further tests, I'd be happy to.   I just wish
'curl' had the ability to handle mod_gzip, it would make testing a lot
easier!

> The browsers failure to handle certain content correctly may result
> from receicing different HTTP headers, which is definitely the case
> between 1.3.19.1a and 1.3.26.1a.
>
> And you should note that 1.3.19.1a is _not_ working correctly in this
> area - there is a reason for the changes we made, and you have to use
> the new configurations directives (that weren't even available in
> 1.3.19.1a) very thoroughly.

Is there a sample configuration somewhere, please?  (More info on our
particular setup below)

> > 2) Worse than this, certain PCs running IE on Win98 started to give
'page
> > has expired' when clicking on a 'Go Back' button.
>
> Which HTTP method did the previous page (the one you wanted to go
> "back" to) use, GET or POST?
> And which HTTP methods did you configure to be gzipped?

This problem still persists.  It was a POST page.  I tried with my new
one-liner 'include' configuration and it still did this.  What now?

By the way, our entire site is PHP, with very little 'static' content.  We
use a mixture of GET and POST and also use PHP to generate images on the fly
(PNG, GIF and JPG).    However, it's important that if somebody makes a
mistake on a form (which can be the result of a GET or POST) and needs  to
do a "javascript:history.back()", it must allow them to do so, showing them
the original page with all their form data still there  (unless the previous
page has been specifically designed to expire to prevent going back/multiple
views)   Some of our users are accessing via proxies and others directly.

Thanks!

Regards,
Keith