Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:42077 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61757 invoked from network); 29 Nov 2008 12:08:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Nov 2008 12:08:42 -0000 Authentication-Results: pb1.pair.com smtp.mail=thetaphi@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=thetaphi@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 80.190.230.99 as permitted sender) X-PHP-List-Original-Sender: thetaphi@php.net X-Host-Fingerprint: 80.190.230.99 www.troja.net Linux 2.5 (sometimes 2.4) (4) Received: from [80.190.230.99] ([80.190.230.99:52754] helo=mail.troja.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C0/63-30340-8C031394 for ; Sat, 29 Nov 2008 07:08:42 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.troja.net (Postfix) with ESMTP id 3A0454DD81; Sat, 29 Nov 2008 13:08:38 +0100 (CET) Received: from mail.troja.net ([127.0.0.1]) by localhost (cyca.troja.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32132-01; Sat, 29 Nov 2008 13:08:36 +0100 (CET) Received: from VEGA (port-83-236-62-11.dynamic.qsc.de [83.236.62.11]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.troja.net (Postfix) with ESMTP id D56474DD1A; Sat, 29 Nov 2008 13:08:35 +0100 (CET) To: "'Arnaud Le Blanc'" Cc: "'Lukas Kahwe Smith'" , , "'Christian Schmidt'" , "'Alex Leigh'" , "'George Wang'" References: <48FBA987.5030809@peytz.dk> <80159BEEC2384A1789C44A10C420039F@VEGA> <200811290302.31997.lbarnaud@php.net> Date: Sat, 29 Nov 2008 13:08:36 +0100 Message-ID: <1C099E3318A141808A22A1548A180BF1@VEGA> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <200811290302.31997.lbarnaud@php.net> Thread-Index: AclRxprYyjnetUWdTq6zhFo7YDuuFAAU3aJw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader() From: thetaphi@php.net ("Uwe Schindler") Hallo Arnaud, > I believe that Apache does sets its headers just before sending them, so > when > PHP deletes all headers in Apache's hashtable this does not removes > "Server", > "Date", etc. If this is not the case for NSAPI, solution a) seems good, > but > also allows to remove "Date" by setting it before ;) That is correct, you are able to remove the headers. For removing the Date header it would be enough to just use the header_remove() without setting it before. But if somebody does this, he knows what he is doing. I want to prevent PHP from doing things that the user cannot control or understand. Sun Webserver for example is able to compress output automatically and other things. So I am not sure what happens, if you remove headers. As source code of this webserver is not yet available (Sun wants to release it soon), I do not know *when* nsapi puts entries in his internal header hash table. Maybe its in protocol_start_response(), if so everything would be ok, and I can manually cleanup the complete webserver's hash table (solution b). But nsapi_response_headers from PHP called shows, that e.g. Date and Server are set *before* the request starts. In my opinion, a call to header_remove() from PHP should only remove headers set by PHP (e.g. revert to the state, before the PHP script started). > One reason for having header_handler() and send_headers() is for example > that > flush() does not sends headers explicitly, but lets the server send them > based > on what header_handler() has set. That's not correct for at least apache: php_apache_sapi_flush(void *server_context) { ... sapi_send_headers(TSRMLS_C); r->status = SG(sapi_headers).http_response_code; SG(headers_sent) = 1; if (ap_rflush(r) < 0 || r->connection->aborted) { php_handle_aborted_connection(); } } The flush function just calls sapi_send_headers so it explicitely send the headers, so my approach of do not implementing a header_handler would also correctly send the headers in this case. For NSAPI it is not even possible to send headers explicitely, you can only set them in an internal hashtable of the web server. For a typical NSAPI module the workflow is the following: Any "Service" handler from webserver's config sets headers in the internal hash table. Before it starts to write output, it may also set the response code. All this is not sent to the client immediately. The headers and everything is sent on protocol_start_response(). After that you cannot set any headers anymore and you have to write to the output stream. The PHP module calls the webserver's protocol_start_response() in sapi_send_headers(), so even when you flush, this must be called (in the current version of output buffering there is still a bug about this, which is fixed in the new version, I think). I repaired this by also implementing flush for nsapi in my new version, which calls like apache sapi_send_headers(TSRMLS_C). This fixes a very old bug for NSAPI. So in my opinion for the server it is no difference when to set the headers (immediately after the call to header()) or shortly before starting the reponse. And this is how CGI works - and this would be enough for NSAPI, too. The only thing that would not work is explicitely removing headers like "Date:", but for this use case header_handler() could only be implemented for the op SAPI_HEADER_DELETE. But with CGI this would not be possible. Uwe