Re: Structured Fields: strict error handling (#2399)

Hi Julian,

> On 28 Feb 2023, at 12:11 am, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> FWIW, that would make the error handling *more* draconian; which I'm
> totally happy with.
> 
> A simpler way to express this would be to replace
> 
> > If parsing fails -- including when calling another algorithm -- the
> entire field value MUST be ignored (i.e., treated as if the field were
> not present in the section). This is intentionally strict, to improve
> interoperability and safety, and specifications referencing this
> document are not allowed to loosen this requirement.
> 
> by
> 
> > If parsing fails -- including when calling another algorithm -- the
> entire field value MUST be ignored (i.e., treated as if the field were
> not present in the section), or alternatively the complete HTTP message
> MUST be treated as malformed. This is intentionally strict, to improve
> interoperability and safety, and specifications referencing this
> document are not allowed to loosen this requirement.

That conflates parsing for the purpose of processing a header block to handle a HTTP message with other use cases, like parsing it to optimistically use a different wire encoding (see binary structured fields) or parsing it to canonicalise it (see signatures). Allowing these uses is one of the primary purposes of retrofit.

How about:

> If parsing fails -- including when calling another algorithm -- either the entire field value MUST be ignored (i.e., treated as if the field were not present in the section), or alternatively the complete HTTP message MUST be treated as malformed. This is intentionally strict to improve interoperability and safety, and field specifications that use Structured Fields are not allowed to loosen this requirement.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 28 February 2023 04:32:55 UTC