R
Robin Walker [MVP]
These groups are full of complaints that MSAS definition updates sometimes
repeatedly try to download the same updates, and so on. Or updates that are
available to one poster appear not to be available when another poster
tries. These problems seem to occur only to some users: others have no
trouble at all. The users that do have trouble seem to have trouble
repeatedly.
I believe that these problems are caused by web caching of one sort or
another.
When Microsoft update their definition files, they do not change the URL of
the files to be fetched. Also, when they serve the files, there are no HTTP
headers which mark the content as non-cachable. All they do is send an HTTP
"ETag", which is a code that changes if the content changes for the same
URL.
Many ISPs operate a system of transparent web proxy caches. These are set
up to keep cached copies within the ISP's network of the content of HTTP
documents fetched from outside the ISP's network. Some ISP proxy web-caches
do not recognise the "ETag" HTTP header as anything special. These proxy
caches will not notice when Microsoft update the MSAS definitions on the MS
spynet server, and these proxy caches will continue to serve stale content
(previous versions) of MSAS definitions to the end-users of that ISP.
End-users on such ISPs will find that MSAS appears to repeatedly revert to
out-of-date versions of the definition files. Interestingly, when MSAS
requests the latest definition version number from the spynet server, it
sends that HTTP request "no-cache" so that it always gets the latest true
response from the spynet server, unaffected by any intervening cache. It is
when it comes to fetch the definitions files themselves that it is liable to
be served stale content by an ISP's web proxy cache.
There is very little that an end-user can do to extricate themselves from
this problem, other than wait for the ISP's proxy web cache to time-out the
stale content copy, and fetch fresh copies from the spynet server. [End
users that understand how to circumvent ISP's transparent web proxy caches
by configuring an explicit HTTP proxy on a port other than 80 may try that
technique to see if that solves their MSAS problem: this is not recommended
for non-expert users].
Microsoft could help ease this situation if, when serving the MSAS
definition files, they used HTTP headers other than just "ETag" to limit the
extent to which MSAS definition files are held cached in ISPs' proxy caches.
Related issue #1:
Tests here show that MSAS uses the HTTP fetch mechanism of the user's web
browser, rather than making HTTP requests itself. After the definition
files have been downloaded, they are held in the browser's web cache as
*.gcz files. I would have expected Microsoft to have ensured that MSIE
honours the "ETag" when deciding whether to use a local cached copy rather
than fetch it, but there is always the possibility of some problem in this
area. So if users are having difficulties with outdated files, it might
help to clear the browser's local cache (Temporary Internet Files).
Related Issue #2:
Do not rely on the definitions version number shown in the "About Microsoft
Windows AntiSpyware" dialogue panel, unless you have just shutdown and
relaunched MSAS. It can, for instance, display the wrong version number
after a definitions update, thus misleading you as to what is going on. It
shows the correct version number when MSAS has just been newly launched
(e.g. after a Windows restart).
repeatedly try to download the same updates, and so on. Or updates that are
available to one poster appear not to be available when another poster
tries. These problems seem to occur only to some users: others have no
trouble at all. The users that do have trouble seem to have trouble
repeatedly.
I believe that these problems are caused by web caching of one sort or
another.
When Microsoft update their definition files, they do not change the URL of
the files to be fetched. Also, when they serve the files, there are no HTTP
headers which mark the content as non-cachable. All they do is send an HTTP
"ETag", which is a code that changes if the content changes for the same
URL.
Many ISPs operate a system of transparent web proxy caches. These are set
up to keep cached copies within the ISP's network of the content of HTTP
documents fetched from outside the ISP's network. Some ISP proxy web-caches
do not recognise the "ETag" HTTP header as anything special. These proxy
caches will not notice when Microsoft update the MSAS definitions on the MS
spynet server, and these proxy caches will continue to serve stale content
(previous versions) of MSAS definitions to the end-users of that ISP.
End-users on such ISPs will find that MSAS appears to repeatedly revert to
out-of-date versions of the definition files. Interestingly, when MSAS
requests the latest definition version number from the spynet server, it
sends that HTTP request "no-cache" so that it always gets the latest true
response from the spynet server, unaffected by any intervening cache. It is
when it comes to fetch the definitions files themselves that it is liable to
be served stale content by an ISP's web proxy cache.
There is very little that an end-user can do to extricate themselves from
this problem, other than wait for the ISP's proxy web cache to time-out the
stale content copy, and fetch fresh copies from the spynet server. [End
users that understand how to circumvent ISP's transparent web proxy caches
by configuring an explicit HTTP proxy on a port other than 80 may try that
technique to see if that solves their MSAS problem: this is not recommended
for non-expert users].
Microsoft could help ease this situation if, when serving the MSAS
definition files, they used HTTP headers other than just "ETag" to limit the
extent to which MSAS definition files are held cached in ISPs' proxy caches.
Related issue #1:
Tests here show that MSAS uses the HTTP fetch mechanism of the user's web
browser, rather than making HTTP requests itself. After the definition
files have been downloaded, they are held in the browser's web cache as
*.gcz files. I would have expected Microsoft to have ensured that MSIE
honours the "ETag" when deciding whether to use a local cached copy rather
than fetch it, but there is always the possibility of some problem in this
area. So if users are having difficulties with outdated files, it might
help to clear the browser's local cache (Temporary Internet Files).
Related Issue #2:
Do not rely on the definitions version number shown in the "About Microsoft
Windows AntiSpyware" dialogue panel, unless you have just shutdown and
relaunched MSAS. It can, for instance, display the wrong version number
after a definitions update, thus misleading you as to what is going on. It
shows the correct version number when MSAS has just been newly launched
(e.g. after a Windows restart).