InternetOpenUrl and local cache (2)

[Si]

Hi,

I'm using InternetOpenUrl, with the flags INTERNET_FLAG_RESYNCHRONIZE
| INTERNET_FLAG_NO_UI, to access a file on a web server.
In the web server, the file is defined to expire after 2 days.

I see 2 behaviors that I don't understand, and I hope someone can
help.

__Issue 1__

After the 1st download, the file is stored in the temporary files
folder.
If I try to "InternetOpenUrl" during the 2 days before expiration,
I've expected that there will not be an access to the web server,
However I see (using Fiddler), that there is an access to the web
server with result 304.
Is there a way to avoid this access before expiration, so only local
cache is used ?

__ Issue 2__
In the previous scenario, although I see "304" in Fiddler,
HttpQueryInfo returns "200".
How can I get the real value ?
(Maybe this issue will be resolved after the 1st one is)

Thanks for any help,
Si.

[Alexander Nickolov]

This behavior is by design. It's a direct consequence of you specifying
INTERNET_FLAG_RESYNCHRONIZE. Here's what RFC2626 has to say about
status code 304:

10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The 304 response MUST NOT contain a
message-body, and thus is always terminated by the first empty line after
the header fields.
The response MUST include the following header fields:
- Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients add
their own Date to any response received without one (as already specified
by [RFC 2068], section 14.19), caches will operate correctly.
- ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request

- Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant

If the conditional GET used a strong cache validator (see section 13.3.3),
the response SHOULD NOT include other entity-headers. Otherwise (i.e.,
the conditional GET used a weak validator), the response MUST NOT
include other entity-headers; this prevents inconsistencies between cached
entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache
MUST disregard the response and repeat the request without the conditional.
If a cache uses a received 304 response to update a cache entry, the cache
MUST update the entry to reflect any new field values given in the response.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnic...@mvps.org
MVP VC FAQ: http://vcfaq.mvps.org
=====================================

"Si" <bluet...@walla.co.il> wrote in message
news:6e03f482-0829-44de...@s8g2000prg.googlegroups.com...

[Si]

Hi,

Thanks for your help.
I've omitted the flag INTERNET_FLAG_RESYNCHRONIZE, and now I get the
behavior I wanted for accessing the remote server. Namely if the file
is in the local computer cache, and not expired, there is no access to
remote server.

However, I still encounter the following problem.
If the "InternetOpenUrl" gets the file from the local computer cache,
HttpQueryInfo still returns "200".
I need to distinguish between a 200 that is of file from remote
server, and 200 that is of file from local cache.
Is there a way to do it ?

(I can do all these checkd before hand, using "GetUrlCacheEntryInfo",
but I want to avoid it as much as possible.)

Thanks for your help,
Si.

[Volodymyr M. Shcherbyna]

IMO, you can't distinguish.

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.

"Si" <bluet...@walla.co.il> wrote in message

news:80d0ab95-d71e-4717...@b1g2000hsg.googlegroups.com...

[Si]

Thanks for your help.
I've bypassed the "200 distinguish" by comparing CRC of files
received, with local copies.
10x again.

On Mar 7, 10:20 am, "Volodymyr M. Shcherbyna"