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

Re: Structured Fields: whitespace in binary content

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 29 Oct 2020 13:56:01 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@varnish-cache.org>
Message-Id: <A1E1A91B-F125-4B39-83BD-E32EE913F8AC@mnot.net>
To: Roy Fielding <fielding@gbiv.com>
Hey Roy,

Yes, that's effectively what RFC 8792 wrapping does -- see previous message (with proposal).

If folks are OK with that approach I think we can avoid changing Structured Fields.

Cheers,


> On 29 Oct 2020, at 12:34 pm, Roy T. Fielding <fielding@gbiv.com> wrote:
> 
>> On Oct 28, 2020, at 1:23 AM, Mark Nottingham <mnot@mnot.net> wrote:
>> 
>> Structured Fields is in AUTH48 and we've addressed everything that's come up except for one very late entrant. I know this is very last minute, but I'm becoming convinced that this is something we should consider changing before shipping.
>> 
>> Background: I've written a script that validates HTTP messages in RFC XML, including Structured Fields. See:
>> https://pypi.org/project/rfc-http-validate/
>> 
>> Applying this to our current drafts, I encountered a problem; if a header field contains binary data, it's extremely likely that it will need to wrap across multiple lines to fit into the RFC. As a reminder, such folded lines are required by HTTP to be replaced by one or more spaces in <https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#field-values>.
>> 
>> For example, here is the PR for the Signature draft:
>> https://github.com/httpwg/http-extensions/pull/1319
>> 
>> At first I thought this could be addressed by an editorial note explaining that whitespace folding is different in examples. However, things like this make that unworkable:
>> 
>> ~~~ http-message
>> Signature-Input: sig1=(*request-target *created host date
>>    cache-control x-empty-header x-example); keyid="test-key-a";
>>    alg=hs2019; created=1402170695; expires=1402170995
>> Signature: sig1=:K2qGT5srn2OGbOIDzQ6kYT+ruaycnDAAUpKv+ePFfD0RAxn/1BUe
>>    Zx/Kdrq32DrfakQ6bPsvB9aqZqognNT6be4olHROIkeV879RrsrObury8L9SCEibe
>>   oHyqU/yCjphSmEdd7WD+zrchK57quskKwRefy2iEC5S2uAH0EPyOZKWlvbKmKu5q4
>>   CaB8X/I5/+HLZLGvDiezqi6/7p2Gngf5hwZ0lSdy39vyNMaaAT0tKo6nuVw0S1MVg
>>   1Q7MpWYZs0soHjttq0uLIA3DIbQfLiIvK6/l0BdWTU7+2uQj7lBkQAsFZHoA96ZZg
>>   FquQrXRlmYOh+Hx5D9fJkXcXe5tmAg==:
>> ~~~
>> 
>> As you can see, whitespace in folding is semantically significant in Signature-Input (if it's lost, delimitation will be lost too), whereas it needs to be removed for Signature to contain valid binary content.
>> 
>> So, the obvious fix is to allow whitespace inside binary content. Delimitation won't be lost, because it's ":" on both ends. The base64 parsers I checked already swallow whitespace in input (not surprising since the motivating use case for base64 was line-wrapped MIME).
> 
> That seems unnecessary to me. Just make the example very long lines
> and change the spec rendering tools to render a wrap that fits
> within the current view. The tools can provide a notation of
> their own to indicate that the folding isn't part of the value.
> 
> ....Roy

--
Mark Nottingham   https://www.mnot.net/
Received on Thursday, 29 October 2020 02:56:25 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 29 October 2020 02:56:26 UTC