(forget about this post...it seems to be the norm except when using specific caching scripts...and we are talking about milliseconds here for the raw html code itself)

I have observed that caching negotiation is "overridden" whenever an extensions is added to the XSSI Parameters, which I can understand. However, on many of my websites, XSSI is used to include headers, menus, etc. Therefore all my .htm and .html pages (or any extension that is added to the XSSI Parameters) then return a Cache-Control: no-cache which would be fine except that without a last modified it cannot be cached by a browser (or at least cached without re-validation.)

Is there any way around this? It is not a huge problem, but would be nice to have unmodified pages be able to return a 304. (Everything else returns a 304 and Abyss is great with this feature in all other regards. I have been able to specify charsets in the Content-Type, so I love the Abyss Custom HTTP Headers and File Expiration Times features!)

Maybe I am just missing something obvious about Cache Control in general?

XSSI is almost a full fledged language with conditional constructs. Output from an XSSI file can depend on the current date/time or on the output of an external command line program. That's why it can be difficult to compute the "last-modified" time of an XSSI generated page.

If the page is made of simple file includes, this shouldn't be complex. But of the page has if/the/else constructs or if it includes dates or system variables (that can change from invocation to invocation), caching is not an option.

We deliberately chose to simplify our implementation by disabling caching on all generated XSSI output. Our motivation is that XSSI was not popular and thus did not justify the investment in time to tweak its implementation.

But if at least one of our customers can benefit from such an advanced implementation, we'll improve it..._________________Support Team
Aprelium - http://www.aprelium.com

Well I wouldn't go to the trouble for "this" customer as I have realized it makes little difference in page speed or anything else. Most of my pages have a SSI for header and/or menu but the "last modified" is only is "inactive" in the html page source. Everything on the page that is "included" will show the 304 and "last modified" header. Since the html source code is miniscule compared to everything else (images, menus, javascript, css, etc., and those do carry the "last modified" and deliver a 304 server response) the raw html that does not carry the last modified amounts to a trivial savings.

I think you made the right choice in "We deliberately chose to simplify our implementation by disabling caching on all generated XSSI output."

I think you made the right choice in "We deliberately chose to simplify our implementation by disabling caching on all generated XSSI output."

That was probably simpler a few years ago but now that the software matured, it's probably time to go back and try to perfect all its subsystems._________________Support Team
Aprelium - http://www.aprelium.com