- From: Roy T. Fielding <fielding@apache.org>
- Date: Tue, 3 Jun 2003 18:45:13 -0700
- To: Rob Cameron <cameron@cs.sfu.ca>
- Cc: uri@w3c.org
> Read literally, the spec could be interpreted to mean that
> a new implementation of a nonvalidating parser should
> actually produce "backwards-compatible" behaviour.
Yes, that was a poor choice of words. What I wanted to say was
that an application testing for invalid links should consider
those references to be invalid because their interpretation will
be inconsistent.
> I'm wondering whether the intent is really to suggest
> that the behaviour that produces "http://a/b/c/g" is
> deprecated, but that implementors should be aware of this
> behaviour in older implementations.
A little more than that. Some browser implementations have
insisted that this behavior is necessary for backward compatibility,
even though it has a negative impact on parsing non-hierarchical
schemes. However, I've managed to tweak the algorithm for abnormal
reference parsing to fix that, so maybe we should just restore
the deprecated behavior.
For now, I have changed it to "strict" instead of "validating".
> I was also trying to track down the genesis of this behaviour
> in RFC 1630, but find only that in "the context of URI
> magic://a/b/c//d/e/f" g:h expands as g:h. Is there arother
> reference?
Where 1630 says:
The rules for the use of a partial name relative to the URI of the
context are:
If the scheme parts are different, the whole absolute URI must
be given. Otherwise, the scheme is omitted, and:
many implementations (including CERN/W3C libwww) interpreted that
as meaning the scheme parts are ignored if they are the same.
> Perhaps the algorithm of section 5.2 could be simplified,
> leaving the caveat on deprecated behaviour as a footnote.
The algorithm doesn't change much either way. What changes is
the number of applications that are compliant to the standard.
....Roy
Received on Tuesday, 3 June 2003 21:42:09 UTC