Bug 34937 - File resolvers (references)
Summary: File resolvers (references)
Status: NEW
Alias: None
Product: Security - Now in JIRA
Classification: Unclassified
Component: Signature (show other bugs)
Version: C++ 1.2.0
Hardware: Other Windows XP
: P2 major
Target Milestone: ---
Assignee: XML Security Developers Mailing List
Depends on:
Reported: 2005-05-16 16:44 UTC by Milan Tomic
Modified: 2005-05-19 07:13 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Milan Tomic 2005-05-16 16:44:18 UTC
XSEC C++ lib requires references to be specified as:


but, XSEC Java lib (and some other open source libs) requires references to be
specified as:


Java XSEC lib doesn't understand (can't find) references signed by XSEC C++ lib
nor XSEC C++ lib understand XSEC Java lib format.
Comment 1 Jesse Pelton 2005-05-16 21:14:13 UTC
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.
Comment 2 Berin Lautenbach 2005-05-19 13:31:24 UTC
Interesting read at:


Having a look around, I believe that file:/// is correct.  But maybe we can work
some smarts in to also accept file:/ and file://
Comment 3 Jesse Pelton 2005-05-19 15:13:14 UTC
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.