httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: URIs again
Date Tue, 03 Mar 1998 01:21:37 GMT
I moved into an on-campus apartment on Sunday. The good news is that it
has a direct 10Mb/s connection to the Internet.  The bad news is that my
new bed won't arrive til Thursday (ouch).

>Roy, RFC2068 3.2.1 defines absoluteURI like so: 
>    absoluteURI    = scheme ":" *( uchar | reserved )
>That is, it's opaque.  Nowhere else in the document does it actually
>define what comes after the scheme.  It's obvious the intention is
>    absoluteURI    = scheme ":" relativeURI
>at least as far as parsing proxy requests go.

Yep.  The two are syntactically equivalent.

>Also interesting is the relativeURI definition:
>          relativeURI    = net_path | abs_path | rel_path
>          net_path       = "//" net_loc [ abs_path ]
>          abs_path       = "/" rel_path
>          rel_path       = [ path ] [ ";" params ] [ "?" query ]
>But no meaning is given to net_loc, other than in 5.1.2 where
>it defines Host: as the contents of net_loc.  Consider:
>    GET //hostname/path HTTP/1.1
>    Host: hostname
>It's a relativeURI, and so Apache doesn't proxy it or do vhosting
>on it.  Apache won't serve /path, it will essentially fail to serve
>//hostname/path.  Apache will also improperly handle URIs such as
>"//abc/../def".  In general right now I'm confused about URLs without

Ummm, those are not allowed in HTTP.  See the definition of Request-URI.
It should be treated as an abs_path.

>Another tidbit... are these valid Location response headers?
>    Location: http:foobar.gif
>    Location: http:/foobar.gif

Yes, but they are invalid http URLs.  The http URL does require net_path.
I know that libwww-based browsers will treat those as relative (due to
a stupid loophole in the original specs/code that assumed that all URLs
would have the net_loc (server) component).

>They seem to be given what I read in draft-fielding-url-syntax-09, but
>I know that some clients choke on them (lynx in particular).  RFC2068
>requires an absoluteURI response, and those fit that description since
>absoluteURI is opaque.

draft-fielding-uri-syntax-01 is the current spec (02 tomorrow), but both
disallow the "http:foobar.gif is relative" interpretation.

>And in a related manner, if a document's base url is
>"http://abc/def/foo.html", can it refer to "https:blah.gif"?  (and expect
>to get "https://abc/def/blah.gif")

No, that will fail (except maybe in Navigator, which has a random parser).


View raw message