On 18 Jun '08, at 3:01 AM, Marc Monguio wrote:
The documentation I've found about Conditional GET in the web says
I should be sending If-Modified-Since and If-None-Match headers
with the contents of Last-Modified and ETag headers from the last
server's answer. However it doesn't look like a NSURLRequest with a
NSURLRequestUseProtocolCachePolicy is adding the If-None-Match
header. Fortunately it adds the Last-Modified header automatically
so I've tweaked my server-side to be able to work just with this
header for caching.
Is this a bug in NSURLRequestUseProtocolCachePolicy ?
I think so; or at least a case where it's not being as optimal as it
could be.
When debugging the status in the connection:didReceiveResponse:
delegate method the statusCode is always 200. I knew for sure than
in fact it was being cached so I ran tcpdump and I saw that except
the first call the rest were always Status Code 304 Not Modified.
Why I can't see what I really get from the server in my code?
I think the framework does this intentionally since it's hiding the
details of the caching from you. Since you didn't explicitly add an if-
modified-since header to your request, a 304 response wouldn't be a
valid status code for the request as you generated it.
When I've implemented conditional requests, I've always added the
necessary headers myself. I haven't used the CFNetwork cache at all in
these cases; but I think you could do so by first sending the request
in use-cache-only mode, checking the mod date and etag of the
response, and then sending a request with your own if-none-match and
if-modified-since headers, using the ignore-cache mode.
—Jens
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
