[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