Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: C++ 1.2.0
    • Fix Version/s: None
    • Component/s: C++
    • Security Level: Public (Public issues, viewable by everyone)
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: Other

      Description

      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.

        Activity

        Hide
        Jesse Pelton added a comment -

        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.

        Show
        Jesse Pelton added a comment - 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.
        Hide
        Berin Lautenbach added a comment -

        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://

        Show
        Berin Lautenbach added a comment - 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://
        Hide
        Jesse Pelton added a comment -

        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.

        Show
        Jesse Pelton added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Milan Tomic
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development