DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9653>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9653 mod_rewrite example exception Summary: mod_rewrite example exception Product: Apache httpd-1.3 Version: 1.3.23 Platform: Other URL: http://httpd.apache.org/docs/misc/rewriteguide.html OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] This bug is due to an unexpected behavior in MSIE when using the referrer field deflector code to deflect unwanted links by referrer. As supplied on the Apache web site, at URL http://httpd.apache.org/docs/misc/rewriteguide.html the code looks like this: RewriteMap deflector txt:/path/to/deflector.map RewriteCond %{HTTP_REFERER} !="" RewriteCond ${deflector:%{HTTP_REFERER}} ^-$ RewriteRule ^.* %{HTTP_REFERER} [R,L] RewriteCond %{HTTP_REFERER} !="" RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L] ## deflector.map ## http://www.badguys.com/bad/index.html - http://www.badguys.com/bad/index2.html - http://www.badguys.com/bad/index3.html http://somewhere.com/ The problem occurs when the deflected and the target page reside on the same site. It is due to (IMHO) an error in MSIE, which does not dump its referrer field after the redirection. (Netscape, Lynx, Opera, etc. do not exhibit this problem.) MSIE comes in, with an offending referrer field, and is deflected to a different URL on the same site. It comes back again *but does not dump the original referrer field* and is deflected again, comes back again, is deflected again, comes back again ... and loops infinitely. I have a patch that I think might fix this, but I would like to have your opinion before installing it. It consists of splitting the second ruleset as follows: # The normal case; request URL != remapped URL RewriteCond %{HTTP_REFERER} !="" RewriteCond ^.* != deflector:%{HTTP_REFERER} RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L] # When MSIE tries to loop; request URL = remapped URL RewriteCond %{HTTP_REFERER} !="" RewriteCond ^.* deflector:%{HTTP_REFERER} RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [F] In the first (the "normal") case, the request URL is not the same as the remapped URL, and Apache issues the remapped URL with a [R]edirect. This will send it off anywhere on the web. In the second case, MSIE is trying to loop, has already been through the first ruleset, and has been redirected to the remapped URL. Therefore, both original and remapped pages reside on this server. Apache still issues the remapped URL, but as [F]inal without a redirect. I would be glad to have your opinion on this. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
