[cc's trimmed]
kfogel@collab.net writes:
> "Sander Striker" <striker@apache.org> writes:
> > > - 8. Python 2.0
> > > + 8. Python 2.0 (http://www.python.org)
> >
> > http://www.python.org/
>
> Are you tacking on slashes? Is that important? (A serious question
> -- I never knew it made a difference.)
Absolutely. This is one of Greg's huge pet peeves--I'm surprised he
hasn't pontificated all over you about this at some point in the
past. :-)
If you don't pass a trailing slash, the webserver will respond to your
request with a 301 Moved Permanently, and then your browser will
make *another* request for the actual page. Watch this:
$ curl http://www.red-bean.com/sussman
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<hr />
<address>Apache/2.0.46 (Unix) DAV/2 SVN/0.23.0+ PHP/4.3.1 Server at www.red-bean.com Port 80</address>
</body></html>
$ curl http://www.red-bean.com/sussman/
<html>
<head>
<title>Homepage of Ben Collins-Sussman</title>
...
Surprised? Most people are.
RFC 2518 Says this:
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.
And I'm sure that's waaaaaaay more than you really wanted to know.
-Fitz
--
Brian W. Fitzpatrick <fitz_at_red-bean.com> http://www.red-bean.com/fitz/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 17 06:51:49 2003