Re: better documentation of zero-length option payloads?
On Mon, Oct 16, 2017 at 02:26:16PM -0500, Eric Blake wrote:
> The spec indirectly implies that NBD_OPT_LIST should be sent with a
> payload size of 0 (nothing in "Option types" mentions it, but
> NBD_REP_ERR_INVALID under "Option reply types" uses "an NBD_OPT_LIST
> with nonzero data length" as an example).
>
> Meanwhile, we have no mention of payload size for NBD_OPT_ABORT
> (presumably, for maximum compatibility, the client SHOULD use a payload
> of 0, but the server MUST ignore payload size altogether); nor for
> NBD_OPT_STARTTLS (presumably, the client MUST use a payload of 0, and
> the server MUST reject with an error an attempt to send starttls with
> payload - for matching existing practice).
>
> Similarly, for the structured-reply extension, NBD_OPT_STRUCTURED_REPLY
> documents "The option request has no additional data" - but does not
> phrase it in terms of a requirement on either client or server.
>
> Should we use consistent wording on all options that are sent without
> payload (with the possible exception of NBD_OPT_ABORT, since the desired
> behavior of quitting trumps diagnosing any invalid payload)?
Yeah, that sounds like a good idea; and since the implementations that I'm
aware of will not send payload for any of those options, telling servers
to do NBD_REP_ERR_INVALID at that point in time seems like the right
thing to do.
Will you write a patch?
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: