Search

That would be cool, for sure. But it wouldn’t be a bugfix release…

I am playing the devil’s advocate, reverting my statement from above: Wouldn’t the most “native” way be to simply include headers of/for the original file which has been uploaded? So we wouldn’t need any configuration. The developer should know what he is doing, and if browsers are doing some crazy caching, that should be fixed in the browser! And, BTW, I always found it somewhat curious that two URLs for an image won’t return the same headers:

  • /workspace/uploads/blabla.jpg
  • /image/uploads/blabla.jpg

The first URL will result in the server’s headers for this file, while the second one will answer using Symphony’s hardcore-no-cache headers.

I would love to hear some comments on this: How should the JIT extension handle this?

Now that is interesting..

The first URL will result in the server’s headers for this file, while the second one will answer using Symphony’s hardcore-no-cache headers.

  1. /workspace/uploads/blabla.jpg
  2. /image/uploads/blabla.jpg

Could this result in abnormal server load using the second method due to the files not being cached and being retrieved from fresh every page visit you think?

Closing this as discussion continues in JIT browser caching.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details