https://issues.apache.org/bugzilla/show_bug.cgi?id=50957

--- Comment #8 from Brad Plies <bpl...@bulliondirect.com> 2011-03-23 01:01:58 
EDT ---
(In reply to comment #7)
> (In reply to comment #0)
> > Tomcat: 7.0.8
> > OS:  Windows 2008 Server (x64)
> > 
> > Compression enabled on both HTTP and HTTPS connectors.
> > 
> > (...)
> > Once the behavior was detected, I used WebScarab as a proxy to monitor the
> > entire Browser <--> Tomcat conversation.  I was able to confirm a scenario 
> > like
> > the following:
> > --------
> > ImageA.gif
> > ImageB.gif
> > 
> > Each has different file size, ETAG, etc.
> > 
> > GET ImageB.gif returned ImageA.gif (with ImageA.gif's ETAG, headers, binary
> > content, and content size)
> > -------
> 
> Do you know/remember whether GET ImageA.gif returned ImageA.gif as well,
> whether either of them was compressed, and whether the requests were from the
> same client? Do you know the size of those files?
> 
> (gif files are not in AbstractHttp11Processor .compressableMimeTypes by
> default, so I think that they should have not be compressed)
> 
> What were your compression settings? Just compression="on"?

I recall a case where ImageA and ImageB were swapped and because the images
were very different dimensions, the page looked really awkward.  I'm fairly
sure I had also witnessed ImageA as both ImageA and ImageB.  Yes all
observations were performed as the same client.

Even though compression was enabled on the connectors the image MIME types are
not included (as you suspected).

Other scenarios occurred where compressable text resources (.js, .css, .xml,
.html) were also served with the incorrect response:  HTML -> IMG, HTML -> JS,
HTML -> CSS, and so on.

I had only mentioned compression="on" just in case it happens to be a
contributory factory.  I would not suspect that it would be related...

I have not and will not have the opportunity to try BIO with compression="off"

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to