php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #16198 appending of 5 bytes to HTTP header off any php page
Submitted: 2002-03-20 23:29 UTC Modified: 2002-03-21 11:29 UTC
From: brander at mnemonic dot net Assigned:
Status: Not a bug Package: Output Control
PHP Version: 4.1.2 OS: linux (rh 7.1/7.2)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: brander at mnemonic dot net
New email:
PHP Version: OS:

 

 [2002-03-20 23:29 UTC] brander at mnemonic dot net 
ANY PHP SCRIPT WILL EXHIBIT THIS PROBLEM!

our server info is at http://www.ice.org/info.php

we saw this bug in 4.0.6, upgraded to 4.1.2 and it is still there.  mysql support is built in.  looking at the www.zend.com problem it appears your dev version of 4.1.3 also has this bug.

i noticed that www.php.net does not exhibit this problem.
php.net appears to be a 4.2.0 dev version from this http header:

Server: Apache/1.3.20 (Unix) DAV/0.9.18-dev PHP/4.2.0-dev
X-Powered-By: PHP/4.2.0-dev

sites that do exhibit this problem are www.php.com (3 bytes).. www.zend.com exhibits this problem but with _4 bytes_ + crlf .. breaks the 3 byte + crlf thought i had. and many many more servers on the web.

when working on ice.org's website i noticed 5 bytes being appending the the HTTP header, these bytes are constant per page but not between them, at the end of the header you expect (in hex):

0D 0A 0D 0A

and right after you'd expect the content, this is incorrect in this bug, you see three bytes and then another crlf pair:

OD OA OD OA 64 63 34 OD OA

it appears to always be 3 bytes and a crlf pair.

these extra bytes are bogus and to properly utilize the content type they need to be removed.  it appears IE ignores these bytes, perhaps the network parser just looks for a final OD OA and thus no one using IE as a browser will complain about bogus content being served.

-brander lien
brander@mnemonic.net

example network dump from www.zend.com / the bogus bytes would be represented via 84d2.. right before the html content:

HTTP/1.1 2OK..Date: Thu, 21 Mar 2002 04:18:41 GMT..Server: Apache/1.3.20 (Unix) PHP/4.1.3-dev mod_macro 32 /1.1.1 mod_ssl/2.8.4 OpenSSL/0.9.6..X-Powered-By: PHP/4.1.3-dev..Set-Cookie: Zend_Session_DB=bd600c5ce909393058282a6b0936a3ad; expires=Thu, 21-Mar-2002 09:18:41 GMT; path=/..Expires: Thu, 19 Nov 1981 08:52:00 GMT..Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0..Pragma: no-cache..Set-Cookie: Zend_In=deleted; expires=Wed, 21-Mar-2001 04:18:40 GMT; path=74 /..Keep-Alive: timeout=5, max=1000..Connection: Keep-Alive..Transfer-Encoding: chunked..Content-Type: text/html....84d2..<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

configure line:
 './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-apxs=/usr/sbin/apxs' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-gettext' '--with-jpeg-dir=/usr' '--with-mm' '--with-openssl' '--with-png' '--with-regex=system' '--with-ttf' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-yp' '--enable-wddx' '--without-mysql' '--without-unixODBC' '--without-oracle' '--without-oci8' '--with-pspell' '--with-xml'

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-03-21 02:40 UTC] derick@php.net 
Can you please check if php-4.2.0rc1 (downloadable from www.php.net/~derick) inhibits the same bahavior?

Derick
 [2002-03-21 05:01 UTC] hholzgra@php.net 
you have just discovered HTTP/1.1 chunked content encoding

please (re-)read RFC2616 , sec 3.6.1
 [2002-03-21 05:01 UTC] hholzgra@php.net 
forgot to bogusify ...
 [2002-03-21 10:43 UTC] brander at mnemonic dot net 
wow, look at that =)  strange that some of your versions don't "support" that and others do.  my apologies for wasting your time on this one, I should have noticed that "Transfer-Encoding: chunked" header and thought to look into it.  I guess i wasn't expecting it since this was the first time I saw anything use it.

so why doesn't 4.2.0-dev exhibit this behavior, different code tree?  should it be doing the same?
 [2002-03-21 11:23 UTC] hholzgra@php.net 
Transport-Encoding: is done by the webserver
and depends on the HTTP version that server
and client use, PHP is not involved in the 
decision, so please don't blame it
 [2002-03-21 11:29 UTC] brander at mnemonic dot net 
no blames intended, apologies to you if it seemed that way.  i was just curious what dictated the use of chunked, since i am using the same browser to hit all the sites that I've seen or not seen this on.

EOF
 
PHP Copyright © 2001-2023 The PHP Group
All rights reserved. 		Last updated: Sun Jun 04 21:03:39 2023 UTC