Re: [art] Question regarding RFC 8089

[Matthew Kerwin <[e-mail]>]

On Tue, 18 Dec 2018 at 03:15, Stephan Bergmann <[e-mail]> wrote:
>
> Is it intentionally so that file URIs do not support neither a query nor
> a fragment part?  At least, that is how I read RFC 8089 section 2 in
> combination with RFC 3986 section 3.
>

I would say: a bit yes, a bit no. There was definitely no support for
query or fragment in RFC 1630 nor 1738, and we never explicitly
*added* support in 8089.

The two goals of RFC 8089 were: to publish an RFC for file URIs with
unambiguous status, and to align the syntax/definition with RFC 3986.

According to the letter of the law (i.e. RFC 3986): "The query
component contains non-hierarchical data that, along with data in the
path component, serves to identify a resource..."  So as far as
aligning with that definition, it wouldn't have made sense to add a
query component.  Files are identified by purely hierarchical data.

As to the fragment, it's a bit murky, but the way I read RFC 3986,
section 3.5, "The fragment's format and resolution is ... dependent on
the media type of a potentially retrieved representation..." Since the
resource representation retrieved by dereferencing a file URI doesn't
have a media type (heuristics notwithstanding) it doesn't make sense
to include a fragment component in the URI scheme, since it would
always be undefined.

All that said, file URI syntax is now a subset of the generic syntax,
so you're technically able to parse a file URI with query and/or
fragment components.  If that's useful for you -- e.g. if you are
confident that your media type heuristics are good enough to make
fragment components workable -- then nothing stops you.  Clearly the
browsers support it; although I don't know what it would mean for
something like cURL or urllib to have to deal with a query component,
so I don't know how it could be added to the scheme definition.  You
could always just go with https://url.spec.whatwg.org/ instead...

A little bit of whataboutism occurs to me: what about data URIs?  They
*do* have media type information, but don't define fragments in the
URI scheme.

>
> (Asking because it can occasionally be convenient to host HTML pages
> with "active content" that interacts with a URI's query part on a local
> file system, and try to access them from a browser with <file:/...?...>
> instead of <http://.../...?...> URIs.)
>

That is a good point.  It's the sort of thing that makes me start
asking deeply philosophical questions, like: what is a URI?  How much
of the URI is now consumed by the resource representation as well as
(instead of?) the scheme's protocol?

My instinctual feeling is that RFC 3986 is out of date.  Anyone up for
a rewrite?

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/