#19098 [Opn]: header("Content-type: text/plain") does not work

ID: 19098 User updated by: michael.mauch@gmx.de Reported By: michael.mauch@gmx.de Status: Open Bug Type: HTTP related Operating System: Linux -PHP Version: 4CVS-2002-08-28 +PHP Version: 4.2.3RC2 New Comment: Hmm, nobody answers, so maybe my bug description was not clear enough? Ok, so I now took php-4.2.3RC2, copied the php.ini-dist to php.ini and only enabled the default-charset: # diff -u php.ini-dist php.ini --- php.ini-dist Sat Aug 24 02:57:06 2002 +++ php.ini Tue Sep 3 20:20:47 2002 @@ -341,7 +341,7 @@ ; ; PHP's built-in default is text/html default_mimetype = "text/html" -;default_charset = "iso-8859-1" +default_charset = "iso-8859-1" ; Always populate the $HTTP_RAW_POST_DATA variable. ;always_populate_raw_post_data = On -------------------------------------------------------------------------- My test file ~/php/header_xml.php: <?php header("Content-type: text/plain"); header("Content-type:text/plain"); header("Content-type:text/plain "); header("Content-type:text/longertextsubtype"); header("Content-type: text/plain;charset=iso-8859-1"); header("Content-type: text/plain; charset=UTF-8"); echo "<hello></hello>\n"; ?> -------------------------------------------------------------------------- I configured php without any configure options. I built the CGI version, because the CLI version doesn't send any headers: # ./php -c . ~/php/header_xml.php X-Powered-By: PHP/4.2.3RC2 Content-type text/plain;charset=er_xml.php Content-type text/plain;charset= Content-type text/plain;charset= Content-type text/longertextsubtype;charset= Content-type: text/plain; charset=UTF-8 <hello></hello> -------------------------------------------------------------------------- There are lots of NUL characters in the output. You can see these if you pipe it into "less" or into "od": # ./php -c . ~/php/header_xml.php | od -taz 0000000 X - P o w e r e d - B y : sp P H >X-Powered-By: PH< 0000020 P / 4 . 2 . 3 R C 2 cr nl C o n t >P/4.2.3RC2..Cont< 0000040 e n t - t y p e nul sp t e x t / p >ent-type. text/p< 0000060 l a i n ; c h a r s e t = nul e r >lain;charset=.er< 0000100 _ x m l . p h p cr nl C o n t e n >_xml.php..Conten< 0000120 t - t y p e nul sp t e x t / p l a >t-type. text/pla< 0000140 i n ; c h a r s e t = nul nul nul nul nul >in;charset=.....< 0000160 nul nul nul nul nul cr nl C o n t e n t - t >.......Content-t< 0000200 y p e nul sp t e x t / p l a i n ; >ype. text/plain;< 0000220 c h a r s e t = nul nul nul nul nul nul nul nul >charset=........< 0000240 nul nul cr nl C o n t e n t - t y p e >....Content-type< 0000260 nul sp t e x t / l o n g e r t e x >. text/longertex< 0000300 t s u b t y p e ; c h a r s e t >tsubtype;charset< 0000320 = nul nul nul nul nul nul nul nul nul nul cr nl C o n >=............Con< 0000340 t e n t - t y p e : sp t e x t / >tent-type: text/< 0000360 p l a i n ; sp c h a r s e t = U >plain; charset=U< 0000400 T F - 8 cr nl cr nl < h e l l o > < >TF-8....<hello><< 0000420 / h e l l o > nl >/hello>.< 0000430 Please also note that Content-type is sent multiple times here, although the docs say that this does not happen if I don't pass FALSE as a second parameter to the header() function. -------------------------------------------------------------------------- So I fiddled with the source; here's the diff: --- php-4.2.3RC2/main/SAPI.c.orig Sat Jul 27 15:15:42 2002 +++ php-4.2.3RC2/main/SAPI.c Tue Sep 3 22:04:01 2002 @@ -261,11 +261,12 @@ newtype = emalloc(newlen + 1); PHP_STRLCPY(newtype, *mimetype, newlen + 1, len); strlcat(newtype, ";charset=", newlen + 1); + strlcat(newtype, charset, newlen + 1); if (*mimetype != NULL) { efree(*mimetype); } *mimetype = newtype; - return newlen; + return newlen - 1; } return 0; } @@ -454,14 +455,14 @@ } if (newlen != 0) { - newlen += sizeof("Content-type: "); + newlen += sizeof("Content-type: ") - 1; newheader = emalloc(newlen); PHP_STRLCPY(newheader, "Content-type: ", newlen, sizeof("Content-type: ")-1); strlcat(newheader, mimetype, newlen); sapi_header.header = newheader; sapi_header.header_len = newlen - 1; colon_offset = strchr(newheader, ':'); - *colon_offset = '\0'; + /* *colon_offset = '\0'; */ efree(header_line); } -------------------------------------------------------------------------- New test file with notes about the output of "./php -c . ~/php/header_xml.php", after my patch to SAPI.c has been applied: <?php // header("Content-type: text/plain"); // ok // header("Content-type:text/plain"); // output: "Content-type: text/plain;charset=iso-8859-" header("Content-type:text/plain "); // output: "Content-type: text/plain;charset=iso-8859-" // header("Content-type:text/longertextsubtype"); // output: "Content-type: text/longertextsubtype;charset=iso-8859-" // header("Content-type: text/plain;charset=iso-8859-1"); // ok // header("Content-type: text/plain; charset=UTF-8"); // ok echo "<hello></hello>\n"; ?> So this is still not optimal, but it looks a lot better than before: only when there's no space after the colon, the content-type is one character too short. And hopefully most people will use a space after the colon. Previous Comments: ------------------------------------------------------------------------ [2002-08-28 16:52:03] michael.mauch@gmx.de Ok, so you wanted me to get my hands dirty? I had a look at the code and suggest that it certainly would be a good idea to append the default charset in sapi_apply_default_charset(): --- php4-STABLE-200208281200/main/SAPI.c~ Sat Jul 27 15:17:37 2002 +++ php4-STABLE-200208281200/main/SAPI.c Wed Aug 28 22:27:20 2002 @@ -261,6 +261,7 @@ newtype = emalloc(newlen + 1); PHP_STRLCPY(newtype, *mimetype, newlen + 1, len); strlcat(newtype, ";charset=", newlen + 1); + strlcat(newtype, charset, newlen + 1); if (*mimetype != NULL) { efree(*mimetype); } But that is only a part of the problem. In sapi_add_header_ex(), I see the lines: colon_offset = strchr(newheader, ':'); *colon_offset = '\0'; These lines insert a NUL at the colon's position, but I can't see what's their purpose. I changed the bug's category from Apache related to HTTP related because it's certainly not Apache's fault, as it happens in the standalone php-cgi as well. ------------------------------------------------------------------------ [2002-08-27 14:14:38] michael.mauch@gmx.de I just found out that the php-cgi adds an empty charset, if I don't set it: # echo '<? header("Content-type: text/xml");?>' | php-cgi Status: 200 X-Powered-By: PHP/4.3.0-dev Content-type text/xml;charset= If I set the charset (even an empty one), mod_php _does_ send the Content-type header. <http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1>: | When no explicit charset parameter is provided by the | sender, media subtypes of the "text" type are defined to | have a default charset value of "ISO-8859-1" when | received via HTTP. So I think I should be allowed to set no charset. Oh: if I disable the default_charset = "iso-8859-1" in php.ini, it works just like it should, i.e. I can omit the charset and the text/plain or text/xml header is sent. ------------------------------------------------------------------------ [2002-08-25 19:15:00] michael.mauch@gmx.de With php4-STABLE-200208251500 and php4-200208251500 the header function does not set the Content-type if it is text/xml or text/plain or text/something. It works with application/xml, and it works with php-4.2.2. # HEAD http://localhost/~elmicha/php/header_xml.php 200 OK Connection: close Date: Sun, 25 Aug 2002 22:47:51 GMT Server: Apache/1.3.26 (Unix) mod_perl/1.26 PHP/4.2.2 Content-Type: text/xml Client-Date: Sun, 25 Aug 2002 22:47:51 GMT Client-Response-Num: 1 X-Powered-By: PHP/4.2.2 # HEAD http://localhost/~elmicha/php/header_xml.php 200 OK Connection: close Date: Sun, 25 Aug 2002 22:48:43 GMT Server: Apache/1.3.26 (Unix) mod_perl/1.26 PHP/4.2.3-dev Content-Type: text/html; charset=iso-8859-1 Client-Date: Sun, 25 Aug 2002 22:48:43 GMT Client-Response-Num: 1 X-Powered-By: PHP/4.2.3-dev I configured both versions only --with-apxs. The test file: <?php header("Content-type: text/xml"); echo "<hello></hello>\n"; ?> ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=19098&edit=1