On 6/11/19 11:31 AM, Eric Blake wrote: >> What I thought of would be another parameter that would specify which other >> parameters must be supported, so that the client quits if any of them is >> unknown. On the other hand it should be perfectly fine to make sure new >> enough >> version of the client is used. > > So, you're asking for some way to know that ?foo=bar is supported by the > client, by having a way to fail if the client doesn't know how to parse > the foo query. What if we document mandatory support for a parameter > '?features=comma,list,of,names', where a client MUST fail to parse the > URI if it does not recognize one of the feature names from the list > given to features? Then we can have: > > nbd://host/?foo=bar > - okay to ignore query foo= as unknown > nbd://host/?foo=bar&features=foo > - client MUST fail to parse URI unless it also knows how to parse the > foo query parameter > > The initial set of features mandated by the NBD URI spec is 'features' > for self-description, as well as 'socket' for Unix but not necessarily > TCP. Then the queries '?features=' and '?features=features' must both > succeed, the query '?features=socket' depends on the scheme, and any > other '?features=...' query becomes a feature probe. We could also reserve feature 'fail' as something that MUST NOT be recognized as a query parameter name, to use 'nbd://host/?features=fail' as a way to probe whether a client correctly rejects unknown features. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature