#16458 [Com]: header() does not replace headers but always produces duplicates
| From: | walkibe at msn dot com | Date: | Thu, 21 Nov 2002 03:37:36 +0000 |
| Subject: | #16458 [Com]: header() does not replace headers but always produces duplicates | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-25373@lists.php.net to get a copy of this message | ||
ID: 16458
Comment by: walkibe@msn.com
Reported By: ernest@vogelsinger.at
Status: Closed
Bug Type: HTTP related
Operating System: Win32 (XP)
PHP Version: 4.1.1
New Comment:
found the solution here :
http://www.faqts.com/knowledge_base/view.phtml/aid/19413/fid/59
the trick is NOT TO HAVE ANY SPACE in between the <?php ?> sets, before
the header() command. cheers! =)
Previous Comments:
------------------------------------------------------------------------
[2002-11-19 01:57:25] bahtiyar_s@yahoo.com
yeah...
I have a same problem as systemshock87!!!!!!!!
What happening?
------------------------------------------------------------------------
[2002-10-19 15:58:58] systemshock87@yahoo.com
<?php
$user = crypt($usuario);
$password = md5($clave);
if (($usuario == "OSN") && ($clave == "misvr"))
{
header ("Location:
http://24.232.112.10/<b>crypt(guestprivado3.php)</b>?Usuario=$userClave=$password");
}
else
{
header ("Location:
http://24.232.112.10/guestprivado.php?Mensaje=osndiceqtevaairmal");
exit;
}
?>
When i load this in my page it appears an error:
Warning: Cannot add header information - headers already sent by
(output started at c:/program files/apache
group/apache/htdocs/guestprivado2.php:11) in c:/program files/apache
group/apache/htdocs/guestprivado2.php on line 17
what's the problem?
------------------------------------------------------------------------
[2002-06-18 06:17:07] sander@php.net
I've commited the patch to CVS, thanks for your help.
------------------------------------------------------------------------
[2002-05-14 16:33:41] msisolak@yahoo.com
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) {
------------------------------------------------------------------------
[2002-04-05 15:23:34] ernest@vogelsinger.at
Thanks for the follow-up, and thanks for reopening... Sorry for the
incorrect classification.
------------------------------------------------------------------------
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