4

Site icons are misaligned in many places across Stack Exchange.

Seems like a duplicate of those old bugs which had been fixed:

Here's what I see now on Windows 10 Chrome 52.0.2743.82 beta-m (64-bit):

enter image description here

on Android (Chrome 51.0.2704.81):

enter image description here

I've cleared the cache and tried incognito mode, as well as Firefox 47.0.1, problem persists.

Update:

Icons are ok on http://meta.stackexchange.com but are misplaced on http://stackoverflow.com and http://russian.stackexchange.com

Update 2:

Here's what I get with requests from two different IP addresses:

Request from an IP in Great Britain (correct response):

alex@dev1:~$ curl 'https://cdn.sstatic.net/img/favicons-sprite32.png?v=df4c1382a05c' -H 'Host: cdn.sstatic.net' -H 'Pragma: no-cache' -H 'Accept-Encoding: gzip, deflate, sdch, br' -H 'Accept-Language: ru,en-US;q=0.8,en;q=0.6' -H 'Upgrade-Insecure-Requests: 1' -H 'X-Compress: null' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: no-cache' -H 'Connection: keep-alive' --compressed -o /dev/null -s -D - --resolve cdn.sstatic.net:443:151.101.129.69
HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: image/png
Last-Modified: Tue, 19 Jul 2016 17:22:46 GMT
ETag: "6366782ae2e1d11:0"
Content-Length: 203313
Accept-Ranges: bytes
Date: Thu, 21 Jul 2016 16:57:07 GMT
Via: 1.1 varnish
Age: 171124
Connection: keep-alive
X-Served-By: cache-lcy1132-LCY
X-Cache: HIT
X-Cache-Hits: 12641
X-Timer: S1469120227.487221,VS0,VE0
Vary: Accept-Encoding

Request from an IP in Russia (incorrect response, see the Content-Length):

[abolen@wind ~]$ curl 'https://cdn.sstatic.net/img/favicons-sprite32.png?v=df4c1382a05c' -H 'Host: cdn.sstatic.net' -H 'Pragma: no-cache' -H 'Accept-Encoding: gzip, deflate, sdch, br' -H 'Accept-Language: ru,en-US;q=0.8,en;q=0.6' -H 'Upgrade-Insecure-Requests: 1' -H 'X-Compress: null' -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' -H 'Cache-Control: no-cache' -H 'Connection: keep-alive' --compressed -o /dev/null -s -D - --resolve cdn.sstatic.net:443:151.101.129.69
HTTP/1.1 200 OK
Cache-Control: max-age=604800
Content-Type: image/png
Last-Modified: Tue, 19 Jul 2016 16:45:32 GMT
ETag: "9864faf6dce1d11:0"
Content-Length: 202798
Accept-Ranges: bytes
Date: Thu, 21 Jul 2016 16:59:10 GMT
Via: 1.1 varnish
Age: 171288
Connection: keep-alive
X-Served-By: cache-bma7021-BMA
X-Cache: HIT
X-Cache-Hits: 15
X-Timer: S1469120350.547303,VS0,VE0
Vary: Accept-Encoding

I've tried to rule out as many variables as possible, however the different IP addresses apparently get served by different Varnish endpoints.

24
  • Try clearing your cache and doing a hard refresh - you are probably loading an old version of the CSS.
    – Oded
    Jul 21 '16 at 14:50
  • @Oded: trust me, I wouldn't have posted it in the first place before doing this.
    – Quassnoi
    Jul 21 '16 at 15:19
  • Well... not everybody does before posting ;) - it could be a proxy between you and us serving up an old version.
    – Oded
    Jul 21 '16 at 15:26
  • @Oded: there is no proxy. Just tried the backup provider and the mobile provider (both in porn mode), the same thing.
    – Quassnoi
    Jul 21 '16 at 15:29
  • Could very well be something your ISP is doing or a caching proxy between you and us.
    – Oded
    Jul 21 '16 at 15:32
  • @Oded: interestingly enough, the sites look fine from a browserstack account. Do you maybe have different caching servers for different areas?
    – Quassnoi
    Jul 21 '16 at 15:33
  • We do use a CDN for static content, but we also cache break newer versions.
    – Oded
    Jul 21 '16 at 15:34
  • @Oded: apparently you don't always, because browserstack and my home computers receive different versions of cdn.sstatic.net/img/favicons-sprite32.png?v=df4c1382a05c (note the HTTPS). X-Served-By:cache-bma7024-BMA (home), X-Served-By:cache-ams4144-AMS (browserstack). Content lengths differ.
    – Quassnoi
    Jul 21 '16 at 15:51
  • But see that ?v=? It should cause a cache break. If you change the value you should see the same file. I don't know what BMA is, but I don't think it is us.
    – Oded
    Jul 21 '16 at 16:04
  • @Oded: out of curiosity, are you shibboleet compatible? xkcd.com/806
    – Quassnoi
    Jul 21 '16 at 16:06
  • Only in the sense that it is a Hebrew word and as an Israeli I am a native speaker of Hebrew ;)
    – Oded
    Jul 21 '16 at 16:10
  • @Oded: OK. Different X-Served-By headers mean that the file is served by different Varnish servers, most probably selected based on GeoIP. The server which serves Mother Russia and vicinity serves a wrong, outdated version of the file. It's 202798 bytes long, not 203313 as it should be. This server identifies itself as cache-bma7023-BMA. Could you please locate someone who is responsible for Varnish caching and ask them to issue a PURGE request against this resource on this server? Thanks!
    – Quassnoi
    Jul 21 '16 at 16:23
  • Purge issued. How does it look now?
    – Oded
    Jul 21 '16 at 16:35
  • @Oded: unfortunately, the same. If I remove or change the v parameter, it serves the right file (12348 pixels high, 203313 bytes long).
    – Quassnoi
    Jul 21 '16 at 16:56
  • @Oded: see the curl script in my update to reproduce the problem.
    – Quassnoi
    Jul 21 '16 at 17:02
1

I've just been talking to Fastly regarding this caching issue, and they have reported that all of our caches are up to date, and we are seeing the correct data now returned from RU.

Looks like the 2nd purge that Oded issued may have resolved the problem.

1
  • It works now, thanks a lot!
    – Quassnoi
    Jul 22 '16 at 13:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .