httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <>
Subject Re: Problem with <Directory proxy:*> and ap_os_canonical_filename()
Date Tue, 26 Jan 1999 23:53:47 GMT
On Sun, Jan 24, 1999 at 02:28:09PM +1000, Brian Havard wrote:
> When using a <Directory proxy:*> block to control access to the proxy,
> "proxy:*" is passed to ap_os_canonical_filename(). My OS/2 implementation of
> that function barfs on that (it's not a valid file name).
> So where should this special case be caught?

Hmmm. If I understand correctly, the Unix side simply allows it
through, so the simplest solution would probably be to allow it
through ap_os_canonical_filename with a special case. Another
alternative, which feels cleaner to me but is more work, would likely
be to check for "proxy:" in spots where it is valid, and skip the
os_canonical_filename call in those cases.

> On a related note I think ap_os_canonical_filename() needs to be able to
> return a failure status for when it's given a bogus file name.

This would be great. Of course, the core code has to be fixed to
support an error condition. But, how much of a hit would there be to
third-party code?

> I can
> currently bomb out a server process in OS/2 by sending it
> GET /a>b.html HTTP/1.0
> This triggers the ap_assert(rc==0) in OS/2's ap_os_canonical_filename() due
> to the '>'. I guess the correct behaviour would be to return "400 Bad
> Request".

As a short-term measure, how about just stripping out any illegal
characters? Or, have ap_ocf return "/" if DosQueryPathInfo returns an error.

Manoj Kasichainula - manojk at io dot com -
"How can one live in this age and not be curious?" -- Charles Krauthammer

View raw message