RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()

I implemented and tested now version a), works fine! header_remove() now only removes headers set/modified by PHP. I tested the case to remove *all* headers by cleaning the server's header hash table, but this breaks server hard: Best example: Removing the "Transfer-encoding: chunked" header, the server inserts at the beginning of the request before PHP is executed, is not restored on protocol_start_response, but the server still sends chunked data -> the browser will not understand it. Solutions c), as I told before would also be good, but then you would not see PHP's headers in get_response_headers(). And code is not much shorter or simplier. ----- Uwe Schindler thetaphi@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Uwe Schindler [mailto:thetaphi@php.net] > Sent: Saturday, November 29, 2008 1:09 PM > To: 'Arnaud Le Blanc' > Cc: 'Lukas Kahwe Smith'; internals@lists.php.net; 'Christian Schmidt'; > 'Alex Leigh'; 'George Wang' > Subject: RE: [PHP-DEV] [PATCH] Allow unsetting headers previously set > usingheader() > > 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 > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php