[PATCH 2/2] Add std.rfc1123() to convert a formatted datetime to VCL_TIME
Dridi Boukelmoune
dridi.boukelmoune at zenika.com
Mon Dec 15 22:51:07 CET 2014
Hi,
As I've hit the same questions on an unrelated project, and changed my
mind even though I reasonned like Federico initlially, I thought I could
give my two cents. I'm also referring to the RFC 2616 because I haven't
found time to go through the new ones yet, let me know if this particular
concern has changed.
On Mon, Dec 15, 2014 at 9:12 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> --------
> In message <CAJV_h0YFuL+OMcFckxAd+D9noX__aPRyLK17WA4m5Cm6f-XdQg at mail.gmail.com>
> , Federico Schwindt writes:
>
>>I thought about this and decided to go for rfc1123() as time() would
>>indicate a TIME input with .integer(), .ip() and .real().
I would go with "date" because in the RFC's grammar (3.3.1) it's
called an "HTTP-date".
HTTP-date = rfc1123-date | rfc850-date | asctime-date
> I simply don't grok that.
>
> The idea behind the conversion functions is
>
> std.${typename}(${convert_this}, ${use_this_if_you_cant})
>
> Nothing prevents
>
> std.time("Mon Dec 15 20:11:04 UTC 2014", std.now())
> and
> std.time("1418674264", std.now())
>
> from giving the same result ?
It actually should (ish) do that. Again, the RFC (3.3.1) follows the
robustness principle and accepts all three date formats for parsing,
but allows only rfc1123-date when generating. Arguably, this is
Varnish Cache and such a function could also accept any
Varnish-specific formats.
> HTTP/1.1 clients and servers that parse the date value MUST accept
> all three formats (for compatibility with HTTP/1.0), though they MUST
> only generate the RFC 1123 format for representing HTTP-date values
> in header fields. See section 19.3 for further information.
My two cents,
Dridi
>>The other options I had in mind were datetime() and date() but I liked
>>rfc1123() best.
>
> I really hate rfc1123 as a name...
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
More information about the varnish-dev
mailing list