Absolute rather than relative times in expires directives

Server NGINX
1

Hi,

I have a static HTML page that is updated at midnight each day. So I’d
like to set its expires directive to an absolute
rather than a relative time.

I was thinking of something like

expires at <crontab-line>

e.g. expires at 0 0 * * *

My questions:

  • Is there an existing solution?
  • If not, is anyone working, or planning to work, on one?
  • If not, would I have to write a core patch, or could it be done in
    an extension?
  • If a core patch, is there a good chance it would be accepted?
  • Can anyone suggest a better way than the above?

Perhaps I should just rely on mtime etags
(GitHub - mikewest/nginx-static-etags: Nginx doesn't generate etags for static content. I'd like it to. Let's see if I can remember some C from college.), and handle the extra
requests
and 304 responses.

Mark

2

01.08.2010, 13:23, “Mark J.” [email protected]:

My questions:

ššš- Is there an existing solution?

Yes:
expires @23h59m;

–
br, Denis F. Latypoff.

3

On 08/01/10 19:51, Denis F. Latypoff wrote:

01.08.2010, 13:23, "Mark J."[email protected]:

I have a static HTML page that is updated at midnight each day. So I’d like to set its expires directive to an absolute
rather than a relative time.
Yes:
expires @23h59m;

Thanks Denis!

That form of the expires directive wasn’t in the English documentation
at Module ngx_http_headers_module .

I’ve re-written the English documentation for the expires directive as
best I could, which included adding the “@” and
“modified” forms that were only in the Russian doc.

4

On Sun, Aug 01, 2010 at 09:57:16AM -0500, Ryan M. wrote:

š š expires @23h59m;

Obviously, adding any RFC-compliant Cache-Control directive would be
desirable. The “public” keyword in particular is needed to allow
Firefox to cache images and the like which are delivered over SSL, and
“private” is clearly desirable for caching per-user information.
Others like “must-revalidate” are less useful in the general sense.

If this isn’t possible with the current implementation, please let me
know and I will take a look at trying to make a simple patch (my first
foray into nginx source instructed me that my C skills are way too
rusty for deep modification or module-writing with nginx).

These directives

expires @24h00m;
add_header Cache-Control private;

return

Expires: Sun, 01 Aug 2010 20:00:00 GMT
Cache-Control: max-age=14809
Cache-Control: private

–
Igor S.
http://sysoev.ru/en/

5

2010/8/1 Igor S. [email protected]:

These directives

expires   @24h00m;
add_header  Cache-Control  private;

return

Expires: Sun, 01 Aug 2010 20:00:00 GMT
Cache-Control: max-age=14809
Cache-Control: private

Hmm… multiple Cache-Control header lines appear to be valid
according to RFC 2616, but my fear would be that many popular browsers
and caches would not behave sensibly with them.

Is anybody out there using multiple Cache-Control header lines for a
public site in production?

I did some research looking at the HTTP headers used by the “major”
web companies (Google, MSFT, Yahoo, etc.). I haven’t ever seen
multiple Cache-Control header lines in a response, which makes me
think that such a scenario is probably not well-supported by common
browsers and proxies. In my past experience, Firefox treats just about
anything except “public”,“private”, or “max-age” as “no-cache”. IE8
seems to do the same, which I suppose is a safe default behavior if
you don’t want to fully implement all the logic necessary to support
all the allowable header combinations in the RFC.

–
RPM

6

On Sun, Aug 1, 2010 at 6:39 AM, Mark J. [email protected]
wrote:

Thanks Denis!

That form of the expires directive wasn’t in the English documentation at
Module ngx_http_headers_module .

I’ve re-written the English documentation for the expires directive as best
I could, which included adding the “@” and “modified” forms that were only
in the Russian doc.

It’s not in the English or Russian documentation, but is it possible
to add any other Cache-Control directives along with expires?

For example, if you want “Cache-Control: private,max-age=300” you need
to do it manually with add_header instead of expires. But then you
lose the ability to use the other “calculation” features of expires
(like modified or @). You also don’t get an actual “Expires” header
for HTTP/1.0 clients and proxies if you have to use add_header
instead.

Obviously, adding any RFC-compliant Cache-Control directive would be
desirable. The “public” keyword in particular is needed to allow
Firefox to cache images and the like which are delivered over SSL, and
“private” is clearly desirable for caching per-user information.
Others like “must-revalidate” are less useful in the general sense.

If this isn’t possible with the current implementation, please let me
know and I will take a look at trying to make a simple patch (my first
foray into nginx source instructed me that my C skills are way too
rusty for deep modification or module-writing with nginx).

–
RPM

7

On Thu, Jan 21, 2016 at 02:19:03AM -0500, rgrraj wrote:

Hi there,

It works fine in 1.9.6. But on 1.9.2 with similar configruation its throwing
“expires” directive invalid value in sites-enabled file.
Any thoughts ?

“Use 1.9.6” would seem to be the easy option.

Failing that: what is the small configuration that does not do what you
want in 1.9.2?

Copy-paste enough so that someone else can reproduce the problem that
you are reporting.

Cheers,

f

Francis D. [email protected]

8

HI Francis

Thanks for the same.

It works fine in 1.9.6. But on 1.9.2 with similar configruation its
throwing
“expires” directive invalid value in sites-enabled file.
Any thoughts ?

Thanks
Govind

Posted at Nginx Forum:

9

Hi Francis

The same works like a charm in 1.9.6 but not in 1.9.2. The error log
shows
the follow,

“[emerg] 6151#0: “expires” directive invalid value in” respective sites
enabled file.

And our configuration is just as follows,

in nginx.conf

map $time_iso8601 $expiresc {
default “3h”;
~T22 “@00h00”;
~T23 “@00h00”;
}

##in sites enabled file,
location /path/to/files/ {
expires $expiresc;
}

doesnt allows to restart nginx and fails with the above error in nginx
error
log.

Any thoughts ??

Thanks
Govind

Posted at Nginx Forum:

10

Hello!

On Sun, Jan 24, 2016 at 02:21:01AM -0500, rgrraj wrote:

map $time_iso8601 $expiresc {

doesnt allows to restart nginx and fails with the above error in nginx error
log.

The message suggests that you are using not 1.9.2, but an older
version without variables support in the expires directive.

Variables support in the expires directive was introduced in nginx
1.7.9, see Module ngx_http_headers_module.

–
Maxim D.
http://nginx.org/

11

http://nginx.org/en/CHANGES:
Changes with nginx 1.9.7 17 Nov
2015
…
*) Bugfix: the “expires” directive might not work when using
variables.

Using the latest version of the branch​ might solve problems…

B. R.

12

Hi

Thank you all for the suggestions and thoughts.

I did double check the nginx version I am having and it is 1.9.2.
root@ser2:~# nginx -V
nginx version: nginx/1.9.2
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
configure arguments:
–add-module=/tmp/nginx/ngx_http_substitutions_filter_module-master
–add-module=/tmp/nginx/headers-more-nginx-module-0.26
–add-module=/tmp/nginx/ngx_pagespeed-release-1.9.32.3-beta
–sbin-path=/usr/local/sbin/nginx --conf-path=/etc/nginx/nginx.conf
root@ser2:~#

but when I use the expires directive it shows invalid error same as
before.

Seems like to get the feature I need to update the nginx version.

Thanks
Govind

Posted at Nginx Forum:

13

On Mon, Feb 01, 2016 at 12:24:22AM -0500, rgrraj wrote:

Hi there,

Thank you all for the suggestions and thoughts.

I did double check the nginx version I am having and it is 1.9.2.

but when I use the expires directive it shows invalid error same as before.

Seems like to get the feature I need to update the nginx version.

All I can say is: it works for me.

“http” section of nginx.conf:

===
http {
map $time_iso8601 $expiresc {
default “3h”;
~T22 “@00h00”;
~T23 “@00h00”;
}

server {
    listen       8080;
    location /a/ {
        expires     $expiresc;
    }
}

}

Selected output from

$ curl -i http://127.0.0.1:8080/a/b

HTTP/1.1 200 OK
Server: nginx/1.9.2
Date: Mon, 01 Feb 2016 09:09:06 GMT
Expires: Mon, 01 Feb 2016 12:09:06 GMT
Cache-Control: max-age=10800

If you get different output, it may be worth investigating properly what
is happening.

But it may be simpler to just deploy your tested-working version.

Good luck with it,

f

Francis D. [email protected]

14

Hello!

On Mon, Feb 01, 2016 at 12:24:22AM -0500, rgrraj wrote:

–add-module=/tmp/nginx/headers-more-nginx-module-0.26
–add-module=/tmp/nginx/ngx_pagespeed-release-1.9.32.3-beta
–sbin-path=/usr/local/sbin/nginx --conf-path=/etc/nginx/nginx.conf
root@ser2:~#

but when I use the expires directive it shows invalid error same as before.

This likely means that nginx you are checking for “nginx -V” is
not the same as one that really works. This may happen if you
have more than one nginx binary (e.g., one in /usr/, and another
one in /usr/local), or you haven’t restarted/upgraded running
nginx binary after upgrading nginx on disk, see here:

http://nginx.org/en/docs/control.html#upgrade

–
Maxim D.
http://nginx.org/