Score:1

Server

NGINX SSI working fine, but LAST_MODIFIED returning "(none)"?

Dave Everitt

11/17/22, 11:41 AM

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.

123

1 + 0

nginx

server-side-includes

last-modified

Score:4

Server

mforsetti

11/20/22, 5:35 PM

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.

0 + 6

Michael Hampton

11/20/22, 7:17 PM

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.

mforsetti

11/20/22, 8:31 PM

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.

Dave Everitt

11/21/22, 7:20 AM

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.

mforsetti

11/21/22, 8:52 AM

@DaveEveritt I've edited my answer and adding a few details

Michael Hampton

11/21/22, 4:01 PM

@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.

Dave Everitt

11/24/22, 12:16 PM

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.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: NGINX SSI working fine, but LAST_MODIFIED returning "(none)"?

TH: NGINX SSI ทำงานได้ดี แต่ LAST_MODIFIED ส่งคืน "(ไม่มี)"

RO: NGINX SSI funcționează bine, dar LAST_MODIFIED returnează „(niciunul)”?

RU: NGINX SSI работает нормально, но LAST_MODIFIED возвращает «(нет)»?

VI: NGINX SSI hoạt động tốt, nhưng LAST_MODIFIED trả về "(không có)"?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.