Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36635
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain peytz.dk from 80.160.174.174 cause and error)
Message-ID: <47EC4050.7090601@peytz.dk>
Date: Fri, 28 Mar 2008 01:48:16 +0100
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: internals@lists.php.net
CC: ceo@l-i-e.com
References: <47EC2065.2000002@peytz.dk> <41516.98.193.37.55.1206663621.squirrel@www.l-i-e.com>
In-Reply-To: <41516.98.193.37.55.1206663621.squirrel@www.l-i-e.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set by header()
From: chsc@peytz.dk (Christian Schmidt)

Richard Lynch wrote:
> At the risk of incurring the wrath of everybody else, I'd prefer to
> see a new function like header_unset (or unset_header) to "undo" a
> header.
Currently header() supports adding, replacing and appending to existing 
headers as well as specifying the response status code, so I think that 
adding a header_unset() would break the current tradition. But I wouldn't 
object to adding a new function, though this is probably above by skills.


> If a header was not set, and then you unset it, is that an error or
> E_NOTICE or anything?
No. I think that the current header() implementation relies on the 
reasonable assumption that the user don't need to know or care what headers 
are already set. For instance, by default existing headers are silently 
overwritten.

> If you try to unset a header after the headers have gone out,
> presumably the same nifty message about WHERE the header was set would
> be output.
Yes - the same error message is generated for header('Foo') and header('Foo: 
bar').

> But then to be truly pedantic, what if you unset a header that was
> never set in the first place, after the headers have gone out?  Is
> this an error or any kind?
Yes - header() always generates an error when called after the headers have 
gone out. This is analog to the current behaviour when setting a header that 
was already set.

> Just trying to anticipate all the edge cases. :-)
I appreciate that :-) I should probably add checks for these to the phpt.


Christian