Hi,
It seems to be the case but this is not documented anywhere on
php.net. Instead
http://php.net/manual/en/function.apache-request-headers.php say "You
can also get at the value of the common CGI variables by reading them
from the environment".
This comment http://www.php.net/manual/en/reserved.variables.server.php#87195
from 2008 concurs. Zend and Symphony both seems to be happy to read
even X- custom headers from SERVER without bothering with
apace_request_headers() or anything like that.
I have tried to read some SAPI code and while most of them are a bit
obscure, to the best of my understanding at least nsapi.c copies every
request header (ok, there are very few exceptions, but certainly
doesnt care about custom ones).
So... is this official enough that I can amend the
reserved.variables.server.php and the
function.apache-request-headers.php pages stating that every HTTP
header including custom ones can be found In SERVER (with the odd
security exceptions)?
Thanks
Karoly Negyesi
Hi,
It seems to be the case but this is not documented anywhere on php.net.
Instead http://php.net/manual/en/function.apache-request-headers.php say
"You can also get at the value of the common CGI variables by reading them
from the environment".
For the environment is no longer true, most multi-threaded webservers don't
have separate environments for every thread (because they can't). You should
only use $_SERVER! The global $_ENV is only safe to use in php-cli, where
you have an defined environment, but not inside webservers. Only apache
currently sets the $_ENV equally to the $_SERVER, but only when used in
prefork mode (not on windows).
This comment
http://www.php.net/manual/en/reserved.variables.server.php#87195
from 2008 concurs. Zend and Symphony both seems to be happy to read even
X- custom headers from SERVER without bothering with
apace_request_headers() or anything like that.I have tried to read some SAPI code and while most of them are a bit
obscure,
to the best of my understanding at least nsapi.c copies every request
header
(ok, there are very few exceptions, but certainly doesnt care about custom
ones).
Thanks for pointing that out. Yes, I wrote that NSAPI code and the main idea
was to reflect the HTTP_ server/env variables as Apache / CGI spec does. I
know many other SAPIs don't take care and they are broken for lots of
applications because of this. Insufficient knowledge on the APIs of those
SAPIs prevented me from fixing it there, too. Apache SAPIs are safe, because
they don't take care what variables to register, because they take what
Apache itself uses as request variables (so it simply clones the Apache
request environment). And those variables are the ones that everybody
expect. To mimic Apache's behavior (which is also defined in CGI/1.1 spec,
but "optional" only), I programmed the converter in the NSAPI SAPI that
takes all request headers and transform them to CGI variables. It should
also handle "X-" headers correctly (transformed to "HTTP_X_").
So... is this official enough that I can amend the
reserved.variables.server.php
and the function.apache-request-headers.php pages stating that every HTTP
header including custom ones can be found In SERVER (with the odd
security
exceptions)?
Theoretically that should be the case, but it isn't for most older SAPIs,
which are partly unmaintained. Also, only NSAPI and ISAPI (as far as I know)
mimic apache_request_headers, this is not part of SAPI spec. The function is
not available in every SAPI.
Uwe
Hi,
It seems to be the case but this is not documented anywhere on php.net.
Instead http://php.net/manual/en/function.apache-request-headers.php say
"You can also get at the value of the common CGI variables by reading them
from the environment".For the environment is no longer true, most multi-threaded webservers don't
have separate environments for every thread (because they can't). You should
only use $_SERVER! The global $_ENV is only safe to use in php-cli, where
OK, OK. this comment then definitely needs expansion. I didnt even
realize it was about $_ENV...
Thanks for pointing that out. Yes, I wrote that NSAPI code and the main idea
was to reflect the HTTP_ server/env variables as Apache / CGI spec does. I
know many other SAPIs don't take care and they are broken for lots of
applications because of this. Insufficient knowledge on the APIs of those
SAPIs prevented me from fixing it there, too.>
I programmed the converter in the NSAPI SAPI that
takes all request headers and transform them to CGI variables. It should
also handle "X-" headers correctly (transformed to "HTTP_X_").So... is this official enough that I can amend the
reserved.variables.server.php
and the function.apache-request-headers.php pages stating that every HTTP
header including custom ones can be found In SERVER (with the odd
security
exceptions)?Theoretically that should be the case, but it isn't for most older SAPIs,
which are partly unmaintained. Also, only NSAPI and ISAPI (as far as I know)
mimic apache_request_headers, this is not part of SAPI spec. The function is
not available in every SAPI.
So then how we should proceed with augmenting documentation esp in the
light of Zend / Symfony already relying on these headers? The CGI
specs (horribly old) say
http://tools.ietf.org/html/draft-robinson-www-interface-00
The server is not required to create environment variables for all the
headers that it receives. In particular, it may remove any headers
carrying authentication information, it may remove headers whose value
is available to the script via other variables
but it does not say further that "the rest should be created". I tried
to check for example the nginx fastcgi documentation itself which
superb terse http://wiki.nginx.org/HttpFcgiModule#fastcgi_pass_header
and doesnt say which ones are passed by default. A few rows down it
says "Determines whether the request headers are passed to the backend
as HTTP_* values. Should generally be left on." but -- really opaque.
Should the documentation say something like "It's reasonable to expect
all custom HTTP headers to be found in $_SERVER but there are a few
web servers where this is broken"?
Regards
NK
It seems to be the case but this is not documented anywhere on
php.net. Instead
http://php.net/manual/en/function.apache-request-headers.php say "You
can also get at the value of the common CGI variables by reading them
from the environment".This comment http://www.php.net/manual/en/reserved.variables.server.php#87195
from 2008 concurs. Zend and Symphony both seems to be happy to read
even X- custom headers from SERVER without bothering with
apace_request_headers() or anything like that.
The reason is that this is the only truly portable way to get the headers, and
it's easier to write a single implementation rather than multiple ones.
That said, I'd really love to have a method in PHP for retrieving request
headers, either singly or as a list. Having to parse through $_SERVER has always
felt hackish.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
hi,
On Fri, Sep 9, 2011 at 5:56 PM, Matthew Weier O'Phinney
weierophinney@php.net wrote:
It seems to be the case but this is not documented anywhere on
php.net. Instead
http://php.net/manual/en/function.apache-request-headers.php say "You
can also get at the value of the common CGI variables by reading them
from the environment".
By the way, it is maybe important to notice that this function is not
apache specific (yes, bad naming). We may alias it and create a new
one called sapi_get_request_headers or something along this line
instead.
That said, I'd really love to have a method in PHP for retrieving request
headers, either singly or as a list. Having to parse through $_SERVER has always
felt hackish.
Yes, a common function for all SAPIs make sense. Let see if we can get
the sapi_get_request/answer_headers in place for 5.4 using exising
ones.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org