Activity

If I understand it correctly, RFC 3986 (like RFC 2396 before it) mandates (or at
least strongly suggests) in section 3 at least two slashes after the scheme
component ("file:" in this case) of a URI. The third, which precedes the URI's
absolute path, also marks the end of any "authority" (a domain or subdomain in
HTTP URLs). Furthermore, RFC 3986 uses "file:///etc/hosts" as an example URI in
section 1.1.

So it looks to me like "file:/sample.xml" is an invalid URI. If this is
correct, the obvious questions are 1) how to get non-conformant implementations
conformant, and 2) what, if anything, XSEC C++ should do differently when it
gets an invalid URI.

Jesse Pelton
added a comment - 17/May/05 02:14 If I understand it correctly, RFC 3986 (like RFC 2396 before it) mandates (or at
least strongly suggests) in section 3 at least two slashes after the scheme
component ("file:" in this case) of a URI. The third, which precedes the URI's
absolute path, also marks the end of any "authority" (a domain or subdomain in
HTTP URLs). Furthermore, RFC 3986 uses "file:///etc/hosts" as an example URI in
section 1.1.
So it looks to me like "file:/sample.xml" is an invalid URI. If this is
correct, the obvious questions are 1) how to get non-conformant implementations
conformant, and 2) what, if anything, XSEC C++ should do differently when it
gets an invalid URI.
Of course, if my understanding is wrong, so are my questions.

Berin Lautenbach
added a comment - 19/May/05 18:31 Interesting read at:
http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-03.txt
Having a look around, I believe that file:/// is correct. But maybe we can work
some smarts in to also accept file:/ and file://

Interesting indeed. I came away shaking my head and thinking, "What a mess!"

Nice as it is to have the various current practices documented in one place, it
sure would be nice to have a little clearer guidance as to what to do for best
interoperability. Given the ambiguity, your proposal makes sense. "file:///"
appears to be preferred, so it should probably be used when generating file
URIs, but other forms are in use and ideally would be understood if received
from other sources.

Jesse Pelton
added a comment - 19/May/05 20:13 Interesting indeed. I came away shaking my head and thinking, "What a mess!"
Nice as it is to have the various current practices documented in one place, it
sure would be nice to have a little clearer guidance as to what to do for best
interoperability. Given the ambiguity, your proposal makes sense. "file:///"
appears to be preferred, so it should probably be used when generating file
URIs, but other forms are in use and ideally would be understood if received
from other sources.