ID: 24083
User updated by: yngve at opera dot com
Reported By: yngve at opera dot com
Status: Bogus
Bug Type: Zlib Related
PHP Version: 4.3.1
New Comment:
The PHP module may not set any Content-Length headers itself, but it is
allowing the scripts to set them. I do not have any real problem with
that (CGI scripts also do this). Any problems caused by incorrect
content-length headers would be local to that particular script.
The problem is that when the PHP module apply *internal* postprocessing
to the data generated by the script, such as is done by the
ob_gzhandler (and possibly by other output handlers in PHP) the
*length* of the output changes, and if the script sent an explicit
content-length header, that particular header is no longer valid and
should have been removed by your outputhandler.
PHP is producing content (header + data) that is inteded to be
transmitted over a HTTP channel, and is therefore IMO affected by the
RFC 2616 requirements.
When PHP (or any other serverside module or proxy) modifies HTTP data
(apart from the original construction of header + data when processing
the script) it becomes PHP's responsibility (to the best of its
ability) to ensure that the headers it forwards are still consistent
with the new version of the data. That includes (in this case) not just
adding a "Content-Encoding: gzip" header, but removing or editing the
"Content-Length" header as well.
This is not really a question of the script setting a correct or
incorrect header, but of the PHP postprocessing step allowing an
obviously incorrect header value to be passed on to the client.
Because, as far as I can see, this is a general problem with PHP, and
because PHP is used by a large number of sites, this Content-Length
header problem is causing problems for many of Opera's users. I
therefore have to take steps to reduce the actual visible signs of the
problem (repeated "flashing" downloads of the page due to our HTTP
pipeline error recovery heuristics, or "Connection closed by server"
errors).
In this case, as it does not appear you are willing to prevent the
problem, the only two options open to me are to either disable
"Accept-Encoding", or to not completely trust the Content-Length
headers when communicating with servers that can be identified as using
PHP. The first may increase network loads, unless the server uses
Transfer-Encoding, the second has the advantages that compression may
still be used, and if the problem is fixed later, Opera can still use
persistent connections to the server (which is anyway not possible as
long as incorrect Content-Length headers are sent by the server).
As I already had code in place for the second option, due to similar
problems with PHP 4.0.4-4.0.6, I chose to expand that code to cover all
PHP versions. What this code do is to not send any new request to the
server until Opera have received all the bytes of data it expects based
on the content-length, even if the server claims to be a pipeline
capable server, and if it does not recieve all the bytes before the
connection closes assume that it really did get all the data, and not
to "make a fuss" about the missing data.
I do not like adding special handling of specific serversoftware (broad
definition) but in a number of cases it has been necessary in order to
handle known problems of a general nature with that particular
serversoftware that cannot be handled properly, or at all, by
heuristics. As soon as the cause of the problem is removed I remove, or
limit the scope of the special handling.
Previous Comments:
------------------------------------------------------------------------
[2003-06-12 12:15:35] [EMAIL PROTECTED]
Erm? 1st: it has nothing to do with "the PHP server", as PHP is not a
server, but rather a module to a webserver. 2nd: we do not set any
Content-Length header ourselves. 3rd: PHP is a flexiable scripting
language allowed users to set (override) Content-Length headers
themselves whereever they think it's necessary even although that might
be wrong. AFAIK RFC 2606 is an HTTP RFC, PHP does NOT implement HTTP,
but rather makes use of it it. So, what is your problem with PHP?
------------------------------------------------------------------------
[2003-06-12 10:43:06] yngve at opera dot com
As you are, apparently, not willing to enforce correct Content-Length
headers I see no option but to make sure that Opera does not trust
Content-Length headers served by PHP powered servers.
This will be effective as of v7.20.
Please inform me when you start enforcing RFC 2616 sec. 4.4 and only
sends/passes through valid Content-Length headers, so that I can
remove/limit this special handling of PHP servers.
------------------------------------------------------------------------
[2003-06-12 08:20:23] [EMAIL PROTECTED]
There's not much we can do if a script sets a wrong content-length
header. Not PHP bug.
------------------------------------------------------------------------
[2003-06-09 22:09:11] [EMAIL PROTECTED]
We still need a short script to reproduce this,
anything I've tried works just fine..
------------------------------------------------------------------------
[2003-06-09 09:01:37] yngve at opera dot com
I do not know if this is present in 4.3.2 as I am not using PHP myself,
but I do know that the problem is present on servers using PHP 4.2.2
and 4.3.1, and your changelog does not indicate many changes related to
compression, and none that I can see are related to this problem.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/24083
--
Edit this bug report at http://bugs.php.net/?id=24083&edit=1
