On Tue, Jun 25, 2019 at 08:44:27PM -0500, Eric Blake wrote:
On 6/11/19 12:35 PM, Wouter Verhelst wrote:I think you're overthinking it here. We could just say that a client which does not recognize a parameter should just balk? After all, a URI is something that in most cases would be passed on the command line, or some such; the feedback to the user would be fairly quick. Additionally, I can't think of any extra feature that we might want to add to the URL but which might be optional...And RFC 3986 states: " When presented with a URI that violates one or more scheme-specific restrictions, the scheme-specific resolution process should flag the reference as an error rather than ignore the unused parts; doing so reduces the number of equivalent URIs and helps detect abuses of the generic syntax, which might indicate that the URI has been constructed to mislead the user (Section 7.6). " So recommending that clients reject a URI they cannot recognize is sane. It also turns out that RFC 3986 permits: nbd:unix:/path/to/socket as a valid URI in the nbd: scheme with no authority and a relative path (different than nbd+unix:///export?socket=/path/to/socket as a URI with an empty authority). However, I'd recommend that you document it as being a scheme-specific restriction that we require the scheme://[authority][/abs/path] form, especially since the former string (used by qemu prior to the introduction of its nbd+unix: scheme) can end up trying to connect over TCP to the export named 'unix:/path/to/socket' on localhost port 10809 rather than the intended connection to the empty string export at a Unix socket at '/path/to/socket'.
Thank you for formalizing the issue I faced. This could certainly be an issue, especially when nbd:unix:/path/to/socket is used in some programs.
If you are using libxml2 xmlParseURI, you can tell the difference on which form was used based on whether path is empty or begins with '/' (good) vs. beginning with anything else, prior to the step where we discard a leading '/'. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: PGP signature