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
