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

Re: #327: Expect syntax

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 18 Dec 2011 00:57:53 +0100
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
Message-ID: <20111217235753.GG21202@1wt.eu>
On Sun, Dec 18, 2011 at 12:47:14PM +1300, Amos Jeffries wrote:
> 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.

I agree Amos, I was just showing an example of what naive code can look
like when applying a rule which (fortunately) becomes simpler, and where
it can break current software, eventhough arguably in a non-critical way.

> >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?

No, here we're changing what's allowed to be sent for a case where only
one single value was allowed. We should just get prepared for a few
isolated breakage reports. At least a referrer to the "changes from 2616"
would be nice. The worst thing with this spec is that it's so huge that
you can't imagine that other areas precise what you're reading hundreds
of pages later if you don't have any hint.

> 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.

No, not to broken sender software, to the ones implementing the new
standard the lazy way.

Received on Sunday, 18 December 2011 00:02:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC