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'. 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: OpenPGP digital signature