W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Re: [Technical Errata Reported] RFC7230 (5163)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 31 Oct 2017 10:09:08 +1100
Cc: David Matson <dmatson@microsoft.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Roy Fielding <fielding@gbiv.com>, "ben@nostrum.com" <ben@nostrum.com>, "aamelnikov@fastmail.fm" <aamelnikov@fastmail.fm>, "adam@nostrum.com" <adam@nostrum.com>, "pmcmanus@mozilla.com" <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <AA5BCCA2-5CCD-44AA-8074-CA474FBDA9A2@mnot.net>
To: "Julian F. Reschke" <julian.reschke@gmx.de>
I'd lean towards filing an issue.

> On 31 Oct 2017, at 12:49 am, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2017-10-25 20:04, David Matson wrote:
>>>> 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
>> ...
> We probably should clarify
>  https://www.greenbytes.de/tech/webdav/rfc7230.html#rule.OWS
> with statements about what kind of rewriting is allowed. And, for
>  https://www.greenbytes.de/tech/webdav/rfc7231.html#header.allow
> we need to clarify that "MUST NOT modify" doesn't apply to the *WS rewriting we allow in general.
> Chairs: should we handle that as erratum or just add it to <https://github.com/httpwg/http11bis/issues>?
> Best regards, Julian

Mark Nottingham   https://www.mnot.net/
Received on Monday, 30 October 2017 23:09:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:11 UTC