Re: [Technical Errata Reported] RFC7230 (5163)

Hi David,

Feel free to file it here:
  https://github.com/httpwg/http-core/issues

Cheers,


> On 6 Apr 2018, at 12:54 pm, David Matson <dmatson@microsoft.com> wrote:
> 
> 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
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 9 April 2018 01:15:56 UTC