1
votes

I'm providing an ETag in the Response Header from the server to the browser when supplying a javascript file generated programatically. On subsequent requests for that same javascript file the ETag does not get supplied back in Request Header by the browser.

I've tried this in both Chrome and IE, same results find below the request and response headers from original request and subsequent one.

Original Request Header

GET /v11/RUNTIME_SUPPORT.GetGlobalFormResources.aspx HTTP/1.1
Host: 101.152.80.163
Connection: keep-alive
Cache-Control: max-age=0
Accept: */*
X-FirePHP-Version: 0.0.6
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.66 Safari/537.36
Referer: http://101.152.80.163/v11/Web_Support.Html.aspx
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,ro;q=0.6,es;q=0.4
Cookie: StaraspxOpenTabsCount=0; ASP.NET_SessionId=jpdkfccaf0zttoxyvys53ac3; STARaspx_SessionId=1006606D-F415-4AE5-AA4C-847625EB2BAE
If-None-Match: 0.0.459

Original Response Header

HTTP/1.1 200 OK
Cache-Control: public, max-age=604800
Content-Type: application/javascript; charset=utf-8
Content-Encoding: gzip
ETag: 0.0.459,0.0.0,0.00
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
ItemType: FORMS
Digest: e0d3a2bdee4c0a48bc4f61bb744755c21c1d6c19
X-Powered-By: ASP.NET
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Headers: callfrom, content-type, runtimecalltype
Access-Control-Allow-Credentials: true
Date: Tue, 12 Apr 2016 11:46:06 GMT
Content-Length: 31763

Subsequent Request Header

GET /v11/RUNTIME_SUPPORT.GetGlobalFormResources.aspx HTTP/1.1
Host: 101.152.80.163
Connection: keep-alive
Cache-Control: max-age=0
Accept: */*
X-FirePHP-Version: 0.0.6
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.66 Safari/537.36
Referer: http://101.152.80.163/v11/Web_Support.Html.aspx
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,ro;q=0.6,es;q=0.4
Cookie: StaraspxOpenTabsCount=0; ASP.NET_SessionId=jpdkfccaf0zttoxyvys53ac3; STARaspx_SessionId=1006606D-F415-4AE5-AA4C-847625EB2BAE
If-None-Match: 0.0.459

Subsequent Response Header

HTTP/1.1 200 OK
Cache-Control: public, max-age=604800
Content-Type: application/javascript; charset=utf-8
Content-Encoding: gzip
ETag: 0.0.459,0.0.0,0.00
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
ItemType: FORMS
Digest: e0d3a2bdee4c0a48bc4f61bb744755c21c1d6c19
X-Powered-By: ASP.NET
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Headers: callfrom, content-type, runtimecalltype
Access-Control-Allow-Credentials: true
Date: Tue, 12 Apr 2016 11:46:48 GMT
Content-Length: 31763
1

1 Answers

1
votes

I've identified the root causes for ETags not working in my scenario:

  • I should have looked at the If-None-Match request header field rather than expecting an ETag field be provided to the server (more details here Header Field Definitions)
  • I should have not used commas in my ETag respose header field value, only the sub-string before the first comma gets sent back in request header field If-None-Match. In my case the ETag value in respose header was 0.0.459,0.0.0,0.00 and the subsequent request had 0.0.459 in the If-None-Match header field.

Response header from server now: HTTP/1.1 304 Not Modified :)