- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 23 Aug 2022 15:59:41 +0200
- To: Tommy Pauly <tpauly@apple.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Roberto Polli <robipolli@gmail.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Aug 23, 2022 at 06:27:14AM -0700, Tommy Pauly wrote: > I imagine it's also a lot easier to translate *to* the human readable / > localized format for a date from the number, since the number is an > unambiguous form. Parsing dates the other way (from human readable to machine > readable) is where much of the complexity and ambiguity arises, so a scheme > that only requires transformations in one direction seems preferable. It's the most important aspect here IMHO: almost no error processing is needed on a scalar. Complex fields require complex processing. Many of us have been used to stuffing this in their scripts: $ date -d "1970-01-01 00:00:$(EPOCH)" to convert an EPOCH date to human-readable in the past, and it was quite an ugly way to abuse a lack of control to do something useful, making sure that once this bug would be plugged it would break such scripts. But the equivalent impact in an HTTP field is a problem as we can easily imagine tools validating a date using a regex and ignoring the time for example, leaving some room for such stuff to be easy to abuse on simple implementations. As such, whenever I have the choice of input format between a simple atol() and tokenizing elements that I need to feed to localtime() or gmtime(), I do have a very strong preference for the former. Regards, Willy
Received on Tuesday, 23 August 2022 14:00:07 UTC