[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.