XSEC C++ lib requires references to be specified as: file:///sample.xml but, XSEC Java lib (and some other open source libs) requires references to be specified as: file:/sample.xml Java XSEC lib doesn't understand (can't find) references signed by XSEC C++ lib nor XSEC C++ lib understand XSEC Java lib format.
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.
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.