RE: [Technical Errata Reported] RFC7230 (5163)

>> By my definition, it wouldn't be generic anymore :-)-

Fair point :)

>> I agree with you about the intent, and that modifying OWS here would be harmless. Do we need to state that, and yes, what header fields are affected?

I think that would be useful. If the we did make such a statement, should it be in RFC7230 or elsewhere? Perhaps RFC7230 could say something like this (phrased perhaps too technically):
"If the ABNF for a header field's content includes RWS or OWS, this whitespace MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream."

For context, the reason this came up is that in Microsoft Azure Storage, certain header fields are canonicalized to be used in a cryptographic hash, and the canonocalized form normalizes this whitespace to a single SP to ensure the signature doesn't break when a proxy makes the kind of transformation formerly allowed under RFC 2616. Had this transformation not been permitted by the RFC, I suspect we would have left the inside of the string as-is when canonicalizing.
https://docs.microsoft.com/en-us/rest/api/storageservices/authentication-for-the-azure-storage-services

Thanks,

David

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Wednesday, 25 October 2017 10:48
To: David Matson <dmatson@microsoft.com>; RFC Errata System <rfc-editor@rfc-editor.org>; fielding@gbiv.com; ben@nostrum.com; aamelnikov@fastmail.fm; adam@nostrum.com; mnot@mnot.net; pmcmanus@mozilla.com
Cc: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7230 (5163)

On 2017-10-25 19:31, David Matson wrote:
> When generic code does know the ABNF of the header field, is it still 
> allowed to remove spaces in field values before processing/passing 
> downstream? If so, where should this behavior be documented as 
> permissible? (Is this something that each field now needs to document 
> separately?)

By my definition, it wouldn't be generic anymore :-)-

> (FWIW, the spec doesn't technically use OWS inside field-content; the 
> ABNF between field-vchar is equivalent to RWS, I believe.)

OWS appears as part of list productions, see <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.greenbytes.de%2Ftech%2Fwebdav%2Frfc7230.html%23abnf.extension&data=02%7C01%7Cdmatson%40microsoft.com%7C649df737b5a6487f6ebb08d51bd085d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636445504782504514&sdata=ACu9NO8NGmE5KuMNcEG5fwJKbD3NyzUQzZf13T7bwzU%3D&reserved=0>. It also appears in specific header fields, such as <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.greenbytes.de%2Ftech%2Fwebdav%2Frfc7231.html%23media.type&data=02%7C01%7Cdmatson%40microsoft.com%7C649df737b5a6487f6ebb08d51bd085d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636445504782504514&sdata=PpGHTLxqOhS1CHI3zy%2BVgBYzC6mb8pV8lY4TF7F%2FAWI%3D&reserved=0>...

> For example, if a proxy understands the ABNF of all the following headers and receives a response with Allow, Server, Vary, etc header fields set where there's more than one space separating items in the list, can it still normalize down to one space before passing the response back to the client? The Allow case is perhaps the most interesting - RFC 7231 specifically prohibits modifying the Allow header field, but I suspect the intent there is more around the list of methods rather than the whitespace characters between them.
> ...

Aha: 
<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.greenbytes.de%2Ftech%2Fwebdav%2Frfc7231.html%23rfc.section.7.4.1.p.4&data=02%7C01%7Cdmatson%40microsoft.com%7C649df737b5a6487f6ebb08d51bd085d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636445504782504514&sdata=bTGIQzF%2Fi5SKMKTO5iLtBZetQe%2B%2FflpskHvU6zMtQkc%3D&reserved=0>:

"A proxy MUST NOT modify the Allow header field — it does not need to understand all of the indicated methods in order to handle them according to the generic message handling rules."

I agree with you about the intent, and that modifying OWS here would be harmless. Do we need to state that, and yes, what header fields are affected?

Best regards, Julian

Received on Tuesday, 31 October 2017 07:30:31 UTC