- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 28 Feb 2023 17:13:49 +1100
- To: "Julian F. Reschke" <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
I've updated the PR: https://github.com/httpwg/http-extensions/pull/2404/files We can't place a RFC2119 requirement on other documents; it will get dinged by the IESG/RFC Editor. 2119 is for implementations only. Cheers, > On 28 Feb 2023, at 4:52 pm, Julian Reschke <julian.reschke@gmx.de> wrote: > > On 28.02.2023 05:32, Mark Nottingham wrote: >> 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, > > WFM; but as PHK said we may want to tune the prose around "including > when calling another algorithm"... > > Best regards, Julian > -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 28 February 2023 06:14:26 UTC