Re: Wrong caching headers in browser
Re: Wrong caching headers in browser
- Subject: Re: Wrong caching headers in browser
- From: OC <email@hidden>
- Date: Sat, 24 Jan 2015 03:00:57 +0100
Chuck,
On 24. 1. 2015, at 2:53, Chuck Hill <email@hidden> 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 also possible that this behaviour is different in Apache 2.2 that whatever version I was using a few years ago.
>
> Could there be some other proxy between your browser and the server?
None I would know of. My proxy setting is clean, and besides, it works same way to another user. Still might (well, highly probably would) be some mangled Apache setting server-side, but to me, it looks weird indeed :-O
(After all, presumed you can spare a couple more minutes, you can try open the URL 'http://aukce1.fskprojektova.cz/cgi-bin/WebObjects/REBOISx.woa/wa/banner?size=103747&mkpk=1000002&lang=CZ' in your browser and download through curl, to see whether the headers would be all right or mangled in one or both cases...)
Thanks a lot and all the best,
OC
> On 2015-01-23, 5:48 PM, "OC" wrote:
>
> P.S.
>
> On 24. 1. 2015, at 2:32, Chuck Hill <email@hidden> 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 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:
> ===
> 54 /tmp> curl -sD - -o /dev/null 'http://aukce1.fskprojektova.cz/cgi-bin/WebObjects/REBOISx.woa/wa/banner?size=103747&mkpk=1000002&lang=CZ' -A 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.71 (KHTML, like Gecko) Version/6.1 Safari/537.71' HTTP/1.1 200 Apple
> 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
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden