637657 - Content Encoding Error on www.modelovysvet.cz

Status: RESOLVED WORKSFORME

(Core :: Networking: HTTP, defect)

Description

[Matěj Cepl]

Attachment: screenshot of the screen with the error message

Both with Fedora firefox-3.6.13-2.el5 and the upstream binary (Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101206 Red Hat/3.6-2.el5 Firefox/3.6.13), I get Content-Encoding error when entering http://www.modelovysvet.cz

Works just fine with Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12).

Comment 1

[Boris Zbarsky [:bzbarsky]]

In a build showing the problem, can you create an HTTP log per https://developer.mozilla.org/en/HTTP_Logging ?

Comment 2

[Matěj Cepl]

Attachment: log of the reproduction

Comment 3

[Boris Zbarsky [:bzbarsky]]

Here's the relevant part of that log:
 
  Cached data size does not match the Content-Length header
  [content-length=2859 size=2376]

and then we make this request (irrelevant headers snipped):


  http request [
    GET / HTTP/1.1
    Host: www.modelovysvet.cz
    Accept-Encoding: gzip,deflate
    Range: bytes=2376-
    If-Range: "49dab7-2da2-4d63aa66"
  ]

and the server response:

  http response [
    HTTP/1.1 206 Partial Content
    Vary: Accept-Encoding
    Etag: "49dab7-2da2-4d63aa66"
    Accept-Ranges: bytes
    Content-Length: 9306
    Content-Range: bytes 2376-11681/11682
    Keep-Alive: timeout=3, max=100
    Connection: Keep-Alive
    Content-Type: text/html
  ]

which is bogus.  What we have cached are the first 2376 bytes of the _gzipped_ 200 response the server sent us at some point.  When we request the rest of the bytes, the server responds with a response that is NOT gzipped (not the totally different Content-Type, etc).  There's no way to match up the data we already had with the data the server is handing us now.

You can probably clear your cache if you want to work around the problem for now by getting rid of the partial-content cache entry, but this server just needs to be fixed....

I suppose we could doom our cache entry in this situation, so at least reloading would do the right thing.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> not the totally different Content-Type, etc

I meant "note the totally different Content-Length".

Again, claiming that this resource has the same ETag as the original resource the server sent us is just broken....

Comment 5

[Honza Bambas (:mayhemer)]

(In reply to comment #3)
> Here's the relevant part of that log:
> 
>   Cached data size does not match the Content-Length header
>   [content-length=2859 size=2376]

Isn't this content-length of the gzipped data?

> and the server response:
>     Content-Length: 9306
>     Content-Range: bytes 2376-11681/11682

...and this the length of NOT gzipped (plain) data?


I'd say this is a dup of bug 613159 or even bug 612135, landed on 2011-02-04.  We do not deploy a range request for a cached entry that has a content encoding.


Matej, in the description you claim that this works with Fx4b12.  So you are confirming this is actually fixed?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Isn't this content-length of the gzipped data?

Yes.

> ...and this the length of NOT gzipped (plain) data?

Yes.

I forgot that we changed things to just work around this breakage....

Comment 7

[Matěj Cepl]

(In reply to comment #5)
> Matej, in the description you claim that this works with Fx4b12.  So you are
> confirming this is actually fixed?

well, yes on FF4b12. However,

a) FF3.6.* is still supported product, isn't it?
b) I don't know if some user-agent/capabilities sniffing is not involved (maybe not updated to FF4 and its new U-A string?).

Check the website for yourself to see it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> a) FF3.6.* is still supported product, isn't it?

Yes, but we don't make invasive web-compat behavior changes there unless they're fixing security or stability bugs.