URIs again

[Dean Gaudet <dg...@arctic.org>]

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
this:

    absoluteURI    = scheme ":" relativeURI

at least as far as parsing proxy requests go.

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
schemes.

Another tidbit... are these valid Location response headers?

    Location: http:foobar.gif
    Location: http:/foobar.gif

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.

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")

Dean