You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@worldgate.com> on 1997/12/30 09:17:44 UTC
[PATCH] PR1265: proxy caching broken on win32
Index: util_win32.c
===================================================================
RCS file: /export/home/cvs/apachen/src/os/win32/util_win32.c,v
retrieving revision 1.7
diff -u -r1.7 util_win32.c
--- util_win32.c 1997/12/26 15:29:40 1.7
+++ util_win32.c 1997/12/30 08:14:32
@@ -58,6 +58,8 @@
{
char buf[HUGE_STRING_LEN];
+ if (!strncmp(szFile, "proxy:", 6))
+ return pstrdup(pPool, szFile);
sub_canonical_filename(buf, szFile);
buf[0]=tolower(buf[0]);
return pstrdup(pPool, buf);
Re: [PATCH] PR1265: proxy caching broken on win32
Posted by Dean Gaudet <dg...@arctic.org>.
That comment is related to the definition IS_SPECIAL in http_core.c. It's
just saying that there's two things that satisfy IS_SPECIAL, one of them
has been dealt with already.
Dean
On Wed, 31 Dec 1997, Marc Slemko wrote:
> On Tue, 30 Dec 1997, Ben Laurie wrote:
>
> > >
> > > The problem is the proxy module period.
> > >
> > > It uses three ways to mark something as a proxy request.
> >
> > :-) When I was messing with the proxy module, I had a distinct suspicion
> > that one of the design principles was that it should use every hook in
> > the module structure (I believe it is the only module to do this).
>
> Looking at directory_walk again, I love this comment:
>
> /*
> * now match the "special" sections (regex, and "proxy:" stuff). But
> * note that proxy: stuff doesn't get down this far, it's been handled
> * earlier, so we'll just skip it.
> */
>
> "match proxy sections but we already did that so we don't"
>
>
>
Re: [PATCH] PR1265: proxy caching broken on win32
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 30 Dec 1997, Ben Laurie wrote:
> >
> > The problem is the proxy module period.
> >
> > It uses three ways to mark something as a proxy request.
>
> :-) When I was messing with the proxy module, I had a distinct suspicion
> that one of the design principles was that it should use every hook in
> the module structure (I believe it is the only module to do this).
Looking at directory_walk again, I love this comment:
/*
* now match the "special" sections (regex, and "proxy:" stuff). But
* note that proxy: stuff doesn't get down this far, it's been handled
* earlier, so we'll just skip it.
*/
"match proxy sections but we already did that so we don't"
Re: [PATCH] PR1265: proxy caching broken on win32
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> On Tue, 30 Dec 1997, Ben Laurie wrote:
>
> > Marc Slemko wrote:
> > >
> > > Index: util_win32.c
> > > ===================================================================
> > > RCS file: /export/home/cvs/apachen/src/os/win32/util_win32.c,v
> > > retrieving revision 1.7
> > > diff -u -r1.7 util_win32.c
> > > --- util_win32.c 1997/12/26 15:29:40 1.7
> > > +++ util_win32.c 1997/12/30 08:14:32
> > > @@ -58,6 +58,8 @@
> > > {
> > > char buf[HUGE_STRING_LEN];
> > >
> > > + if (!strncmp(szFile, "proxy:", 6))
> > > + return pstrdup(pPool, szFile);
> > > sub_canonical_filename(buf, szFile);
> > > buf[0]=tolower(buf[0]);
> > > return pstrdup(pPool, buf);
> >
> > I considered doing it this way, but isn't it symptomatic of a deeper
> > problem (i.e. that things starting "proxy:" should never be treated as
> > filenames)? What happens under Unix if I make files called
> > proxy:somethingclever in appropriate places?
>
> The problem is the proxy module period.
>
> It uses three ways to mark something as a proxy request.
:-) When I was messing with the proxy module, I had a distinct suspicion
that one of the design principles was that it should use every hook in
the module structure (I believe it is the only module to do this).
> What happens is that the access control code is the same for proxy access
> and for other stuff.
Ah.
> I suppose perhaps os_canonical_filename should be moved to below the if
> "(test_filename[0] != '/')" section of directory_walk.
I hope that's really an os_is_path_absolute()...
> Note that that
> section will always return and will always be called for proxy: (or any
> non-file) requests, so it isn't actually treated as a file.
>
> Yea, ok, I guess I can go for the bug being in the location of the call to
> os_canonical_filename. As long as there are no other "fake filenames"
> that do need canonicalization.
Not that I can think of, and I guess if I'm wrong we'll find out!
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: [PATCH] PR1265: proxy caching broken on win32
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 30 Dec 1997, Ben Laurie wrote:
> Marc Slemko wrote:
> >
> > Index: util_win32.c
> > ===================================================================
> > RCS file: /export/home/cvs/apachen/src/os/win32/util_win32.c,v
> > retrieving revision 1.7
> > diff -u -r1.7 util_win32.c
> > --- util_win32.c 1997/12/26 15:29:40 1.7
> > +++ util_win32.c 1997/12/30 08:14:32
> > @@ -58,6 +58,8 @@
> > {
> > char buf[HUGE_STRING_LEN];
> >
> > + if (!strncmp(szFile, "proxy:", 6))
> > + return pstrdup(pPool, szFile);
> > sub_canonical_filename(buf, szFile);
> > buf[0]=tolower(buf[0]);
> > return pstrdup(pPool, buf);
>
> I considered doing it this way, but isn't it symptomatic of a deeper
> problem (i.e. that things starting "proxy:" should never be treated as
> filenames)? What happens under Unix if I make files called
> proxy:somethingclever in appropriate places?
The problem is the proxy module period.
It uses three ways to mark something as a proxy request.
What happens is that the access control code is the same for proxy access
and for other stuff.
I suppose perhaps os_canonical_filename should be moved to below the if
"(test_filename[0] != '/')" section of directory_walk. Note that that
section will always return and will always be called for proxy: (or any
non-file) requests, so it isn't actually treated as a file.
Yea, ok, I guess I can go for the bug being in the location of the call to
os_canonical_filename. As long as there are no other "fake filenames"
that do need canonicalization.
Re: [PATCH] PR1265: proxy caching broken on win32
Posted by Ben Laurie <be...@algroup.co.uk>.
Marc Slemko wrote:
>
> Index: util_win32.c
> ===================================================================
> RCS file: /export/home/cvs/apachen/src/os/win32/util_win32.c,v
> retrieving revision 1.7
> diff -u -r1.7 util_win32.c
> --- util_win32.c 1997/12/26 15:29:40 1.7
> +++ util_win32.c 1997/12/30 08:14:32
> @@ -58,6 +58,8 @@
> {
> char buf[HUGE_STRING_LEN];
>
> + if (!strncmp(szFile, "proxy:", 6))
> + return pstrdup(pPool, szFile);
> sub_canonical_filename(buf, szFile);
> buf[0]=tolower(buf[0]);
> return pstrdup(pPool, buf);
I considered doing it this way, but isn't it symptomatic of a deeper
problem (i.e. that things starting "proxy:" should never be treated as
filenames)? What happens under Unix if I make files called
proxy:somethingclever in appropriate places?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache