Chuck, On 24. 1. 2015, at 2:53, Chuck Hill <ch...@gevityinc.com> 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 <ch...@gevityinc.com> 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 (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com