|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #12884 Content-Encoding: PHP sends incorrect Content-Length when gzip is used on a re
Submitted: 2001-08-21 14:43 UTC Modified: 2001-11-13 07:37 UTC
From: yngve at opera dot com Assigned:
Status: Closed Package: HTTP related
PHP Version: 4.0.6 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
45 + 49 = ?
Subscribe to this entry?

 [2001-08-21 14:43 UTC] yngve at opera dot com
I am a developer at Opera Software, in charge of the HTTP protocol support in the Opera Browser. 

We recently received a report of a problem on . 

When I investigating this report I found that the problem was caused by an incorrect Content-Length header in combination with a Content-Encoding: gzip header. 

The length indicated by the Content-Length is actually the length of the original, uncompressed body, but it should have been the length of the compressed body (References: RFC 2616 section 4.4, 7.2 and 14.13). 

The mismatch between the indicated Content-Length and the actual amount of received data causes Opera to do repeated load attempts (This is a fallback primarily used to handle problems with pipelining and persistent connections).

This mismatch also destroys the pipelining and persistent connection capabilities in HTTP 1.1. I actually observed one  example where the HTTP header of the next (pipelined) request was received and added to the content of the gzipped file.

Investigating the PHP sourcecode I found that the code to add the Content-Length header was disabled.

I am still investigating workarounds that will handle this problem, but unless it is removed on the server side it will affect all Opera versions after v4.0, as well as any other HTTP useragent that uses HTTP pipelining and therefore have to trust the Content-Length headers

To fix this problem you will have to replace the Content-Length header with a proper header, or remove it. An alternative (for HTTP 1.1 clients) is to use the chunked transfer encoding.

This is an example session: 

GET / HTTP/1.1
User-Agent Mozilla/3.0 (Windows 2000; U) Opera 5.50  [en]
Accept text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
Accept-Language en
Accept-Charset iso-8859-1,*,utf-8
Accept-Encoding deflate, gzip, x-gzip, identity, *;q=0
Connection Keep-Alive, TE
TE deflate, gzip, chunked, identity, trailers 

(Cookie header removed)

with the following response from the server 

HTTP/1.1 200 OK
Date Mon, 13 Aug 2001 175609 GMT
Server Apache/1.3.19 (Unix)  (Red-Hat/Linux) PHP/4.0.6 mod_perl/1.24_01
X-Powered-By PHP/4.0.6
Content-Length 60928
Content-Encoding gzip
Vary Accept-Encoding
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Type text/html 

followed by an entity body of 9562 bytes of gzipped data. 

The gzipped data expands to 60928 bytes of data, as specified in the content length header.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2001-08-22 01:25 UTC]
this should be fixed in CVS. Could you please try
the latest snapshot to verify:


 [2001-08-23 22:33 UTC]
I don't think that it's fixed the way yngve expects: ob_get_length() is still not fixed as far as I know. 

However, a work-around involving sending a Content-Length header form the ob_gzhandler, has been committed to CVS.

See also discussion at,2,8

 [2001-10-02 18:56 UTC]
So is this problem still valid or not?

 [2001-11-09 14:48 UTC]
No feedback. Reopening.
 [2001-11-13 07:37 UTC]
I talked to Yngve and he has confirmed that it works fine with the latest development-version.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Jun 13 20:01:31 2024 UTC