XF 2.2 Strange entries in web.log of the server

[smallwheels]

I am digging around dealing with bots (and getting rid of them) and found a couple of strange entries in the log of my webserver:

mail.huijingzhiye.com - - [27/Apr/2025:21:00:30 +0200] "GET /favicon.ico HTTP/1.1" 404 196 "-" "Go-http-client/1.1" 497 4623
mail.huijingzhiye.com - - [27/Apr/2025:21:00:31 +0200] "GET /robots.txt HTTP/1.1" 200 3394 "-" "Go-http-client/1.1" 496 7970
mail.huijingzhiye.com - - [27/Apr/2025:21:00:31 +0200] "GET /sitemap.xml HTTP/1.1" 200 65390 "-" "Go-http-client/1.1" 497 70632
mail.huijingzhiye.com - - [27/Apr/2025:21:00:59 +0200] "GET /js/xf/core-compiled.js?_v=76c81cce HTTP/1.1" 200 216054 "-" "Go-http-client/1.1" 520 221218
mail.huijingzhiye.com - - [27/Apr/2025:21:01:01 +0200] "GET /jc/gtm.js?_v=76c81cce HTTP/1.1" 200 357311 "-" "Go-http-client/1.1" 507 364979
mail.huijingzhiye.com - - [27/Apr/2025:21:01:03 +0200] "GET /robots.txt HTTP/1.1" 200 3394 "-" "Go-http-client/1.1" 496 7970
mail.huijingzhiye.com - - [27/Apr/2025:21:01:03 +0200] "GET /sitemap.xml HTTP/1.1" 200 65390 "-" "Go-http-client/1.1" 497 70632

What is strange for a start is that the host "mail.huijingzhiye.com" does not resolve / not exist and neither does the domain. Two of the requests made are strange as well:

"GET /js/xf/core-compiled.js?_v=76c81cce

gives you a huge load of javascript - raw code of XFs core. Not sure if it should be that way? The parameter used in the call "_v=76c81cce" does not seem to make any sense - the answer seems to be the same w/o it.

The call

"GET /jc/gtm.js?_v=76c81cce

uses the same parameter, again it seems to have no effect and again you end up with a bunch of code - this time it seems to be rather generic as it starts with "// Copyright 2012 Google Inc. All rights reserved."

Has anyone a clue what the intention behind this may be?

ist using the same parameter (and seems to have been successful according to the log)

 

[Jeremy P]

gives you a huge load of javascript - raw code of XFs core. Not sure if it should be that way? The parameter used in the call "_v=76c81cce" does not seem to make any sense - the answer seems to be the same w/o it.

That's bundled and minified JS required for every page, so it's supposed to be that way. The query string is a cache-buster so that long-lived cache headers can be set for the response but the file can still be updated as necessary.

"GET /jc/gtm.js?_v=76c81cce

It'll be the Google Analytics JS, presumably from some add-on or mechanism to serve it locally as that's not something we do out of the box.

As far as the mail host, it could just be some bot/spider spoofing the Host request header while connecting to the IP address of your apex domain.

 

[smallwheels]

Thanks for the fast clarification!

it could just be some bot/spider spoofing the Host request header

You can consider that a a given I'd say.

 

[Kirby]

As far as the mail host, it could just be some bot/spider spoofing the Host request header while connecting to the IP address of your apex dodomain.

Hmm .. the first field of a webserver access log is the client IP address or hostname (with reverse lookups enabled) if the de-facto standard combined format is used.
So this should have nothing to do with the Host header?

I'd turn off reverse lookups not only for performance reasons but also to prevent malicious clients to hide their IP from access logs by using PTR RRs with non-existing hostnames.

 

[Jeremy P]

Good catch, I haven't had enough coffee today