- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 21 Oct 2014 12:20:16 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Roberto Peon <grmocg@gmail.com>, Mark Nottingham <mnot@mnot.net>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Oct 21, 2014 at 12:02:39PM +0200, Julian Reschke wrote: > On 2014-10-21 11:44, Willy Tarreau wrote: > >... > >I know, and you remember, that was one of the basic points of our > >proposal 2 years ago. I think we'll hardly propose this here since > >it changes the ability to pass certain invalid values. However, I > > ... > > Right. But maybe we could try something the represents valid values > well, but still allows transporting invalid values? I hadn't thought about that option honnestly and I find that it could be very efficient and even save a lot of CPU by avoiding to process anything complicated or out of range. I mean, if the date respects a very precise format, we encode it and transport it in binary. Otherwise we leave it in plain text mode. We can have an encoding starting with something impossible in text mode (eg: LF byte) to mark that what follows is a 32-bit binary encoding of a timestamp. A variable-length encoding would allow to pass end of the current epoch and to use less bytes currently. This method would even be compatible with existing encoding and parsers. Do you think it's still possible to propose something along this without conflicting with the goal of stabilizing changes ? Willy
Received on Tuesday, 21 October 2014 10:21:55 UTC