ID: 16458
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: HTTP related
Operating System: Win32 (XP)
PHP Version: 4.1.1
New Comment:
Suggested fix submitted to dev list:
Bug #16458 reports that the header() command does not correctly use the
replace parameter (i.e., a header of the same name should be replaced
if this parameter is true). The problem is that the standard
sapi_add_header_ex function assumes that the sapi being used with deal
with any header replacements. For Apache that works fine as the Apache
sapi correctly used the replace parameter. The IIS sapi, however,
defaults to the standard funtionality in sapi_add_header_ex (as does
the CGI). The default handler just calls zend_llist_add_element to add
the header to the header list thus appending even if replace was
requested.
Attached is a suggested patch that first removes the header from the
list if it already exists if we are in replace mode. This works for
the Win32 IIS and CGI builds, but I don't have a way to test any
possible interaction this might have with the other sapi modules (or
under GCC).
--- sapi.c Tue May 14 16:11:31 2002
+++ sapi.c.new Tue May 14 16:29:23 2002
@@ -385,6 +385,11 @@
return code;
}
+static int sapi_find_matching_header(void *element1, void *element2)
+{
+ return strnicmp(((sapi_header_struct*)element1)->header,
(char*)element2, strlen((char*)element2)) == 0;
+}
+
/* This function expects a *duplicated* string, that was previously
emalloc()'d.
* Pointers sent to this functions will be automatically freed by the
framework.
*/
@@ -551,6 +556,19 @@
zend_llist_clean(&SG(sapi_headers).headers);
}
if (retval & SAPI_HEADER_ADD) {
+ /* in replace mode first remove the header if it already exists in
the headers llist */
+ if (replace) {
+ colon_offset = strchr(header_line, ':');
+ if (colon_offset) {
+ char sav;
+ colon_offset++;
+ sav = *colon_offset;
+ *colon_offset = 0;
+ zend_llist_del_element(&SG(sapi_headers).headers,
+header_line,
(int(*)(void*, void*))sapi_find_matching_header);
+ *colon_offset = sav;
+ }
+ }
+
zend_llist_add_element(&SG(sapi_headers).headers, (void *)
&sapi_header);
}
if (free_header) {
Previous Comments:
------------------------------------------------------------------------
[2002-04-05 15:23:34] [EMAIL PROTECTED]
Thanks for the follow-up, and thanks for reopening... Sorry for the
incorrect classification.
------------------------------------------------------------------------
[2002-04-05 15:08:51] [EMAIL PROTECTED]
Note: the replace parameter seems to be completely ignored; it replaces
the headers as an Apache module anyway, and it refuses to replace them
as CGI.
------------------------------------------------------------------------
[2002-04-05 15:06:37] [EMAIL PROTECTED]
OK, to be more verbose:
I experienced the same problem with the CGI version of PHP 4.1.2 on
Linux, but the problem didn't show up with the Apache-module of
4.3.0-dev.
I've just recompiled 4.2.0RC2 as CGI, and the bug reappeared.
So it's a CGI only bug. Reopened (and reclassifed).
Anyway, PHP 4.2.0 is scheduled for release at the 22th of April.
------------------------------------------------------------------------
[2002-04-05 14:13:22] [EMAIL PROTECTED]
Just checked the 4.2.0-RC2 and found the identical behaviour from the
command line (with PHP.EXE, no headers are displayed, so I used
PHP-CGI.exe).
------------------------------------------------------------------------
[2002-04-05 13:50:47] [EMAIL PROTECTED]
If this bug doesn't exist with the Linux/Apache module it is ok for me
- if it is this doesn't "work for me" at all... Reason: my application
framework uses output buffering so headers don't get sent until
ob_end_flush() is called. Especially any caching headers are /modified/
depending on results of the application computations.
So it is not quite "easy" to "code around this 'bug'" - the caching
headers are pre-set as soon as a session is established, and are not
modifyable afterwards. In fact this 'bug' disables me to sent pages
being cacheable, increasing server load and network traffic. And, with
NetScape 4.x clients, pages resulting from posted forms cannot be
resized (NS 4.x wants to resend the POST data to redraw the
non-cacheable data).
Any idea when 4.2.0 will be out as production version?
On our production servers I cannot use an RC or -dev version, I need
the stable build, so I have 4.1.2/RedHat Linux running there (cannot
crosscheck the problem on the server just now).
------------------------------------------------------------------------
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/16458
--
Edit this bug report at http://bugs.php.net/?id=16458&edit=1
