On 02/10/2017 07:48 AM, Jim Jagielski wrote:
But since these are envvars, does anyone really use them
that way?
Hmm... that's actually kind of a tricky question to answer.
CGI/1.1 says that an empty value and a missing value are indistinguishable:
This specification does not distinguish between zero-length (NULL)
values and missing values. For example, a script cannot distinguish
between the two requests http://host/script and http: //host/script?
as in both cases the QUERY_STRING meta-variable would be NULL.
That's kind of unfortunate, since there are at least two HTTP headers
(Host and Accept-Encoding are the ones I found) where an empty value is
not semantically equivalent to a missing one. Maybe there are some shell
environments that can't tell the difference between an empty variable
and a nonexistent one, so CGI had to follow suit?
It looks like (by inspection, haven't tested) PHP allows developers to
distinguish between the two with getenv(), and PHP-FPM also
distinguishes between missing and empty values when applying its fixups.
(For example, an empty REDIRECT_URL will trigger the "old Apache"
fixups, but they won't run if REDIRECT_URL is completely missing.) And
of course, there are other shells and scripting environments that let
you distinguish between the two.
I think that if we want this directive to be the "last resort" for weird
FCGI compatibility issues, we need to allow both empty *and* unset
variables.
We don't want people to think that one can "unset"
an envvar by casting it to "", which some people may think.
I guess it's more a docco issue that anything :)
+1 to both points. I'll keep thinking about ways to document; Eric
pointed out we need good examples here too.
--Jacob
