I don't think that this is a result of a conscious decision -- feel free to fix it with a pull request!

- Demian

From: Joe Atzberger [joe@booksite.com]
Sent: Monday, April 21, 2014 5:23 PM
To: vufind-tech Tech
Subject: [VuFind-Tech] Cover image caching

One of the weirdest things about VuFind from a performance perspective is that the images themselves are delivered to the browser without reasonable cache durations.  For example:

https://library.villanova.edu/Find/Cover/Show?author=Howells%2C+Christina.&callnumber=B2430.D484&isn=0745611672&size=small&title=Derrida+%3A+deconstruction+from+phenomenology+to+ethics+%2F

The response is served with:

  1. Cache-Control:
    no-store, no-cache, must-revalidate, post-check=0, pre-check=0
  2. Connection:
    Keep-Alive
  3. Content-Length:
    2512
  4. Content-Type:
    image/jpeg
  5. Date:
    Mon, 21 Apr 2014 20:45:44 GMT
  6. Expires:
    Thu, 19 Nov 1981 08:52:00 GMT
  7. Keep-Alive:
    timeout=5, max=100
  8. Pragma:
    no-cache
  9. Server:
    Apache/2.2.18 (Unix) mod_ssl/2.2.18 OpenSSL/0.9.8e-fips-rhel5 PHP/5.3.27
  10. Set-Cookie:
    ui=standard; path=/
  11. X-Powered-By:
    PHP/5.3.27

That is pretty odd since image responses are large relative to text and very frequent (20+ per page). Is there are rationale for this?

The request includes a lot of fields now, apparently for a possible cover generation feature.  But client-side caching would still seem to make sense for that, arguably moreso.

Is this a privacy thing?  (seems paranoid, but could be handled with Cache-Control: private)
Is there a use case where cover images would actually be changing rapidly?
Or can I enable downstream caching by default and make everybody happy with their faster webpages?

--joe