Notifications

2045 views

Description

When revisiting a ServiceNow instance in any browser, a conditional GET request is sent by the browser for most of the required resources as a local cached copy will exist. Example resource types include CSS files, font files, JavaScript files, and images. The conditional GET request asks the server whether the file has changed since the browser's cached version. If so, the server responds with a '200 OK' response that contains a copy of the new file. If the file has not changed, a '304 Not Modified' response is sent by the server.

This behavior means that the browser always has the latest version of a resource. It also saves bandwidth and load times by not downloading a resource if that exact file is already present.

For font file resources such as SourceSansPro and retina_icons, the server ALWAYS responds with a '304 Not Modified' response, even if the file actually has changed. This means that after upgrading from Geneva to Helsinki (where the icon fonts have changed) users will continue using the old Geneva icon font and that all icons throughout the interface are wrong. See attached screenshot named PRB705910-wrong-icons-304.png.

This is a server-side issue with the way that the server is responding to the browser's requests for the font. The server is telling the browser that it is ok to use the local copy of the file as the file has not changed, even when it actually has.

Steps to Reproduce

 

  1. On a computer/virtual machine running Windows 7 and IE11, provision a Geneva Patch 4 instance.
  2. On a Windows 7 computer/virtual machine, open Internet Explorer 11.
  3. Open the F12 Developer tools.
  4. Switch to the Network tab.
  5. Ensure the Always refresh from server option is not enabled.
  6. Log in to the instance.
    Note the icons.
  7. Upgrade the instance to Helsinki Patch 2.
  8. Log in to the instance.
    Note the icons. The server returns a 304 Not Modified response, even though the font file on the server has been modified and is different from the cached copy on the client. Because the font file has changed during the upgrade, the server should respond with a 200 OK request and supply the new font file to the browser.

 

 

Workaround

If you have a small amount of end users, perform one of the following options on each affected computer:

  • Do a hard refresh (CTRL + F5)
  • Clear the browser's local storage cache/temporary internet files
  • Manually delete the font files from the browser's local storage cache/temporary internet files

If you have hundreds or even thousands of users, the burden of applying this workaround is extremely large.

If you are running a Windows domain environment and Internet Explorer 11, create a temporary logon script that deletes these font files for all the users in the domain, and push it out via Group Policy. You can use a script similar to the following example:

cd %localappdata%\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5
del /S SourceSansPro*.eot
del /S retina_icons*.eot

 


Related Problem: PRB705910

Seen In

Fuji Patch 12 Hot Fix 1
Geneva Patch 1 Hot Fix 8
Geneva Patch 3 Hot Fix 2
Geneva Patch 4
Geneva Patch 5
Geneva Patch 6
Geneva Patch 6 Hot Fix 2
Geneva Patch 7
Geneva Patch 8
Helsinki Patch 0 Hot Fix 1
Helsinki Patch 1
Helsinki Patch 2
Helsinki Patch 3
Helsinki Patch 3 Hot Fix 6
Helsinki Patch 4
Helsinki Patch 5
Helsinki Patch 6 Hot Fix 1
Istanbul

Fixed In

Helsinki Patch 10
Istanbul Patch 4
Jakarta

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-03-07 03:48:53
Published:2017-07-31
PRB705910-wrong-icons-304.png