You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/02/24 10:46:25 UTC
Re: over-aggressive redirection in mod_dir
I believe the problem can be handled much cleaner. I think we can all
agree that returning the 304 in the fixups phase is a good thing. It
allows sub-requests to determine if we are going to get a re-direct or
not. The problem is that before, we could always rely on the re-direction
only really happening if we were in a GET request.
Would we solve the basic problem if we just put a big if statement in the
fixups phase? Something like:
Index: mod_dir.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_dir.c,v
retrieving revision 1.30
diff -u -d -b -w -u -r1.30 mod_dir.c
--- mod_dir.c 2001/02/21 17:54:41 1.30
+++ mod_dir.c 2001/02/24 17:45:50
@@ -118,15 +118,11 @@
static int fixup_dir(request_rec *r)
{
- dir_config_rec *d;
-
if (r->finfo.filetype != APR_DIR) {
return DECLINED;
}
-
- d = (dir_config_rec *) ap_get_module_config(r->per_dir_config,
- &dir_module);
+ if (r->method_number == M_GET) {
if (r->uri[0] == '\0' || r->uri[strlen(r->uri) - 1] != '/') {
char *ifile;
if (r->args != NULL)
@@ -141,6 +137,8 @@
return HTTP_MOVED_PERMANENTLY;
}
return OK;
+ }
+ return DECLINED;
}
static int handle_dir(request_rec *r)
Ryan
On Sat, 24 Feb 2001, Greg Stein wrote:
> The mod_dir changes have seriously busted WebDAV handling in Apache.
>
> Let's say that I go into Windows Explorer and add a Web Folder. One of the
> first things it does is an OPTIONS request against the directory. However,
> it leaves off the trailing slash. The latest Apache 2.0 returns a 301 to
> tell the client to use a slash. However, Web Folders doesn't understand a
> 301 in this case, so it basically says "sorry. no DAV there."
>
>
> I'm not sure what the right solution here is (in the middle of other stuff,
> then some sleep), but I think we need to back off on the redirects.
>
> For now, I've just #if 0'd the fixup_dir() function in mod_dir.c (in my
> working copy). We'll need to fix this before the next tag/roll.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: over-aggressive redirection in mod_dir
Posted by Bill Stoddard <bi...@wstoddard.com>.
> Bill Stoddard wrote:
> >
> > > Bah. I say follow the RFC. Apache is a reference implementation
> > > of HTTP, and should do so in any event.
> >
> > And what do you do when a paying customer says 'hey, this function
> > that 1000's of my customers depend on that used to work is now
> > broken'?
>
> Apache *has* no 'paying customers.'
Too literal of an interpretation. Apache has users who rely on Apache to run
their business. If we break them, who are we serving? The RFC god?
>
> > Decisions like this must always be made on a case-by-case basis.
>
> Sorry, I believe in doing the RIGHT thing, not the expedient one.
> 'Be strict in what you send, liberal in what you accept.'
The RIGHT thing is serving our user base. We ignore that fact at our peril.
Bill
Re: over-aggressive redirection in mod_dir
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Monday, February 26, 2001 2:13 PM
> Bill Stoddard wrote:
> >
> > > Bah. I say follow the RFC. Apache is a reference implementation
> > > of HTTP, and should do so in any event.
> >
> > And what do you do when a paying customer says 'hey, this function
> > that 1000's of my customers depend on that used to work is now
> > broken'?
>
> Apache *has* no 'paying customers.'
>
> > Decisions like this must always be made on a case-by-case basis.
>
> Sorry, I believe in doing the RIGHT thing, not the expedient one.
> 'Be strict in what you send, liberal in what you accept.'
Paying or not - who looks to be the bad guy - MS for doing the wrong thing,
or Apache for doing the right thing?
Can this be resolved with a bit of IfEnv / BrowserMatch magic and a small
config directive?
You can't argue we have never made accomodations for other horked up browsers.
Bill
pps. I lost my mail list feed this a.m. - about 4 hours worth - so if I appear
clueless, it's just because I am.
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Stein wrote:
>
> I just added a task to STATUS, but I'm not sure that I parsed
> your statement above properly. Here is what is now in STATUS:
>
> * mod_dir should normally redirect ALL directory requests which do
> not include a trailing slash on the URI. However, if a "notes"
> flag is set (say, via BrowserMatch), this behavior will be
> disabled for non-GET requests.
> Status: Greg volunteers
> MsgId: <20...@lyra.org>
> MsgId: <3A...@Golux.Com>
>
> Does that match your thoughts, Ken?
Sort of. In metatext, what I meant was:
"mod_dir should normally redirect ALL directory requests which do
not include a trailing slash on the URI. However, if an
environment variable is set (such as by BrowserMatch), and the
method is other than HEAD or GET, mod_dir should treat the request
as though the slash had been included."
Is that any more parseable? :-)
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 27, 2001 at 02:31:35PM -0500, Rodent of Unusual Size wrote:
>...
> So we MAY accept "foo" instead of "foo/", and SHOULD emit a
> content-location field if we do, and Web Folders SHOULD include
> the trailing slash in the first place.
>
> Note that this is a convention, however, and not a rule.
> "foo" != "foo/" -- but it MAY be treated as though it were.
>
> It is not quite as black&white as I thought it to be. I change
> to +1 for the configurable behaviour with the default being the
> treatment as equivalence, and -0 for forcing that treatment by
> fiat in all cases.
I just added a task to STATUS, but I'm not sure that I parsed your statement
above properly. Here is what is now in STATUS:
* mod_dir should normally redirect ALL directory requests which do
not include a trailing slash on the URI. However, if a "notes"
flag is set (say, via BrowserMatch), this behavior will be
disabled for non-GET requests.
Status: Greg volunteers
MsgId: <20...@lyra.org>
MsgId: <3A...@Golux.Com>
Does that match your thoughts, Ken?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Rodent of Unusual Size" <Ke...@Golux.Com>
Sent: Tuesday, February 27, 2001 1:31 PM
> > [RFC2396].
> :
> > There is a standing convention that when a collection is referred to
> > by its name without a trailing slash, the trailing slash is
> > automatically appended. Due to this, a resource may accept a URI
> > without a trailing "/" to point to a collection. In this case it
> > SHOULD return a content-location header in the response pointing to
> > the URI ending with the "/". For example, if a client invokes a
> > method on http://foo.bar/blah (no trailing slash), the resource
> > http://foo.bar/blah/ (trailing slash) may respond as if the operation
> > were invoked on it, and should return a content-location header with
> > http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
> > form of collection names.
>
> So we MAY accept "foo" instead of "foo/", and SHOULD emit a
> content-location field if we do, and Web Folders SHOULD include
> the trailing slash in the first place.
Note that we hork this right now, we simply return the barename in some
cases, such as index.html.en given a request for /docs/index.html or
simply /docs/ if the user turned on multiviews.
By properly returning content-location=/docs/index.html.en
we will provide significant stability for relative paths. The obvious
question, if we request /docs/somescript.pl/foo/bar is; or even worse,
if we request /docs/index.html/foo/bar in the above example, can we
actually return the actual script for relative path parsing, e.g.
content-location=/docs/somescript.pl or content-location=/docs/index.html.en
in those cases?
> Note that this is a convention, however, and not a rule.
> "foo" != "foo/" -- but it MAY be treated as though it were.
Absolutely agreed, this is simply shorthand. So is the multiplicity
between /docs, /docs/, /docs/index.html and /docs/index.html.en
> It is not quite as black&white as I thought it to be. I change
> to +1 for the configurable behaviour with the default being the
> treatment as equivalence, and -0 for forcing that treatment by
> fiat in all cases.
+1 here for adding the conditional behavior, and +1 for setting up the
appropriate BrowserMatch semantics to get around the bogus MS implementation,
and +1 to correct content-location to return the 'proper' server-rooted uri.
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Stein wrote:
>
> Eh? How is that. If http://www.lyra.org/dav translates to a
> directory in the filesystem, then what else can it possibly mean?
What if I want the actual contents of the directory file itself,
rather than the formatted metadata or the collection object?
> Ken: go find the RFC that talks about trailing slashes.
RFC 2518:
> 5.2 Collection Resources
>
> A collection is a resource whose state consists of at least a list of
> internal member URIs and a set of properties, but which may have
> additional state such as entity bodies returned by GET. An internal
> member URI MUST be immediately relative to a base URI of the
> collection. That is, the internal member URI is equal to a
> containing collection's URI plus an additional segment for non-
> collection resources, or additional segment plus trailing slash "/"
> for collection resources, where segment is defined in section 3.3 of
> [RFC2396].
:
> There is a standing convention that when a collection is referred to
> by its name without a trailing slash, the trailing slash is
> automatically appended. Due to this, a resource may accept a URI
> without a trailing "/" to point to a collection. In this case it
> SHOULD return a content-location header in the response pointing to
> the URI ending with the "/". For example, if a client invokes a
> method on http://foo.bar/blah (no trailing slash), the resource
> http://foo.bar/blah/ (trailing slash) may respond as if the operation
> were invoked on it, and should return a content-location header with
> http://foo.bar/blah/ in it. In general clients SHOULD use the "/"
> form of collection names.
So we MAY accept "foo" instead of "foo/", and SHOULD emit a
content-location field if we do, and Web Folders SHOULD include
the trailing slash in the first place.
Note that this is a convention, however, and not a rule.
"foo" != "foo/" -- but it MAY be treated as though it were.
It is not quite as black&white as I thought it to be. I change
to +1 for the configurable behaviour with the default being the
treatment as equivalence, and -0 for forcing that treatment by
fiat in all cases.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 27, 2001 at 01:09:02PM -0500, Rodent of Unusual Size wrote:
> Greg Stein wrote:
> > The question is NOT about how GETs are handled. We all agree that
> > a GET should be redirected.
> >
> > The issue is for methods *OTHER* than GET.
>
> I disagree. I believe the issue is for *all* methods.
We're agreed on GET. Not so for the others. That's where the issue is :-)
> > If you redirect an OPTIONS /dav, then WebFolders says that /dav is not
> > DAV-enabled. It's a no-go from the start.
> >
> > Basically, doing a redirect on /dav is not "being lenient in what we
> > accept", even though Ken said we should be. We know what was meant,
> > so we should go ahead and respond.
>
> <sarcasm> How wonderful it must be to have such omniscience. </sarcasm>
> No, we do NOT know what was meant. We can guess, and probably be
> right, but we cannot KNOW.
Eh? How is that. If http://www.lyra.org/dav translates to a directory in the
filesystem, then what else can it possibly mean?
> +1 on an envariable switch controlling whether we treat "foo" and
> "foo/" as equivalent (for ALL methods). -1 on redirecting some
> and not redirecting others without configurability.
RFC 2616 has special language about redirecting GET and HEAD. If you want to
obey the RFCs, then you will redirect specific methods. Not all.
Another answer may to stop the redirection altogether and use the
Content-Location header.
Ken: go find the RFC that talks about trailing slashes.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Stein wrote:
>
> The question is NOT about how GETs are handled. We all agree that
> a GET should be redirected.
>
> The issue is for methods *OTHER* than GET.
I disagree. I believe the issue is for *all* methods.
> If you redirect an OPTIONS /dav, then WebFolders says that /dav is not
> DAV-enabled. It's a no-go from the start.
>
> Basically, doing a redirect on /dav is not "being lenient in what we
> accept", even though Ken said we should be. We know what was meant,
> so we should go ahead and respond.
<sarcasm> How wonderful it must be to have such omniscience. </sarcasm>
No, we do NOT know what was meant. We can guess, and probably be
right, but we cannot KNOW.
+1 on an envariable switch controlling whether we treat "foo" and
"foo/" as equivalent (for ALL methods). -1 on redirecting some
and not redirecting others without configurability.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
The question is NOT about how GETs are handled. We all agree that a GET
should be redirected.
The issue is for methods *OTHER* than GET.
If you redirect an OPTIONS /dav, then WebFolders says that /dav is not
DAV-enabled. It's a no-go from the start.
Basically, doing a redirect on /dav is not "being lenient in what we
accept", even though Ken said we should be. We know what was meant, so we
should go ahead and respond.
Cheers,
-g
On Tue, Feb 27, 2001 at 11:07:36AM -0500, Dale Ghent wrote:
> On Tue, 27 Feb 2001, Rodent of Unusual Size wrote:
>
> | So let mod_dir treat them as equivalent if the envariable
> | "no-collection-redirect" is set, otherwise continue in the
> | current, technically correct, behaviour.
>
> Your description of the problem is fair.
>
> On a curious whim, I went a took a look at how other servers handle this
> (ie, is /foo and /foo/ the same or are we redirected?):
>
> ----------------------------------------------
> Zeus redirects you with a 301:
>
> [daleg@stardiver]~>telnet support.digex.net 80
> Trying 205.197.247.39...
> Connected to support.digex.net (205.197.247.39).
> Escape character is '^]'.
> GET /cst HTTP/1.0
>
> HTTP/1.1 301 Moved Permanently
> Server: Zeus/3.1
> Date: Tue, 27 Feb 2001 16:00:51 GMT
> Connection: close
> Content-Type: text/html
> Location: http://support.digex.net/cst/
>
> ---------------------------------------------
> IIS redirects using a 302:
>
> [daleg@stardiver]~>telnet www.digex.com 80
> Trying 164.109.42.100...
> Connected to www.digex.com (164.109.42.100).
> Escape character is '^]'.
> GET /leverage HTTP/1.1
> Host: www.digex.com
>
> HTTP/1.1 302 Object Moved
> Location: http://www.digex.com/leverage/
> Server: Microsoft-IIS/5.0
> Content-Type: text/html
> Content-Length: 153
>
> ---------------------------------------------
> Netscape 3.x redirects with a 302:
>
> [daleg@stardiver]~>telnet www.kraftfoods.com 80
> Trying 164.109.67.183...
> Connected to kraftfoods.com (164.109.67.183).
> Escape character is '^]'.
> GET /templates HTTP/1.1
> Host: www.kraftfoods.com
>
> HTTP/1.1 302 Moved Temporarily
> Server: Netscape-Enterprise/3.6 SP2
> Date: Tue, 27 Feb 2001 16:06:16 GMT
> Location: http://www.kraftfoods.com/templates/
> Content-length: 0
> Content-type: text/html
>
> /dale
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 27, 2001 at 01:04:30PM -0500, Rodent of Unusual Size wrote:
> Greg Stein wrote:
> > We aren't talking about GETs. What you state is correct, but
> > only with respect to a GET.
>
> Umm.. huh? It applies to anything that tries to interpolate
> relative URIs. The request method is completely irrelevant.
> Of course, this hardly ever happens with anything *except* GETs,
> but your argument is specious.
URL interpolation (by which I assume you mean "joining a base with a
relative path") occurs within the UA for content bodies returned by a GET. I
don't know of any other situation where it occurs.
The whole redirect thing is really pretty bogus.
http://www.lyra.org/dav
When I hit the filesystem and see that the above URL refers to a directory,
then I know absolutely and unequivocally that they referred to the
directory. There is just no question about it.
What this whole argument is about is that some people think it really needs
a slash on the end because of some perceived notion of "ambiguity".
Heck, let's pull out our RFCs here. Section 10.3.2 301 Moved Permanently. It
says, "If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the request
unless it can be confirmed by the user, since this might change the
conditions under which the request was issued."
According to that paragraph, WebFolders is perfectly justified in its
behavior (refusing to use the new location as the web folder). IOW, it is
working correctly.
If Apache decides to issue a redirect for a method other than GET/HEAD,
then we should expect that the UA will not automatically switch over and
reissue the request. In fact, the RFC says that it MUST NOT. (emphasis
original)
> > Things like PROPFIND and OPTIONS don't have the issue you describe.
> > The current CVS code only does the redirect for the GET and HEAD
> > methods.
>
> By 'current' you mean the recently-applied patch, correct?
Yup.
> Which
> behaviour is different from that of the pre-patch software, correct?
The pre-patch would redirect on all requests. But that was caused by other
work in that area. Prior to that, the redirection logic was wrapped up in
the handler. If anybody else handled the request (e.g. mod_dav serving a
PROPFIND or mod_put handling a PUT or DELETE or ...), then the mod_dir
handler wouldn't be invoked and no redirection would occur.
Based on RFC 2616, it appears the current CVS behavior is best for UAs. If
we return redirects, then the UA won't be able to automatically handle them.
I have yet to hear somebody point to an RFC about trailing slashes.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Greg Stein wrote:
>
> We aren't talking about GETs. What you state is correct, but
> only with respect to a GET.
Umm.. huh? It applies to anything that tries to interpolate
relative URIs. The request method is completely irrelevant.
Of course, this hardly ever happens with anything *except* GETs,
but your argument is specious.
> Things like PROPFIND and OPTIONS don't have the issue you describe.
> The current CVS code only does the redirect for the GET and HEAD
> methods.
By 'current' you mean the recently-applied patch, correct? Which
behaviour is different from that of the pre-patch software, correct?
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by "James A. Sutherland" <ja...@cam.ac.uk>.
On Tue, 27 Feb 2001, Greg Stein wrote:
> On Tue, Feb 27, 2001 at 12:33:25PM +0000, James A. Sutherland wrote:
> > On Tue, 27 Feb 2001, Rodent of Unusual Size wrote:
> > > Dale Ghent wrote:
> > > >
> > > > Correct or not, they are equivalent.
> > >
> > > No, they are not.
> >
> > Indeed - and in another way not yet mentioned...
> >
> > Think about relative links. If I request "/foo/help.html", and then click
> > on a link to "rtfm.html" on that page, I am requesting "/foo/rtfm.html".
> >
> > Now I'll try "/foo/", and do the same. Again, I'm requesting
> > "/foo/rtfm.html". OK?
> >
> > Now think about "/foo" - logically, clicking on "rtfm.html" on THAT URL's
> > HTML would be a request for "/rtfm.html". Oops.
>
> We aren't talking about GETs. What you state is correct, but only with
> respect to a GET.
>
> Things like PROPFIND and OPTIONS don't have the issue you describe. The
> current CVS code only does the redirect for the GET and HEAD methods.
Hrmm?! I don't like the sound of that... the URL would appear valid for
one method, but result in a 30x for another?!
James.
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Feb 27, 2001 at 12:33:25PM +0000, James A. Sutherland wrote:
> On Tue, 27 Feb 2001, Rodent of Unusual Size wrote:
> > Dale Ghent wrote:
> > >
> > > Correct or not, they are equivalent.
> >
> > No, they are not.
>
> Indeed - and in another way not yet mentioned...
>
> Think about relative links. If I request "/foo/help.html", and then click
> on a link to "rtfm.html" on that page, I am requesting "/foo/rtfm.html".
>
> Now I'll try "/foo/", and do the same. Again, I'm requesting
> "/foo/rtfm.html". OK?
>
> Now think about "/foo" - logically, clicking on "rtfm.html" on THAT URL's
> HTML would be a request for "/rtfm.html". Oops.
We aren't talking about GETs. What you state is correct, but only with
respect to a GET.
Things like PROPFIND and OPTIONS don't have the issue you describe. The
current CVS code only does the redirect for the GET and HEAD methods.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by "James A. Sutherland" <ja...@cam.ac.uk>.
On Tue, 27 Feb 2001, Rodent of Unusual Size wrote:
> Dale Ghent wrote:
> >
> > Correct or not, they are equivalent.
>
> No, they are not.
Indeed - and in another way not yet mentioned...
Think about relative links. If I request "/foo/help.html", and then click
on a link to "rtfm.html" on that page, I am requesting "/foo/rtfm.html".
Now I'll try "/foo/", and do the same. Again, I'm requesting
"/foo/rtfm.html". OK?
Now think about "/foo" - logically, clicking on "rtfm.html" on THAT URL's
HTML would be a request for "/rtfm.html". Oops.
James.
Re: over-aggressive redirection in mod_dir
Posted by Dale Ghent <da...@elemental.org>.
On Tue, 27 Feb 2001, Rodent of Unusual Size wrote:
| So let mod_dir treat them as equivalent if the envariable
| "no-collection-redirect" is set, otherwise continue in the
| current, technically correct, behaviour.
Your description of the problem is fair.
On a curious whim, I went a took a look at how other servers handle this
(ie, is /foo and /foo/ the same or are we redirected?):
----------------------------------------------
Zeus redirects you with a 301:
[daleg@stardiver]~>telnet support.digex.net 80
Trying 205.197.247.39...
Connected to support.digex.net (205.197.247.39).
Escape character is '^]'.
GET /cst HTTP/1.0
HTTP/1.1 301 Moved Permanently
Server: Zeus/3.1
Date: Tue, 27 Feb 2001 16:00:51 GMT
Connection: close
Content-Type: text/html
Location: http://support.digex.net/cst/
---------------------------------------------
IIS redirects using a 302:
[daleg@stardiver]~>telnet www.digex.com 80
Trying 164.109.42.100...
Connected to www.digex.com (164.109.42.100).
Escape character is '^]'.
GET /leverage HTTP/1.1
Host: www.digex.com
HTTP/1.1 302 Object Moved
Location: http://www.digex.com/leverage/
Server: Microsoft-IIS/5.0
Content-Type: text/html
Content-Length: 153
---------------------------------------------
Netscape 3.x redirects with a 302:
[daleg@stardiver]~>telnet www.kraftfoods.com 80
Trying 164.109.67.183...
Connected to kraftfoods.com (164.109.67.183).
Escape character is '^]'.
GET /templates HTTP/1.1
Host: www.kraftfoods.com
HTTP/1.1 302 Moved Temporarily
Server: Netscape-Enterprise/3.6 SP2
Date: Tue, 27 Feb 2001 16:06:16 GMT
Location: http://www.kraftfoods.com/templates/
Content-length: 0
Content-type: text/html
/dale
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dale Ghent wrote:
>
> Correct or not, they are equivalent.
No, they are not.
> Since they're equivalent, why is one more correct than the other?
> Put in the perspective of something simpler; Is it better to
> 'cd /usr/' or 'cd /usr' ? Neither is better. They do and mean
> the same thing.
For Unix shells, that is correct. For Web URLs, it is not.
'http://server/foo' and 'http://server/foo/' are NOT identical;
the second has a trailing empty path segment.
For filesystem datastores, a trailing empty path segment refers
to a collection -- what Dean liked/likes to call the 'directory
object.' Apache supplies mod_dir and mod_autoindex to respond
to requests for directory objects.
For filesystem datastores, a request that lacks the empty segment
is for the directory itself. Since that is generally a meaningless
request, mod_dir assumes the directory *object* was meant, and issues
a redirect to the correct URL for that resource.
The thing that raised this issue was Web Folders' inability to
cope with a 301 response to an OPTIONS request. That is just plain
broken. It is actually broken in two different ways, since
it should never have made the request without the trailing empty
segment anyway, since it is querying a collection.
The question is whether we work around this brokenness by
*treating* the two different formats as though they are
equivalent (although they actually are not). Since this
issue comes up repeatedly in other contexts -- filesystem ones --
I am in favour of providing a means of doing so. If Web Folders
was the only client encountering this, I would say 'no way.'
(Actually, AFAIK it *is* the only broken client -- in all other
cases, it is the users' expectations that are broken. :-)
So let mod_dir treat them as equivalent if the envariable
"no-collection-redirect" is set, otherwise continue in the
current, technically correct, behaviour.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by Dale Ghent <da...@elemental.org>.
On Tue, 27 Feb 2001, James A. Sutherland wrote:
| On Mon, 26 Feb 2001, Greg Stein wrote:
|
| > On Mon, Feb 26, 2001 at 03:13:13PM -0500, Rodent of Unusual Size wrote:
| > >...
| > > > Decisions like this must always be made on a case-by-case basis.
| > >
| > > Sorry, I believe in doing the RIGHT thing, not the expedient one.
| > > 'Be strict in what you send, liberal in what you accept.'
| >
| > Um. Doesn't "liberal in what you accept" mean that we should be liberal in
| > accepting URLs without a trailing slash? We *KNOW* what the hell the client
| > meant, so why should we go and mess things up?
|
| What they put is /foo when they should have said /foo/ - so the correct
| thing to do, surely, is send a redirect to /foo/ and leave it at that.
| What's the problem?
Correct or not, they are equivalent.
Since they're equivalent, why is one more correct than the other? Put in
the perspective of something simpler; Is it better to 'cd /usr/' or
'cd /usr' ? Neither is better. They do and mean the same thing.
The only thing that would separate the two is a RFC or a compelling
system-level reason (which I doubt exists). Do any relevant RFCs address
this? If so, we follow it. If not, then lets not make more work for the
server because of idiosyncrasies.
/dale
Re: over-aggressive redirection in mod_dir
Posted by "James A. Sutherland" <ja...@cam.ac.uk>.
On Mon, 26 Feb 2001, Greg Stein wrote:
> On Mon, Feb 26, 2001 at 03:13:13PM -0500, Rodent of Unusual Size wrote:
> >...
> > > Decisions like this must always be made on a case-by-case basis.
> >
> > Sorry, I believe in doing the RIGHT thing, not the expedient one.
> > 'Be strict in what you send, liberal in what you accept.'
>
> Um. Doesn't "liberal in what you accept" mean that we should be liberal in
> accepting URLs without a trailing slash? We *KNOW* what the hell the client
> meant, so why should we go and mess things up?
What they put is /foo when they should have said /foo/ - so the correct
thing to do, surely, is send a redirect to /foo/ and leave it at that.
What's the problem?
James.
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 26, 2001 at 03:13:13PM -0500, Rodent of Unusual Size wrote:
>...
> > Decisions like this must always be made on a case-by-case basis.
>
> Sorry, I believe in doing the RIGHT thing, not the expedient one.
> 'Be strict in what you send, liberal in what you accept.'
Um. Doesn't "liberal in what you accept" mean that we should be liberal in
accepting URLs without a trailing slash? We *KNOW* what the hell the client
meant, so why should we go and mess things up?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> Obeisance to the RFC gods is nice, but it is still up to the client to say
> "I was redirected to a different URL, so the one you gave me isn't DAV
> capable." That doesn't violate RFCs, AFAICT. Let's let them work.
BTW, I would have suggested browsermatch, but the fact is that Microsoft
is just taking an overly-anal interpretation of RFC 2616 and puking
on the 301 instead of doing the automatic redirect of OPTIONS. This is
the fault of the wording in RFC 2616 as much as anything else.
....Roy
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 26, 2001 at 03:42:34PM -0500, Rodent of Unusual Size wrote:
> Jim Winstead wrote:
> >
> > but hasn't the standard httpd solution to these things been to
> > implement something like 'nokeepalive' and introduce a BrowserMatch
> > line to the standard config to enable the incorrect behavior for
> > broken browsers?
>
> *That* concept I can +1. As long as it is not the default..
After seeing some of the reaction last night before I tuned out (had a
marathon session of Smuggler's Run on my PS2), I got the impression people
were desiring a "conformant" server over a "useful" server. Personally, I'll
take the latter, but understand people's desire for the former. What was the
solution? (ponder ponder) I figured on a directive and then remembered the
"force-response-1.0" stuff in the .conf file.
I'll be implementing a BrowserMatch-based fix for the "avoid redirects on
non-GET requests". I think the default should be on, however. Just like we
enable force-response-1.0 by default, we ought to do the same for this case.
Otherwise, by that logic, we should tell web server admins that the default
install won't work for certain clients, but "oh, you can fix that for them
by tweaking your .conf". I'd much rather see that we work out of the box for
as many scenarios as possible, yet not lose the fact that we are making
special concessions to do so.
Obeisance to the RFC gods is nice, but it is still up to the client to say
"I was redirected to a different URL, so the one you gave me isn't DAV
capable." That doesn't violate RFCs, AFAICT. Let's let them work.
And note: since this will be a .conf issue, people developing *new* software
will have to fix their code since most servers won't have the right conf
magic. We do get to use our "hammer" on them.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jim Winstead wrote:
>
> but hasn't the standard httpd solution to these things been to
> implement something like 'nokeepalive' and introduce a BrowserMatch
> line to the standard config to enable the incorrect behavior for
> broken browsers?
*That* concept I can +1. As long as it is not the default..
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by Jim Winstead <ji...@trainedmonkey.com>.
On Mon, Feb 26, 2001 at 03:13:13PM -0500, Rodent of Unusual Size wrote:
> Bill Stoddard wrote:
> >
> > > Bah. I say follow the RFC. Apache is a reference implementation
> > > of HTTP, and should do so in any event.
> >
> > And what do you do when a paying customer says 'hey, this function
> > that 1000's of my customers depend on that used to work is now
> > broken'?
>
> Apache *has* no 'paying customers.'
but hasn't the standard httpd solution to these things been to
implement something like 'nokeepalive' and introduce a BrowserMatch
line to the standard config to enable the incorrect behavior for
broken browsers?
maybe a solution along these lines would be appropriate here.
jim
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Bill Stoddard wrote:
>
> > Bah. I say follow the RFC. Apache is a reference implementation
> > of HTTP, and should do so in any event.
>
> And what do you do when a paying customer says 'hey, this function
> that 1000's of my customers depend on that used to work is now
> broken'?
Apache *has* no 'paying customers.'
> Decisions like this must always be made on a case-by-case basis.
Sorry, I believe in doing the RIGHT thing, not the expedient one.
'Be strict in what you send, liberal in what you accept.'
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by Bill Stoddard <bi...@wstoddard.com>.
> rbb@covalent.net wrote:
> >
> > Ummmm, This message is suggesting regressing function that once
> > worked. This message says, break WebFolders, but tell people how
> > to fix it, since we would finally be following the spec. What
> > we have right now, is a bit broken, but it doesn't break WebFolders.
>
> So we are broken, and WebFolders are broken. Brilliant solution,
> that, in which NO-one is doing it correctly.
>
> Bah. I say follow the RFC. Apache is a reference implementation
> of HTTP, and should do so in any event.
> --
And what do you do when a paying customer says 'hey, this function that 1000's
of my customers depend on that used to work is now broken'? Tell them to look
at the RFC? Decisions like this must always be made on a case-by-case basis.
This one seems to be a case that we can accomodate with minimal impact on
anything else.
Bill
Re: over-aggressive redirection in mod_dir
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> Ummmm, This message is suggesting regressing function that once
> worked. This message says, break WebFolders, but tell people how
> to fix it, since we would finally be following the spec. What
> we have right now, is a bit broken, but it doesn't break WebFolders.
So we are broken, and WebFolders are broken. Brilliant solution,
that, in which NO-one is doing it correctly.
Bah. I say follow the RFC. Apache is a reference implementation
of HTTP, and should do so in any event.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
ApacheCon 2001!
Four tracks with over 70+ sessions. Free admission to exhibits
and special events - keynote presentations by John 'maddog' Hall
and David Brin. Special thanks to our Platinum Sponsors IBM and
Covalent, Gold Sponsor Thawte, and Silver Sponsor Compaq. Attend
only Apache event designed and fully supported by the members of
the ASF. See more information and register at <http://ApacheCon.Com/>!
Re: over-aggressive redirection in mod_dir
Posted by rb...@covalent.net.
On Sun, 25 Feb 2001, Bill Stoddard wrote:
>
> > And therein lies the biggest dilemma of all... do you follow the RFC's or
> > fix a Microsoft bug... my vote... follow the RFC's and comment the lines
> > where the patch needs to go and then show them what the patch is.
> >
> > You now have achieved two critical things...
> >
> > 1. Followed the RFC's
> > 2. Supported the customer which in turn will get them to continue using the
> > product.
> >
> > A win win for the ASF, which can only be a good thing.
> >
>
> I have to agree. Regressing function that once worked, is usually a bad idea.
Ummmm, This message is suggesting regressing function that once worked.
This message says, break WebFolders, but tell people how to fix it, since
we would finally be following the spec. What we have right now, is a bit
broken, but it doesn't break WebFolders.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: over-aggressive redirection in mod_dir
Posted by Bill Stoddard <bi...@wstoddard.com>.
> And therein lies the biggest dilemma of all... do you follow the RFC's or
> fix a Microsoft bug... my vote... follow the RFC's and comment the lines
> where the patch needs to go and then show them what the patch is.
>
> You now have achieved two critical things...
>
> 1. Followed the RFC's
> 2. Supported the customer which in turn will get them to continue using the
> product.
>
> A win win for the ASF, which can only be a good thing.
>
I have to agree. Regressing function that once worked, is usually a bad idea.
Bill
RE: over-aggressive redirection in mod_dir
Posted by "Peter J. Cranstone" <Cr...@remotecommunications.com>.
And therein lies the biggest dilemma of all... do you follow the RFC's or
fix a Microsoft bug... my vote... follow the RFC's and comment the lines
where the patch needs to go and then show them what the patch is.
You now have achieved two critical things...
1. Followed the RFC's
2. Supported the customer which in turn will get them to continue using the
product.
A win win for the ASF, which can only be a good thing.
Peter
-----Original Message-----
From: rbb@covalent.net [mailto:rbb@covalent.net]
Sent: Sunday, February 25, 2001 9:47 AM
To: new-httpd@apache.org
Subject: Re: over-aggressive redirection in mod_dir
On Sat, 24 Feb 2001, Roy T. Fielding wrote:
> WTF? First of all, Webfolders is buggy because it should always be
> including the trailing slash. How the brainiacs at Microsoft got that
> one wrong is beyond me -- I personally explained to them that Apache
> returns a 301 on any directory without a slash because those are two
> different resources and ONLY the one with the slash is a collection.
> The other URL is not a collection.
Roy, I think you answered your question for yourself. :-) You explained
in great detail how to make Webfolders incompatible with Apache. I have a
feeling they tested against Apache, and discovered that it continued to
work. The problem was that they were getting lucky. We allowed mod_dav
to get the handler phase before mod_dir. Now, we always run this because
it is in the fixup, so we are going to ALWAYS do the redirection.
> Greg, the change is wrong, but I suppose we can leave it in for now.
This begs the question, how long do we leave the wrong behavior in the
code? I would rather fix this correctly now, and break Webfolders than
continue doing something wrong.
Ryan
____________________________________________________________________________
___
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
----------------------------------------------------------------------------
---
Re: over-aggressive redirection in mod_dir
Posted by rb...@covalent.net.
On Sat, 24 Feb 2001, Roy T. Fielding wrote:
> WTF? First of all, Webfolders is buggy because it should always be
> including the trailing slash. How the brainiacs at Microsoft got that
> one wrong is beyond me -- I personally explained to them that Apache
> returns a 301 on any directory without a slash because those are two
> different resources and ONLY the one with the slash is a collection.
> The other URL is not a collection.
Roy, I think you answered your question for yourself. :-) You explained
in great detail how to make Webfolders incompatible with Apache. I have a
feeling they tested against Apache, and discovered that it continued to
work. The problem was that they were getting lucky. We allowed mod_dav
to get the handler phase before mod_dir. Now, we always run this because
it is in the fixup, so we are going to ALWAYS do the redirection.
> Greg, the change is wrong, but I suppose we can leave it in for now.
This begs the question, how long do we leave the wrong behavior in the
code? I would rather fix this correctly now, and break Webfolders than
continue doing something wrong.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: over-aggressive redirection in mod_dir
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
WTF? First of all, Webfolders is buggy because it should always be
including the trailing slash. How the brainiacs at Microsoft got that
one wrong is beyond me -- I personally explained to them that Apache
returns a 301 on any directory without a slash because those are two
different resources and ONLY the one with the slash is a collection.
The other URL is not a collection.
Greg, the change is wrong, but I suppose we can leave it in for now.
Unfortunately, the HTTP spec overspecified the constraint on redirecting
request methods -- it is perfectly safe for a user agent to automatically
handle a redirect for a read-only method like OPTIONS. I expected that
the WebDAV spec would have made that clear, but it doesn't, so I'll have
to send it to the http-wg.
I suppose you have already informed the webfolders dudes that their
code is buggy.
....Roy
Re: over-aggressive redirection in mod_dir
Posted by rb...@covalent.net.
On Sat, 24 Feb 2001, Greg Stein wrote:
> On Sat, Feb 24, 2001 at 06:55:27AM -0800, rbb@covalent.net wrote:
> > On Sat, 24 Feb 2001, Greg Stein wrote:
> >
> > > Agreed. I thought of the same thing about an hour or so ago. Given two minds
> > > in agreement :-), I went ahead and made the change.
> > >
> > > The underlying rationale is this: for relative links in a returned document
> > > (via a GET) to work properly, the base URL needs a terminating slash; this
> > > fixup handles that. Other methods do not return content (in the same way or
> > > semantics), so they do not require the redirection.
> >
> > The other nice thing, that I realized while I was out. This is how I read
> > the RFC. :-)
>
> Woah! There is something in 2616 about this? What section?
Take a look at section 10.3.2. It isn't perfect, but IMHO it opens a
small loophole that says the server can treat everything other than GET
and HEAD differently from how it would treat GET and HEAD requests.
It's a bit shady, but I think we can get away with it.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Feb 24, 2001 at 06:55:27AM -0800, rbb@covalent.net wrote:
> On Sat, 24 Feb 2001, Greg Stein wrote:
>
> > Agreed. I thought of the same thing about an hour or so ago. Given two minds
> > in agreement :-), I went ahead and made the change.
> >
> > The underlying rationale is this: for relative links in a returned document
> > (via a GET) to work properly, the base URL needs a terminating slash; this
> > fixup handles that. Other methods do not return content (in the same way or
> > semantics), so they do not require the redirection.
>
> The other nice thing, that I realized while I was out. This is how I read
> the RFC. :-)
Woah! There is something in 2616 about this? What section?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: over-aggressive redirection in mod_dir
Posted by rb...@covalent.net.
On Sat, 24 Feb 2001, Greg Stein wrote:
> Agreed. I thought of the same thing about an hour or so ago. Given two minds
> in agreement :-), I went ahead and made the change.
>
> The underlying rationale is this: for relative links in a returned document
> (via a GET) to work properly, the base URL needs a terminating slash; this
> fixup handles that. Other methods do not return content (in the same way or
> semantics), so they do not require the redirection.
The other nice thing, that I realized while I was out. This is how I read
the RFC. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: over-aggressive redirection in mod_dir
Posted by Greg Stein <gs...@lyra.org>.
Agreed. I thought of the same thing about an hour or so ago. Given two minds
in agreement :-), I went ahead and made the change.
The underlying rationale is this: for relative links in a returned document
(via a GET) to work properly, the base URL needs a terminating slash; this
fixup handles that. Other methods do not return content (in the same way or
semantics), so they do not require the redirection.
Cheers,
-g
On Sat, Feb 24, 2001 at 01:46:25AM -0800, rbb@covalent.net wrote:
>
> I believe the problem can be handled much cleaner. I think we can all
> agree that returning the 304 in the fixups phase is a good thing. It
> allows sub-requests to determine if we are going to get a re-direct or
> not. The problem is that before, we could always rely on the re-direction
> only really happening if we were in a GET request.
>
> Would we solve the basic problem if we just put a big if statement in the
> fixups phase? Something like:
>
> Index: mod_dir.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/mappers/mod_dir.c,v
> retrieving revision 1.30
> diff -u -d -b -w -u -r1.30 mod_dir.c
> --- mod_dir.c 2001/02/21 17:54:41 1.30
> +++ mod_dir.c 2001/02/24 17:45:50
> @@ -118,15 +118,11 @@
>
> static int fixup_dir(request_rec *r)
> {
> - dir_config_rec *d;
> -
> if (r->finfo.filetype != APR_DIR) {
> return DECLINED;
> }
> -
> - d = (dir_config_rec *) ap_get_module_config(r->per_dir_config,
> - &dir_module);
>
> + if (r->method_number == M_GET) {
> if (r->uri[0] == '\0' || r->uri[strlen(r->uri) - 1] != '/') {
> char *ifile;
> if (r->args != NULL)
> @@ -141,6 +137,8 @@
> return HTTP_MOVED_PERMANENTLY;
> }
> return OK;
> + }
> + return DECLINED;
> }
>
> static int handle_dir(request_rec *r)
>
> Ryan
>
>
> On Sat, 24 Feb 2001, Greg Stein wrote:
>
> > The mod_dir changes have seriously busted WebDAV handling in Apache.
> >
> > Let's say that I go into Windows Explorer and add a Web Folder. One of the
> > first things it does is an OPTIONS request against the directory. However,
> > it leaves off the trailing slash. The latest Apache 2.0 returns a 301 to
> > tell the client to use a slash. However, Web Folders doesn't understand a
> > 301 in this case, so it basically says "sorry. no DAV there."
> >
> >
> > I'm not sure what the right solution here is (in the middle of other stuff,
> > then some sleep), but I think we need to back off on the redirects.
> >
> > For now, I've just #if 0'd the fixup_dir() function in mod_dir.c (in my
> > working copy). We'll need to fix this before the next tag/roll.
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
> >
> >
>
>
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/