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

On 27.02.2023 04:51, Mark Nottingham wrote:
>
>
>> On 27 Feb 2023, at 11:00 am, Martin Thomson <mt@lowentropy.net> wrote:
>>
>> Unwrapping the proposal:
>>
>>> 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), unless the field definition specifies another behavior. It is RECOMMENDED that fields not modify this requirement, as it enhances interoperability and safety.
>>
>> Can you speak more about the rationale behind this approach?
>>
>> I generally see SF as middleware in field processing.  That is, it performs a transformation from bytes into the abstract SF data model.  Field-specific processing can then be limited to describing how to consume an Integer or Dictionary or whatever.  This is a distinct advantage over classic field processing, where the entirety of processing is field-specific.
>>
>> A design choice we made with SF was to be strict.  That is, if SF processing fails, no output is produced.  This change allows fields to dabble: they can try SF processing and then back out if it doesn't work.
>
> Well, that's one option (which someone using retrofit might exercise, as you point out below). The more common one -- and what I think we discussed during 8941 -- was that ignoring the field might not be appropriate, depending on its semantics; e.g., it could have security implications, and the safest thing to do would not be to pretend the field doesn't exist, but to reject the message outright.
> ...

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.

Best regards, Julian

Received on Monday, 27 February 2023 13:11:39 UTC