- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 14 Apr 2016 21:32:59 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Mark Nottingham <mnot@mnot.net>, RFC Errata System <rfc-editor@rfc-editor.org>, Julian Reschke <julian.reschke@greenbytes.de>, Ben Campbell <ben@nostrum.com>, Alissa Cooper <alissa@cooperw.in>, Alexey Melnikov <aamelnikov@fastmail.fm>, Alex Rousskov <rousskov@measurement-factory.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Apr 14, 2016 at 12:20:12PM -0600, Roy T. Fielding wrote: (...) Thanks for the detailed history Roy! (...) > Apache httpd's chunk parser doesn't make use of chunk-ext unless it is bypassed > (i.e., a module can implement its own chunk parser). The core will allow up to > 10 bad whitespace between the chunk-size and chunk-ext (to allow for space-padding > of the chunk-size in fixed buffers), and then skip anything other than invalid > control chars between the ";" and the end of line; i.e., > > chunk-ext = 0*10<BWS> ";" *( OWS / VCHAR / ) > > IOW, that parser would support such a fix, but only by accident. In haproxy it's basically the same. It doesn't make any use of these extensions but happily skips these spaces if they are there. > I seriously doubt > we can assume that arbitrary HTTP implementations would expect whitespace in those > places. It was a stretch to expect that all implementations can handle chunk-ext, > but at least for that we had examples of how they would be implemented. At least now we have an indication that at least one user exists :-) > I don't have a problem with adding whitespace back in there, but I am not at all > confidant that such a choice would be less likely to break things. I don't want > to play errata ping pong. Well after all that's pretty much what the BWS was for : "you may have to accept it for improved backwards compatibility but you must not emit it". Regards, Willy
Received on Thursday, 14 April 2016 19:33:48 UTC