- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 30 Oct 2017 14:49:13 +0100
- To: David Matson <dmatson@microsoft.com>, RFC Errata System <rfc-editor@rfc-editor.org>, "fielding@gbiv.com" <fielding@gbiv.com>, "ben@nostrum.com" <ben@nostrum.com>, "aamelnikov@fastmail.fm" <aamelnikov@fastmail.fm>, "adam@nostrum.com" <adam@nostrum.com>, "mnot@mnot.net" <mnot@mnot.net>, "pmcmanus@mozilla.com" <pmcmanus@mozilla.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Monday, 30 October 2017 13:50:08 UTC