Curl looks right. This is what I am seeing in Safari:
[cid:781F4D0B-0AD1-45AB-A2FB-35F1CC0DF717]
On 2015-01-23, 6:00 PM, "OC" wrote:
Chuck,
On 24. 1. 2015, at 2:53, Chuck Hill
mailto:ch...@gevityinc.com>> wrote:
I know that I have had this happen to me before with resources vended from the
Chuck,
On 24. 1. 2015, at 2:53, Chuck Hill wrote:
> I know that I have had this happen to me before with resources vended from
> the app. But mine was consistently wrong, not just from a browser.
> mod_expires was what popped into my head, but it might have been something
> else. It is als
I know that I have had this happen to me before with resources vended from the
app. But mine was consistently wrong, not just from a browser. mod_expires
was what popped into my head, but it might have been something else. It is
also possible that this behaviour is different in Apache 2.2 tha
P.S.
On 24. 1. 2015, at 2:32, Chuck Hill wrote:
> First guess would be your mod_expires configuration in Apache. Apache can,
> and will, override the headers that the app sends.
> http://httpd.apache.org/docs/2.2/mod/mod_expires.html
meantime, I'm studying the link, and they say in pretty una
Chuck,
On 24. 1. 2015, at 2:32, Chuck Hill wrote:
> First guess would be your mod_expires configuration in Apache. Apache can,
> and will, override the headers that the app sends.
> http://httpd.apache.org/docs/2.2/mod/mod_expires.html
If I were receiving proper headers through direct access
First guess would be your mod_expires configuration in Apache. Apache can, and
will, override the headers that the app sends.
http://httpd.apache.org/docs/2.2/mod/mod_expires.html
Chuck
On 2015-01-23, 5:21 PM, "OC" wrote:
Hello there,
in my image URL direct action, I set up caching headers i
