- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sun, 18 Dec 2011 12:47:14 +1300
- 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. AYJ
Received on Saturday, 17 December 2011 23:48:19 UTC