P.S.
First guess would be your mod_expires configuration in Apache. Apache can, and will, override the headers that the app sends.
meantime, I'm studying the link, and they say in pretty unambiguous terms
"When the Expires header is already part of the response generated by the server, for example when generated by a CGI script or proxied from an origin server, this module **does not change or add an Expires or Cache-Control header**."
(Emphasized yours truly.)
My code does generate them both, using the following code:
===
WOActionResults bannerAction {
...
WOResponse wor=new WOResponse()
...
wor.setHeader(NSTimestamp.now.timestampByAddingMinutes(120).toString(),"Expires")
wor.setHeader('private, max-age=36000',"Cache-Control")
return wor
}
===
and the curl results prove they indeed get generated.
Hmmm. Weird.
Thanks,
OC
On 2015-01-23, 5:21 PM, "OC" wrote:
Hello there,
in my image URL direct action, I set up caching headers in my WOResponse so that the client caches the image. When I have a look through curl, I _am_ getting those headers all right:
===
Date: Sat, 24 Jan 2015 01:16:07 GMT
Server: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/0.9.8y
cache-control: private, max-age=36000
expires: 2015-01-24 03:16:07 Etc/GMT
content-length: 103747
MS-Author-Via: DAV
Content-Type: image/png
55 /tmp>
===
It does not seem to work in browser though -- Safari shows me the response headers for the very same URL in a different (and wrong) way:
PastedGraphic-7.tiff
Has anybody the slightest idea what might be the culprit?
Note: the problem does not seem to be local to my computer/browser -- another user reported the same (wrong, as in the screenshot) headers in his Chrome.
Thanks a lot,
OC