Joseph S D Yao wrote:
I understand that the argument to the Proxy directive is supposed to be a shell-style wildcard (rather than a simple prefix match), as the argument to the ProxyMatch directive is supposed to be a Perl-style regular expression.Ok. So a shell style wildcard never hits on a path delimiter, right?That depends on what "shell-style wildcard" means in a given implementation. I have seen ones where the path delimiter is not a special character. As the '/' is (a) not solely a path delimiter and (b) not the unique path delimiter, in a URL, I had not expected that to be a special character here.
Shell wildcards are sensitive to path delimiters; read RFC 2616 and its cited RFC's; "/" are path delimiters, End of discussion.
In fact, noting that a "*" will match "http://www.example.com/dir1/dir2/dir3/page.html";, I rather suspect that it is not.
It will.
<Proxy http://*.tuxedo.org*>Perhaps you meant http://*.tuxedo.org/* But the trailing * is redundant. drop it all together.Yours does not accept the common usage, "http://www.tuxedo.org";, with no trailing '/'. Most Web servers will accept and correct this.
No; they don't - your browser did. But that correction is prior to httpd handling the request. "/" is the minimal path, see the RFC.
It is not clear to me that the "*" is redundant. Without it, don't Irestrict myself to the home page?
No
All examples I have seen used with <Proxy> that are not using "*" end in '*'.
Who suggested random configurations you discover from google are any good? --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|