1

I have NGINX SSI working fine in the virtualHosts file (code below) but LAST_MODIFIED is returning "(none)", although the NGINX docs for SSI state that the ssi_last_modified directive appeared in version 1.5.1 (we’re running version 1.14.2).

VirtualHost file:

…
  location / {
    ssi on;
    ssi_last_modified on;
    …
  }
…

and in the .html file:

<!--#if expr="$footer_id='blackfooter'" --><div id="blackfooter"><!--#else --><div id="footer"><!--#endif -->
    <!--#config timefmt="%A %d %B %Y" --><p>Updated: <!--#echo var="LAST_MODIFIED" --> | Today: <!--#echo var="DATE_LOCAL" --></p>
</div>

So for now, I've resorted to JavaScript:

<!--#if expr="$footer_id='blackfooter'" --><footer id="blackfooter"><!--#else --><footer><!--#endif -->
    <!--#config timefmt="%A %d %B %Y" --><p>Updated: <span id="updated"></span> | Today: <!--#echo var="DATE_LOCAL" --></p>
</footer>
<script>
    let lastmod = new Date(document.lastModified);
    updated.innerHTML = lastmod.toString().substring(4,15);
</script>

Why is NGINX delivering other documented SSI functionality, but not LAST_MODIFIED in the header?

The only possible clue I found was that the sub_filter_last_modified is mentioned in the docs for the NGINX ngx_http_sub_module but AFAIK (and I'm not NGINX specialist) I'm not sure that helps much.

Dave Everitt
  • 181
  • 2
  • 11

1 Answers1

4

Why is NGINX delivering other documented SSI functionality, but not LAST_MODIFIED in the header?

Because nginx haven't fully implement SSI anyway. Quoting the docs:

Currently, the list of supported SSI commands is incomplete.

For a list of supported SSI commands and variables, check nginx's source here.


Edit:

If complete SSI support is desired, try using Apache httpd behind nginx.

according to the NGIX (sic) docs (see the link in my post)

Here's direct quote from ssi_last_modified docs circa July 21st, 2021:

Allows preserving the Last-Modified header field from the original response during SSI processing to facilitate response caching.

By default, the header field is removed as contents of the response are modified during processing and may contain dynamically generated elements or parts that are changed independently of the original response.

By default, when responding to a request for a static file, nginx adds Last-Modified HTTP response header.

When using SSI, nginx remove this header on purpose because nginx is generating the page dynamically instead of returning a static file, therefore adding a Last-Modified response header is pointless.

ssi_last_modified directive re-adds Last-Modified HTTP response header according to SSI script file timestamp.

In no way it said that this directive adds LAST_MODIFIED variable to nginx's SSI.

LAST_MODIFIED should still be supported

AFAIK, there's no standard, nor RFCs, that could be relied upon to completely implement SSI. Arguably, docs to mod_include could be such standard, but again, it's only a manual to another product. Let me know if there's such standard and I'll amend this answer.

You'll have better chance resolving this problem by submitting a feature request to nginx's Trac.

Tangent: even if it's supported, if you add LAST_MODIFIED, should its value be the timestamp of the SSI script, or server timestamp; since the HTML response is generated on-the-fly instead of directly read from a file.

This is for legacy sites I've moved across to NGINX from Apache. Some large sites still use SSI, and it's a useful lightweight way approach, avoiding PHP etc.

I doubt those large sites still use SSI behind the scenes. At this point, SSI is a legacy framework with a lot of alternatives available.

mforsetti
  • 2,488
  • 2
  • 14
  • 20
  • 1
    Don't expect it to get added either. SSI is long-dead tech and I'm always surprised when I see someone attempting to use it. I was also a bit surprised that Igor ever added it to nginx at the beginning. It was dead even back then. – Michael Hampton Jul 20 '21 at 19:17
  • 1
    I do think SSI had its place in the past, especially since SSI is simple enough to use, and CGI didn't perform well in the first place (we're talking about pre-2000 here); though current levels of computing power and dynamics that can be delivered by *GIs (CGI, FastCGI, WSGI, etc) did put the final nail in the coffin for SSI. – mforsetti Jul 20 '21 at 20:31
  • Although it might not be as fully implemented as it is in Apache, according to the NGIX docs (see the link in my post) LAST_MODIFIED should still be supported, which is my question. This is for legacy sites I've moved across to NGINX from Apache. Some large sites still use SSI, and it's a useful lightweight way approach, avoiding PHP etc. – Dave Everitt Jul 21 '21 at 07:20
  • 1
    @DaveEveritt I've edited my answer and adding a few details – mforsetti Jul 21 '21 at 08:52
  • 1
    @DaveEveritt You have misread the docs. This option controls the Last-Modified response header, not any SSI directive. As for SSI, it had to be extremely lightweight because that's all a 486 or Pentium could handle and still manage to serve a web page in a reasonable (for the 1990s) amount of time. You must have some incredibly "legacy" sites. – Michael Hampton Jul 21 '21 at 16:01
  • Thanks for the clarification. With Apache, LAST_MODIFIED gave either the date the file containing the SSI was last updated, or the date an included file was updated, which is what I'm now getting with the JavaScript, so I'll keep using JS instead. – Dave Everitt Jul 24 '21 at 12:16