Redirect keeps appending slashes

ISP redirect fails on external link by redirecting to self

[dspaude]

hello,

I have been trying to make use of mod_alias and mod_rewrite via .htaccess on my ISP's web server (Apache 1.3.27). However, all attempts to redirect fail to route to the external address given and instead route back to the referer page with a trailing slash added for each redirect until the web browser detects this endless recursion and stops the redirecting.

Some things I have noticed on the server (without using .htaccess) is that the web server will redirect http://name.domain/directory to http://name.domain/directory/ (adds trailing slash). I am assuming that somehow this is affecting me. However, if I attempt to redirect to an external address it won't go there.

For example, in the browser go to http://www.example.com/~dlspaude/test/index.html and you will be greeted with endless redirects:
http://www.example.com/~dlspaude/test/index.html/
http://www.example.com/~dlspaude/test/index.html//
http://www.example.com/~dlspaude/test/index.html///
and so on.

The .htaccess file in http://www.example.com/~dlspaude/test/ has one line:
RedirectMatch permanent .* http://www.quux-foo.com

In Firefox using Live HTTP headers the Location information shows the original address requested plus one extra slash added for each successive request. I would think that since an external link was named that it would not recurse on the server and instead should route to the external link.

All of this works as expected on my Mac OS X Apache installation (basically default config), but on this ISP's web server I get this endless local recursion.

I've also tried using mod_rewrite and get the same results. There must be something on the server side that is preventing the external redirect, but what?

Any help is appreciated,
Darrik

[edited by: jdMorgan at 3:41 pm (utc) on July 22, 2006]
[edit reason]
[1][edit reason] Example.com [/edit] [/edit][/1]

[dspaude]

My ISP determined the problem and recommended adding ErrorDocument 301. The .htaccess file now looks like:
ErrorDocument 301
RedirectMatch 301 .* [quux-foo.com...]

Hopefully this will help someone else. This was unresolved for almost one month with no one able to help on any forums or mailing lists.

[jdMorgan]

Wow, That's an interesting situation -- The host had set an ErrorDocument for 301 responses, forcing you to "unset" it by specifying a blank argument to ErrorDocument -- That's highly unusual!

Thanks for posting. I didn't realize that ErrorDocument would even accept a blank argument!

Jim

[coopster]

I didn't either, and I wanted to know more so I started digging around a bit today. I dug into the source a bit and found this comment in one of the change logs for ver 2.2:

*) Changed the 'ErrorDocument' syntax in that it NO longer supports the asymetric

ErrorDocument 301 "Some message

Note the opening " quote, without a closing quote. It now has either the following syntaxes

... 
        ErrorDocument nnn /local/uri 
        ErrorDocument nnn http://valid/url 
        ErrorDocument nnn "Some Message"

The recognition heuristic is: if it has a space it is a message. If it has no spaces and starts with a / or is a valid URL then treat it that way. Otherwise it is assumed to be a message.

This breaks backward compatibility ...

So, be warned that in future releases you may have issues if you are still running the same configuration ...

Then I was thinking, would it really be "unsetting" the ErrorDocument redirect? I would have thought perhaps it would use the default <action> but seemingly not so. Still, being curious by what was happening here I started digging into the 1.3 source (

http_request.c

) and I've clipped most everything except the comments and if/else structure:

/* 
   * Two types of custom redirects --- plain text, and URLs. Plain text has 
   * a leading '"', so the URL code, here, is triggered on its absence 
   */ 
  if (custom_response && custom_response[0] != '"') { 
    if (ap_is_url(custom_response)) { 
/* 
 * The URL isn't local, so lets drop through the rest of this 
 * apache code, and continue with the usual REDIRECT handler. 
 * But note that the client will ultimately see the wrong 
 * status... 
 * 
 * Also, before updating r->status, we may need to ensure that 
 * the connection is dropped. For example, there may be 
 * unread request body that would confuse us if we try 
 * to read another request. 
 */ 
    } else if (custom_response[0] == '/') { 
    } else { 
/* 
 * Dumb user has given us a bad url to redirect to --- fake up 
 * dying with a recursive server error... 
 */ 
recursive_error = SERVER_ERROR; 
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO¦APLOG_ERR, r, 
"Invalid error redirection directive: %s", 
custom_response); 
    } 
  } 

Which response section do you feel you are getting? ;)