[ic] discussion of patch for IC compatibility with NS 7
Mike Heins
interchange-users@icdevgroup.org
Sat Sep 28 11:38:00 2002
Quoting Jeff Dafoe (jeff@badtz-maru.com):
> > Please give me an actual example of a URL, what Mozilla gives,
> > which HTTP server it is running on, which link program, etc.
>
> This issue occurs with Apache 1.3.26 under Linux using mod_interchange
> 1.22 on an Interchange 4.8.6 server. Using Netscape 7, which is Mozilla
> 1.0, on Windows as a user agent. When the user clicks on one the of the
> pages of the more list, the user agent sends a request: for the following:
>
>
> /sophee/scan/MM=7bd44736752c7c1017f5a8858c7b8a9f%3A16%3A31%3A16?mv_session_i
> d=wdtPzDU8&mv_pc=3001&mv_more_ip=1&mv_nextpage=results
>
> This results in a blank page display and the following error in the
> catalog's error log:
>
> 65.80.15.252 wdtPzDU8:65.80.15.252 - [26/September/2002:22:24:15 -0400]
> sophee /sophee/scan/MM=7bd44736752c7c1017f5a8858c7b8a9f%3A16%3A31%3A16
> search error: Object saved wrong in
> /home/sophee/catalogs/sophee/tmp/w/wdtPzDU8.7bd44736752c7c1017f5a8858c7b8a9f
> %3A16%3A31%3A16 for search ID
> wdtPzDU8.7bd44736752c7c1017f5a8858c7b8a9f%3A16%3A31%3A16.
>
> I believe, from reading previous discussions on the issue in the
> archives and through my own experimentation, that the issue is that the
> colons in the MM value are urlencoded. IE and the older NS versions do not
> encode the colon on the PC (although NS on the Mac does). Looking at the
> message archive, I theorize that most, if not all, versions of Mozilla may
> do this. Following the RFC, the user agent is actually free to encode any
> octet, so it can't really be considered a bug. In examining the Server.pm
> file it looks like the query_string's parameters are being urldecoded in
> parse_post, which seems correct. However, interchange also uses some of the
> path_info for parameters as well (as is the case with scan's MM) but
> path_info is never urldecoded. This is what I think is incorrect. To
> mitigate, I added:
>
> $CGI::path_info =~ s/%([A-Fa-f0-9]{2})/chr(hex($1))/eg;
>
> to the bottom of map_cgi . This does allow NS7 to operate although I am
> not certain it does not introduce any additional issues that might result if
> there is some sort of urlencoding "deficiency" when interchange builds urls
> for pages, ie, if urlencoding is not performed somewhere and %xx is an
> actual expected parameter.
>
> Thanks for your time,
And for yours making this excellent description which allows me to understand
what people are saying. It is as I thought, and there is nothing for
Interchange to do about this.
This is normally handled in the HTTP server -- when we get path_info, it
is supposed to be decoded, I believe. As in fact I know it is, normally:
<a href="/cgi-bin/found/process/%25%3a%3f?mv_action=return&mv_nextpage=dump">Try this</A>
If you have a dump.html page in your MV server with <xmp>[dump]</XMP>
in it, you will see:
Full client host name:
Full client IP address: 10.10.10.6
Query string was: mv_action=return&mv_nextpage=dump
browser: Lynx/2.8.4rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.6b
last_url: /process/%:?
0 items in main cart.
###### ENVIRONMENT #####
{
'SCRIPT_NAME' => '/cgi-bin/found',
'SERVER_NAME' => 'sam.heins.net',
'PATH_INFO' => '/process/%:?',
[snip]
This tells me that it is a bug in mod_interchange or Apache. If we
did as you suggest, the string that I gave before (%253a) would be
improperly translated to colon.
I just checked it against Apache 1.3.23 and the latest mod_interchange
and found no problem:
Full client host name:
Full client IP address: 10.10.10.6
Query string was: mv_action=return&mv_nextpage=dump
browser: Lynx/2.8.4rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.6b
last_url: /process/%:?
0 items in main cart.
###### ENVIRONMENT #####
{
'SCRIPT_NAME' => '/site',
'SERVER_NAME' => 'sam.heins.net',
'PATH_INFO' => '/process/%:?',
So the bug is not in mod_interchange nor is it in Interchange. It
appears to be in Apache 1.3.26, or in Mozilla for double-encoding
the string.
--
Mike Heins
Perusion -- Expert Interchange Consulting http://www.perusion.com/
phone +1.513.523.7621 <mike@perusion.com>
Software axiom: Lack of speed kills.