Thanks for the response, William --
On 02/15/2013 11:49 AM, William A. Rowe Jr. wrote:
> On Fri, 15 Feb 2013 10:38:40 -0500
> Mark Stosberg <[email protected]> wrote:
>
>>
>> I'd like feedback on whether the following behavior is a bug, or
>> intentionally inconsistent.
>>
>> I was looking at the environment variables generated by this case:
>>
>> Browser URL: /file%3Fa=b?c=d
>>
>> 'QUERY_STRING' => 'a=b&c=d',
>> 'SCRIPT_URL' => '/file?a=b',
>> 'SCRIPT_URI' => 'http://example.com/file?a=b',
>> 'REQUEST_URI' => '/file%3Fa=b?c=d',
>>
>> The "%3F" is an encoded question mark.
>>
>> Note that SCRIPT_URI and SCRIPT_URL treat the query string as starting
>> after the unencoded question mark, while 'QUERY_STRING' variables
>> treats the query string as started at the encoded question mark.
>>
>> >From my reading of RFC 3875 (CGI), my understanding is that only an
>> unencoded question mark should mark the beginning the query string.
>> Thus, it appears that the QUERY_STRING variable being returned here is
>> incorrect. Is it?
>
> I agree with your interpretation. However, we pick apart QUERY_STRING
> long after %-escapes are transcoded. That could be the issue.
>
>> This data was generated with Apache/2.2.14.
>
> Was mod_rewrite involved in any way with processing this request?
Yes, a standard dispatching recipe was in play:
# If an actual file or directory is requested, serve directly
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# Otherwise, pass everything through to the dispatcher
RewriteRule ^home/project/www/(.*)$ /cgi-bin/dispatch.cgi/$1
[last,qsappend]
Should I open a bug report? (If someone could check quickly against
HEAD, that could be helpful as well).
Mark
