Xojo.Net.HTTPSocket caching data

Reading the data from the PageRecevied event, however it seems that somehow the data is being cached behind the scenes. The same URL in a web browser returns the correct value, yet using this socket, it can get stuck with old data. Right now it’s been 10 minutes and it’s still showing me the OLD data, app restarts don’t make any difference.

Any help please? This is frustrating as heck.

You can help this by “changing” the URL. Add a parameter to the end as ?r=1234 or &r=1234 if there are other parameters.

I typically use ticks or microseconds.

If you have control over the server, make sure the caching headers are set up properly and the ETag header changes when the underlying data changes.

[quote=327252:@Greg O’Lone]You can help this by “changing” the URL. Add a parameter to the end as ?r=1234 or &r=1234 if there are other parameters.

I typically use ticks or microseconds.[/quote]
Thanks, I’ll experiment with this.

The correct data gets downloaded if I access the page in Safari, just in my Xojo made application it’s returning stale data.

Is any other way I make the socket request the latest data? Any headers or anything? Does it make any difference that I’m testing this on OS X 10.11.6.

Version shouldn’t matter. You could try explicitly setting the ETag header.

On the macOS are you guys using NSURLSession as I think I may have found a solution…

NSURLCache.sharedURLCache().removeAllCachedResponses()

I’ll try it anyway and let you know if it makes any difference.

Okay, so I’m not 100% it’s all working correctly or even if this is just coincidence.

I uploaded fresh data this morning and tested my already built application, still downloaded the stale data.

Then I added the following code to the ‘tester’ application that I’m debugging.

#if TargetMacOS and TargetCocoa then declare function NSClassFromString lib "Cocoa" ( className as CFStringRef ) As Ptr declare function sharedURLCache lib "Cocoa" selector "sharedURLCache" ( NSURLCacheClass as ptr ) as Ptr declare sub removeAllCachedResponses lib "Cocoa" selector "removeAllCachedResponses" ( NSURLCacheInstance as Ptr ) removeAllCachedResponses( sharedURLCache( NSClassFromString( "NSURLCache" ) ) ) #endif

When I ran the tester application, it downloaded the correct data. When I tried the already built application, it also downloaded the correct data (and not the stale data). It leaves me thinking that the OS is doing some caching in the background and storing this universally somewhere. The thing that gets me, is Safari always returns the correct data, yet not the new sockets. Are Apple doing something special for Safari? Maybe they don’t even use their own APIs?

Have you tried retrieving the data through a telnet socket to see if it gets the stale or new data?

[quote=327305:@Sam Rowlands]Okay, so I’m not 100% it’s all working correctly or even if this is just coincidence.

I uploaded fresh data this morning and tested my already built application, still downloaded the stale data.

Then I added the following code to the ‘tester’ application that I’m debugging.

#if TargetMacOS and TargetCocoa then declare function NSClassFromString lib "Cocoa" ( className as CFStringRef ) As Ptr declare function sharedURLCache lib "Cocoa" selector "sharedURLCache" ( NSURLCacheClass as ptr ) as Ptr declare sub removeAllCachedResponses lib "Cocoa" selector "removeAllCachedResponses" ( NSURLCacheInstance as Ptr ) removeAllCachedResponses( sharedURLCache( NSClassFromString( "NSURLCache" ) ) ) #endif

When I ran the tester application, it downloaded the correct data. When I tried the already built application, it also downloaded the correct data (and not the stale data). It leaves me thinking that the OS is doing some caching in the background and storing this universally somewhere. The thing that gets me, is Safari always returns the correct data, yet not the new sockets. Are Apple doing something special for Safari? Maybe they don’t even use their own APIs?[/quote]
do you happen to have a copy of Paw? I’d be curious to know what headers are being returned from your server as that may help track this down.