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

Re: #327: Expect syntax

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Sun, 18 Dec 2011 12:47:14 +1300
Message-ID: <4EED2A02.50900@treenet.co.nz>
To: ietf-http-wg@w3.org
On 18/12/2011 11:25 a.m., Willy Tarreau wrote:
> On Sat, Dec 17, 2011 at 11:01:14PM +0100, Julian Reschke wrote:
>>> Well, it's possible that in a few years we see new implementations write
>>> their Expect header as $expectation ";" $extension but by this time, server
>> Example?
> I basically mean this (sorry for the poor naming above) :
>    int make_header(char *out, const char *hdr, const char *name, const char *value)
>    {
> 	return sprintf(out, "%s: %s; %s\r\n", hdr, name, value);

At which point the authors gets breakage reports and someone points out 
it should have been:

   return sprintf(out, "%s: %s%s%s\r\n", hdr, name, (*value?";":""), value);

Which is both less bandwidth and more compliant across all headers. 
Including those which use ';' as delimiter between names and those which 
dont permit parameters.

>    }
> and further in the code :
>    if (post_request)
>        req += make_header(req, "Expect", "100-continue", "");
> Which will result exactly in this, which was not possible in 2616 :
>    "Expect: 100-continue; \r\n"
> That said, since Expect is only used with 100-continue, we could add
> a line indicating that previous versions did not allow the trailing
> semi-colon and that senders should avoid emitting it for the sake of
> interoperability.

Which is a bit doubtful on the need. Under that same reasoning every 
other header BNF would need a similar statement about things which 
*might* be sent but not accepted by all receivers? I think its not a 
good idea to go down that road. The worst that would happen here is 417 
responses to broken sender software.

Received on Saturday, 17 December 2011 23:48:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC