Am 30.03.2005 um 20:15 schrieb Charlie Boisseau:
On 30 Mar 2005, at 18:24, Frank Bitterlich wrote:
I'm trying to find the reason to some strange HTTPSocket behavior I'm
seeing. It looks to me that the HTTPSocket (or the underlying OS
parts) is doing some kind of caching.
The HTTPSocket doesn't cache anything and seeing as it's built on an
ordinary TCPSocket, there's no underlying process capable of doing any
caching.
Glad to hear this, so this should work transparently.
Previously I have run into issues because my ISP has a forced-proxy
setup. Whether you know it or not, some ISPs force all web traffic
through their proxy. Safari could be sending a header which tells the
proxy to ignore the cache.
That can't be the issue here as it is purely in-house.
You should use a packet sniffer (there's one in Net Tool Box, which
just won a Design Award!) to see what the difference in headers is.
Once you know which ones Safari uses you can replicate this on your
HTTPSocket.
That's what I feared :) I'm using tcpflow for this kind of wok, which
is quite comfortable but still a lot of trial-and-error. I'll first try
to add a few cache-control directives to my request, if that doesn't
work I'lll do as Dean Davis suggested - replicate the Safari request
completely.
Thanks to Stefan Pantke too.
Cheers,
Frank+++
--
Günter Schmidt & Co. oHG
Frank Bitterlich eMail: bitterlich at gsco dot de
Schlosserstr. 4 WWW: http://www.gsco.de/
D-60322 Frankfurt Tel.: 069 / 156809-29
GERMANY Fax: 069 / 156809-28
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|