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

Julian Reschke writes:

>  > 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.

Works for me.

Although I still question the performative power of "not allowed to"
vs. a real SHALL NOT ?

If we adopt this form, it should be up front in 1.1 where we talk
about strictness.


	"-- including when calling another algorithm -- "

seems a confusing way to needlessly repeat what 1.1 says more clearly:

   This specification intentionally defines strict parsing and
   serialization behaviors using step-by-step algorithms; the only error
   handling defined is to fail the operation altogether.

And inserting "entire" before "operation" would make that even clearer.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Monday, 27 February 2023 13:28:27 UTC