Re: Standards compliance versus compatibility

[Clarence (Andreas M. Schneider)]

Andreas Otte wrote:
> 
> and that would be "http://www.foo.bar/path/file;param?query#";
> or "http://www.foo.bar/path/file;param?query"; which are equivalent.

I used the '#' to make clear that "" in RFC 2396 means the same
as "#", i.e. no validation at the server and scrolling to the
top of the document (see section 4.2 for "", but the behavior
of "#" seems to be nowhere explicitly defined).

> But after reading Miles comments I'm not sure sure on any of the
> examples in RFC 2396 anymore.

Yes, I summarize what we get with a base URI
"http://www.foo.bar/path;param/file;param?query#ref"; now:

RFC 1808:

"file2"         "http://www.foo.bar/file2";
";param2"       "http://www.foo.bar/path;param2";
"?query2"       "http://www.foo.bar/path;param/file;param?query2";
""              "http://www.foo.bar/path;param/file;param?query#ref";

RFC 2396 (corrected, see Miles' post):

"file2"         "http://www.foo.bar/path;param/file2";
";param2"       "http://www.foo.bar/path;param/;param2";
"?query2"       "http://www.foo.bar/path;param/file;param?query2";
""              "http://www.foo.bar/path;param/file;param?query#";

Now we have this with RFC 2396:

- Parameters exist only syntactically. RFC 2396, G.4:

|   Extensive testing of current client applications demonstrated that
|   the majority of deployed systems do not use the ";" character to
|   indicate trailing parameter information, and that the presence of a
|   semicolon in a path segment does not affect the relative parsing of
|   that segment.  Therefore, parameters have been removed as a separate
|   component and may now appear in any path segment.  Their influence
|   has been removed from the algorithm for resolving a relative URI
|   reference.  The resolution examples in Appendix C have been modified
|   to reflect this change.

- If the scheme is omitted, it is inherited:
  "//www.foo2.bar/path2;param/file2;param?query2#ref2" ->
                "http://www.foo2.bar/path2;param/file2;param?query2#ref2";

- If the authority is omitted too, it is inherited:
  "/path2;param/file2;param?query2#ref2" ->
                "http://www.foo.bar/path2;param/file2;param?query2#ref2";

- If the path is omitted too, it is inherited:
  "file2;param?query2#ref2" ->
                "http://www.foo.bar/path;param/file2;param?query2#ref2";

- If the file name is omitted too, it is inherited:
  "?query2#ref2" ->
                "http://www.foo.bar/path;param/file;param?query2#ref2";

- If the query is omitted too, it is inherited:
  "#ref2" ->    "http://www.foo.bar/path;param/file;param?query#ref2";

- If the fragment is omitted too, it is the top of the document:
  "" ->         "http://www.foo.bar/path;param/file;param?query#";

Hmm, that last point seems not to be very logical. It was in RFC 1808.
RFC 2396 says in G.4:

|   RFC 1808 (Section 4) defined an empty URL reference (a reference
|   containing nothing aside from the fragment identifier) as being a
|   reference to the base URL.  Unfortunately, that definition could be
|   interpreted, upon selection of such a reference, as a new retrieval
|   action on that resource.  Since the normal intent of such references
|   is for the user agent to change its view of the current document to
|   the beginning of the specified fragment within that document, not to
|   make an additional request of the resource, a description of how to
|   correctly interpret an empty reference has been added in Section 4.

I doubt the "normal intent" is as described. Now we have 3 possible
solutions for resolving "" (if we want to follow RFC 2396):

1) Take RFC 2396 literally:
   "http://www.foo.bar/path;param/file;param?query#";

2) Follow the spirit of RFC 2396, i.e. do what the "normal intent" is:
   "http://www.foo.bar/path;param/";

3) Follow the logic used elsewhere in RFC 2396 (with the correction
   mentioned in 9kjgda$[EMAIL PROTECTED]">news:9kjgda$[EMAIL PROTECTED] ):
   "http://www.foo.bar/path;param/file;param?query#ref";

4) Fall back to RFC 1808 (same as (3))

(1) and (3) should not validate the document at the server.

I would now prefer (3), but it might be more reasonable to apply (2).
And if we want to conform strictly with RFC 2396, we should do (1).

Clarence