httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ken Parzygnat" <kp...@raleigh.ibm.com>
Subject RE: Problem with <Directory proxy:*> and ap_os_canonical_filename()
Date Fri, 29 Jan 1999 18:56:18 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?
> > 

Seems to me that you may want to use the routine that Paul wrote: ap_os_is_filename_valid.
Right now that routine's sole purpose is to determine if there is some special Windows
device name in the filename (like CON, AUX, ...), but maybe it should be extended a little?

> 
> This code used to get called for all sorts of things ...

This is true, that is one reason I don't think ap_os_canonical_filename cannot just
reject a bad name.   On Windows, ap_os_canonical_filename just returns "proxy:*"
when "proxy:*" is fed to it.

>  See the long list of example cases
> that kind IBM person (forget his name...) posted when he did work on the
> Win32 function.

That'd be me ... (blush).

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

This works OK on windows, the client gets back a 403.  

- - - - - - - - - - - - - - - - - -
Ken Parzygnat
email: kparz@raleigh.ibm.com 

Mime
View raw message