ERA HTTP proxy caching install files but not modules

[Gamtat 1]

I'm having some issues with the ERA Apache http caching proxy.  I've updated a few test machines to EEA 6.6.2046 and the 6.6.2046 installer looks like it was pulled from the cache properly but after the install and forced reboot there was another update (modules?)  This wasn't pulled from the cache instead it was just proxied through Apache on the ERA server.

[Wed Sep 20 09:53:59.467075 2017] [cache:debug] [pid 6468:tid 916] mod_cache.c(1214): [client 10.10.10.86:49213] AH00768: cache: hxxp://update.eset.com/ep6.6-dll-rel-sta/mod_002_engine_30152/em002_64_l0.dll.nup not cached. Reason: Authorization required

After about 15 minutes downloading I noticed this in the ERA proxy's error.log:

[Wed Sep 20 10:06:23.072275 2017] [cache:debug] [pid 6468:tid 900] mod_cache.c(1214): [client 10.10.10.86:49279] AH00768: cache: hxxp://update.eset.com/ep6.6-dll-rel-sta/mod_002_engine_34802/em002_64_l2.dll.nup not cached. Reason: Response status 404

And the client's EEA update tab now says "Modules update failed, file not found on server".  However, the client in ERA is listed as "modules updated", with the correct EEA version number (ESET Endpoint Antivirus 6.6.2046.0) but an old definitions version - 15873.  (current as of now is 16112).  I guess this is because the hourly update task hasn't been run yet?

 

 I then manually click "check for updates" on the client and it's now downloading another file (em023_64_i0.dll.nup) through the proxy again instead of the cache.  This file is 16MB, the previous one that failed (em002_64_i0.dll.nup ?) was 75MB.  After a lengthy update the client then goes through the "updating modules x/6" process and now looks fine on both the client and the ERA.

 

 

Tried it on another machine and exactly the same results.  The installation file is cached but the modules aren't.  When the machine gets logged in after the forced reboot the user is presented with a big warning popup telling them "modules update failed, file not found on server".  If I manually run check updates or manually force the scheduled hourly scheduled task to run the modules are now updated but are still not being cached by the ERA proxy.

 

if I run htcacheclean -a -p "c:\programdata\apache http proxy\cache" I get a little over 1100 entries so some things are being cached fine but not everything.

[sdnian 6]

You are right. I've the same issue. But I don't think it's the problem of Apache HTTP Proxy. On August 29, I post this issue  https://forum.eset.com/topic/12938-66-and-mirror-tool/ . But no anybody cares for me just like others. 

[Gamtat 1]

I'm assuming update.ver isn't supposed to be cached.  Here's a section of yesterday's cached-requests.log from Apache.  Note that the only clients that are occasionally receiving a cached update.ver are the ones that have been updated to 6.6.2046.

10.10.10.105 - - [21/Sep/2017:00:04:48 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.134 - - [21/Sep/2017:00:07:01 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.105 - - [21/Sep/2017:01:04:48 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.134 - - [21/Sep/2017:01:07:00 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.134 - - [21/Sep/2017:03:07:01 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.134 - - [21/Sep/2017:06:07:03 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9600
10.10.10.134 - - [21/Sep/2017:07:07:05 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9599
10.10.10.134 - - [21/Sep/2017:09:07:13 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9599
10.10.10.134 - - [21/Sep/2017:11:07:05 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9656
10.10.10.105 - - [21/Sep/2017:12:04:53 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9656
10.10.10.134 - - [21/Sep/2017:12:07:05 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9656
10.10.10.134 - - [21/Sep/2017:13:07:05 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9656
10.10.10.104 - - [21/Sep/2017:13:57:09 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.105 - - [21/Sep/2017:14:04:52 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.134 - - [21/Sep/2017:14:07:07 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.86 - - [21/Sep/2017:14:20:27 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9621
10.10.10.105 - - [21/Sep/2017:15:04:53 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9626
10.10.10.134 - - [21/Sep/2017:15:07:10 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9626
10.10.10.134 - - [21/Sep/2017:17:07:08 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9626
10.10.10.104 - - [21/Sep/2017:17:57:14 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9613
10.10.10.105 - - [21/Sep/2017:18:04:55 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9613
10.10.10.134 - - [21/Sep/2017:18:07:07 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9613
10.10.10.86 - - [21/Sep/2017:18:20:28 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9613
10.10.10.134 - - [21/Sep/2017:19:07:08 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.105 - - [21/Sep/2017:20:04:55 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.134 - - [21/Sep/2017:20:07:07 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.105 - - [21/Sep/2017:21:04:55 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.134 - - [21/Sep/2017:21:07:07 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.105 - - [21/Sep/2017:22:04:55 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.134 - - [21/Sep/2017:22:07:07 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.134 - - [21/Sep/2017:23:07:08 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9635

I also get requests for update.ver in revalidated-requests.log a couple times a day.  Also only from the clients that have been updated to 6.6.2046.  Here are those entries copied  from that log:

10.10.10.104 - - [20/Sep/2017:14:57:02 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9633
10.10.10.134 - - [20/Sep/2017:16:06:59 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9633
10.10.10.105 - - [21/Sep/2017:19:04:55 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.104 - - [21/Sep/2017:21:57:15 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9658
10.10.10.105 - - [21/Sep/2017:23:04:57 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9635
10.10.10.134 - - [22/Sep/2017:07:07:08 -0500] "GET hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver HTTP/1.1" 200 9606

Am I reading the logs incorrectly?

If I grep update.ver from htcacheclean.exe -a -p "c:\ProgramData\Apache HTTP Proxy\cache" I get this:

hxxp://um05.eset.com:80hxxp://um05.eset.com/eset_upd/v5/update.ver?
hxxp://um02.eset.com:80hxxp://um02.eset.com/eset_upd/v5/update.ver?
hxxp://38.90.226.40:80hxxp://38.90.226.40/eset_upd/v5/update.ver?
hxxp://um21.eset.com:80hxxp://um21.eset.com/eset_upd/v5/update.ver?
hxxp://update.eset.com:80hxxp://update.eset.com/eset_upd/v5/update.ver?
hxxp://um07.eset.com:80hxxp://um07.eset.com/eset_upd/v5/update.ver?
hxxp://91.228.166.13:80hxxp://91.228.166.13/eset_upd/v5/update.ver?
hxxp://91.228.167.21:80hxxp://91.228.167.21/eset_upd/v5/update.ver?
hxxp://um09.eset.com:80hxxp://um09.eset.com/eset_upd/v5/update.ver?
hxxp://91.228.167.133:80hxxp://91.228.167.133/eset_upd/v5/update.ver?
hxxp://38.90.226.39:80hxxp://38.90.226.39/eset_upd/v5/update.ver?
hxxp://update.eset.com:80hxxp://update.eset.com/eset_upd/ep6.6/dll/update.ver?
hxxp://91.228.166.16:80hxxp://91.228.166.16/eset_upd/v5/update.ver?
hxxp://38.90.226.37:80hxxp://38.90.226.37/eset_upd/v5/update.ver?

 

The clients I've updated to 6.6.2046 do seem to have the latest definition updates (currently 16123) despite occasionally being served cached update.ver files, so I'm not sure what's going on.  A little help deciphering this would be great.

[MartinK 378]

This issue is currently being investigated. Seems that there is problem in configuration of ESET update servers affecting update files for latest endpoint products (v6.6): no cache-control related headers are sent by ESET servers. In case this is confirmed, re-configuration of ESET servers should be enough to enable caching for all users of ep6.6 mirror.

Regarding update.ver caching: file is cached because of missing "no-cache" headers sent from update servers, but this should not affect security product update -> each time product checks for updates, it sends HEAD request with "no-cache" properties so that file is not server from HTTP proxy. Update.ver should be server from cache only in case initial HEAD request shows that file on ESET servers is the same as the one cached.

[jeffm 0]

Hi MartinK,

Is there any update on this?  I'm seeing a similar problem when updating EEA clients from 6.5 to 6.6, the HTTP proxy is not caching the installer file.  Every client is pulling the file from the internet every time.  This has been driving me nuts for the past week; I assumed something was wrong with Apache, but I can't find anything wrong.

 

[Marcos 5,071]

The problem was with the configuration of update servers. I'll need to check with the respective guys if this has already been addressed.

[MartinK 378]

New configuration of update servers was deployed to private/testing servers during last week. Unfortunately I do not know for how long it will be tested as it is critical part of ESET infrastructure. What I can tell you is that once new configuration is deployed on public servers, caching will start to work automatically.

[MartinK 378]

Just to let you now (if you are interested in testing), changes are now available for Pre-release update servers. I guess they will be propagated to Regular update servers in a few days in case nothing goes wrong.

[jeffm 0]

I'm still having trouble with install files not caching.

I am using the "Install by direct package URL" option in my install task and using this URL: https://download.eset.com/com/eset/apps/business/eea/windows/latest/eea_nt64_enu.msi.  This file is not caching.

I created a new install task and used the "Install package from repository" option, and this file does cache as expected.

[MichalJ 434]

Thanks for reporting. I will check with the download servers team, whether they are configured to support caching. If not, that might be the reason for caching not working for your "direct download link option".

Repository (the default channel) is, which means that caching works as expected.