W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p1: BWS

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 19 Apr 2013 11:34:59 +0200
Message-ID: <51710FC3.9060200@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Roberto Peon <grmocg@gmail.com>, Willy Tarreau <w@1wt.eu>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On 2013-04-19 00:27, Mark Nottingham wrote:
> We can either:
> - make it a MUST
> - document what the exceptional circumstances are that cause the SHOULD (but I don't think it's that kind of SHOULD)
> - downgrade it to an "ought to"
> I do note that we say "generate" there (which I missed before, sorry); in our terminology, that means you DON'T need to fix it up when forwarding it; it's only when you're actually creating the element that this applies.
> So, I'd suggest we make it a MUST, and change the language slightly to clarify:
> "...but it MUST NOT be generated in messages..."

I have no problem with *that* change.

What concerns we much more is the "MUST accept such bad optional 
whitespace and remove it before interpreting the field value or 
forwarding the message downstream" -- that part is fine for parsing the 
message itself (everybody needs to be able to do that), but *not* ok for 
individual field values. We need a distinction here.

> Also, in p2, I'd note that we do NOT allow BWS inside of media type parameters:
>    https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#media.type
> AIUI (thanks, Julian), this is because many implementations don't accept whitespace there at all. It might be worth noting in the text that this parameter construct is different in that aspect.

I don't know whether it's because of implementations following the spec, 
or the spec following implementations.

Somewhat outdated tests are over here: 

I'm more than happy to require recipients to handle BWS here for 
consistency with other header fields, as long as we tell generators to 
never ever use it.

Best regards, Julian
Received on Friday, 19 April 2013 09:35:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC