httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: Uniqueness, or security and <Location> revisited
Date Tue, 17 Oct 2000 00:51:02 GMT
On Sun, Oct 15, 2000 at 03:50:13PM -0500, William A. Rowe, Jr. wrote:
> 
>   I'm starting the overhaul of canonical name.  Everyone knows what
> it's for, and noone agrees on what it does.  OS2 full paths, Unix
> does nothing, Win32 just cleans it up.

I'm pretty sure it was named wrong from the very beginning, but it
is so ugly that nobody has had enough time to rearchitect it.

>   You have stated (and I agree) that if security matters to the website
> administrator, the filename should be resolved in the same case as on 
> the file system.  If it doesn't match, redirect (this blows monkey 
> chunks for anything but GET operations, however.)

BTW, I meant to say last time that I only care about the GET/HEAD
situation -- we could have a million URLs for a POST request (or even
for a GET/HEAD containing a "?") and it has no negative effect on the
Web because caches and spiders don't care.  So it is fine to only
redirect for M_GET.

>   If we take that for gospel, I really have to disagree with the current
> handling of multiple slashes.  We gleefully accept the URL /test//this/p.html
> and go right on humming, but coax the // into / for your basic <Location>
> parsing.  I'm arguing that this makes no more sense than your adamant stance
> against accepting the wrong case on file systems that simply -don't care-.
> The same goes for paths like /./test/this/p.html, which is equally well
> resolved.  

Absolutely -- it is a known bug introduced when the URL stuff was overhauled
for better speed, and I just never found the time to fix it.  There are
also bugs in the regex for request-URI.

>   I'm bugging the list on this because we can't persist the way we have, and
> need to get this right for 2.0 so we can blow the warning statements away.
> This is the single weakest link in the system.  If locations will ever work
> correctly on any platform, you are right on, we must accept that a file path
> should have one and only one possible resolution (never minding Multiviews,
> which could also be fixed with a redirect.)

No, Multiviews are a different egg.  In that case, we have multiple URI
that identify *different* resources which may map to the same file at
that specific point in time.

In general, the rule is to send a redirect to the client if the canonicalized
URL differs from the request URI in any mechanical way that was not the
result of website configuration (multiviews, mod_rewrite, alias, ...),
since the config can specify its own external redirect if desired.

>   What's your position on these (assuming entirely lower case real names):
> 
> /test//this/thing.p redirects to /test/this/thing.p
> /./test/this/thing.p also redirects to /test/this/thing.p
> /Test/This/Thing.p redirects to /test/this/thing.p
> 
>   This should affect the file system only, it will be up to other modules to
> observe the proper security precautions for their namespace.  I want to get
> this right from the getgo on 2.0b1 since we already have a dozen reports to
> the list, bugs, newsgroups etc of people who don't understand the changes to
> the regex RedirectMatch syntax.
> 
>   How do you all feel about this?

That's fine with me, but we might want a simple config option like

    RedirectCanon on

where on means send 301 (default) and off means send 404 (not found).
There might be some cases where a redirect results in an infinite loop
due to a buggy UA -- it would be best to prepare for that contingincy.

....Roy

Mime
View raw message