RE: [Technical Errata Reported] RFC7230 (5163)

Filing an issue sounds fine to me. Would it be best if one of the editors did so? 

Thanks,

David

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

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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Frest%2Fapi%2Fstorageservices%2Fauthentication-for-the-azure-storage-services&data=02%7C01%7Cdmatson%40microsoft.com%7C75fca3db7ca74d0fe0e008d51feb3c4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450017566625117&sdata=8A%2B0RGuYHYcXFeJrPK73WHJsmgRd01y%2BtDH%2FfWrNM5I%3D&reserved=0
>> ...
> 
> We probably should clarify
> 
>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.greenbytes.de%2Ftech%2Fwebdav%2Frfc7230.html%23rule.OWS&data=02%7C01%7Cdmatson%40microsoft.com%7C75fca3db7ca74d0fe0e008d51feb3c4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450017566781373&sdata=eNxVhuwSwZC6tBYybks28gghP%2FlRO%2FxVYiyuVz7rJ4w%3D&reserved=0
> 
> with statements about what kind of rewriting is allowed. And, for
> 
>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.greenbytes.de%2Ftech%2Fwebdav%2Frfc7231.html%23header.allow&data=02%7C01%7Cdmatson%40microsoft.com%7C75fca3db7ca74d0fe0e008d51feb3c4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450017566781373&sdata=ezmgssosA6XI8MdHsiPyydFs%2FTzDLDUZBg5urFQ3FtY%3D&reserved=0
> 
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp11bis%2Fissues&data=02%7C01%7Cdmatson%40microsoft.com%7C75fca3db7ca74d0fe0e008d51feb3c4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450017566781373&sdata=g37aJ305U0tLaVrtS%2BrahgQJEeuj4w7mZENfrNz9qHo%3D&reserved=0>?
> 
> Best regards, Julian
> 

--
Mark Nottingham   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cdmatson%40microsoft.com%7C75fca3db7ca74d0fe0e008d51feb3c4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450017566781373&sdata=qMJofCIcRJcFDqWYp%2BolSQtZ0iuRUQug52iQL2BZHOw%3D&reserved=0

Received on Friday, 6 April 2018 02:54:44 UTC