durusmail: quixote-users: Inconsistency between mod_scgi behavior and published scgi protocol?
Inconsistency between mod_scgi behavior and published scgi protocol?
2008-06-23
Inconsistency between mod_scgi behavior and published scgi protocol?
Inconsistency between mod_scgi behavior and published scgi protocol?
2008-06-23
2008-06-24
Inconsistency between mod_scgi behavior and published scgi protocol?
Mike Orr
2008-06-24
On Mon, Jun 23, 2008 at 4:18 PM, Al Pacifico
 wrote:
>
>
> On Mon, Jun 23, 2008 at 3:14 PM, Neil Schemenauer  wrote:
>>
>> Al Pacifico  wrote:
>> > I've been writing a SCGI server program in C (for use as a web service)
>> > and
>> > while testing, I came across the following when fetching the URL '
>> > http://localhost/dynamic': mod_scgi passes a SCGI header with name
>> > QUERY_STRING and an empty value (i.e. name NUL  NUL).
>>
>> I'm not sure what is specified by the HTTP RFC but the vast majority
>> of web sites, AFAIK, treat an emtpy query string the same as no
>> query string.  The behavior of mod_scgi is the same as mod_cgi in
>> regards to QUERY_STRING.  If you really want to distinguish between
>> no query string and an empty query string, I guess you could look
>
>
> You raise an interesting point! Previously, I thought empty query string and
> no query string would be synonymous, that the query string is just the part
> of the URL following '?'. Fetching 'http://localhost/dynamic?', mod_scgi
> sends the same SCGI request as when fetching 'http://localhost/dynamic' as I
> would have expected.

All URLs have an implicit query string.  Users are allowed to put "?"
at the end of every URL if they wish, including POST requests.
Applications should extract the value as ``environ.get("QUERY_STRING",
"")`` because the distinction between "" and missing is undefined,
just like the distinction between "?name=" and "?".  Maybe the browser
drops empty parameters, maybe the server adds an empty QUERY_STRING,
or maybe it doesn't.  Given that mod_scgi has a precedent of adding
QUERY_STRING, there's no reason to change it.

--
Mike Orr 
reply