Re: [apps-discuss] Fun with URLs and regex

["Roy T. Fielding" <[e-mail]>]

On Jan 28, 2015, at 3:59 PM, Matthew Kerwin wrote:

> On 29/01/2015, Julian Reschke <[e-mail]> wrote:
>> 
>> I agree that the fragment is part of the URI; the question, as far as I
>> understand, is whether the *scheme* definition should include the
>> fragment, given the fact that you can attach a fragment to any URI anyway.
>> 
> 
> The answer to this affects what I write in the 'file' scheme draft. I
> was advised early on to not mention fragments (which I took as
> "disallow by omission") because, while it's easy to define syntax, the
> scheme also has to define semantics, and fragment semantics are tied
> to content type, and dereferenced 'file' URIs don't have a
> well-defined content type.
> 
> Whether or not I mention it comes back to the definition and intended
> use-case of RFC 3986; if it defines an 'abstract' syntax - in the POO
> sense - then there's no such thing as a universal parser (i.e. It's
> impossible to parse a URI with an unknown scheme). If it defines a
> low-level structure, then any URI can be parsed, but the individual
> components can't be validated without deferring to scheme-specific
> machinery.
> 
> If the former and I don't include the fragment in 'file', it isn't
> allowed. If the latter, I just leave a hole in the spec.

It isn't that black and white.  The grammar for the scheme is what
excludes a fragment.  That doesn't prevent the scheme docs from
talking about fragments (in reference to RFC3986) and using them
within examples.

That part of the URI spec was written specifically to address
issues created by folks who thought they could redefine the meaning
of fragments within individual schemes, or forbid them entirely,
when in fact the meaning and use of fragments are independent of
scheme.

What makes you think that dereferenced files don't have a well-defined
content type?  The client might not know what it is, but that doesn't
mean the content type doesn't exist, and any decision to process the
file is basically an assumption of some content type (and its rules
for processing fragments).

....Roy