locked
HTTP Response Header Variable returns null in IE 11 RRS feed

  • Question

  • I am using Javascript to access the value of the HTTP Response Variable, Server, and am displaying the value on the web page, as a test. Once this is successful, I will be executing other logic based on the value returned in the variable. Essentially I want to handle some operations differently depending on whether the server is IIS or Apache.

    In my test Javascript, I am alerting all response headers (getAllResponseHeaders()) and the Server response header (getResponseHeader("Server")), then I am passing the value of getResponseHeader("Server") onto a field on the web page.

    I have tested this with 4 browsers, so far. It works fine in Chrome, in Safari on Windows and also in Safari on an iPad tablet. In IE 11, the first time I execute the Javascript, it works correctly, getResponseHeader("Server") returns Apache or Microsoft-IIS/8.0 depending on the backend web server. In subsequent executions on IE 11, though, getResponseHeader("Server") returns a null value. If I delete browsing history, it will work again once, but after that I receive null for the value.

    Is this a bug in IE 11? Or is there some setting that will change the behaviour to what I am expecting, and what the other browsers deliver, - the Server response value each time? Or is there a better, more reliable way to retrieve this value in IE?

    Wednesday, March 5, 2014 3:46 PM

Answers

  • The data in my answer is the output of SnapshoTIF, a utility I wrote that enumerates the WinINET cache using the native APIs.

    IE maintains the Last-Modified and Expiration time as native date fields; my recollection is that it regenerates "fake" headers with the values in question when XHR calls the GetAllResponseHeaders method.


    Tuesday, March 11, 2014 7:00 PM

All replies

  • Hi,

    f12>Networking tab, click the "Start" button...

    what is the server response code?

    http://ajaxpatterns.org/Periodic_Refresh


    Rob^_^

    Thursday, March 6, 2014 3:50 AM
  • Did not see a "Start" button in the Networking tab. I enabled network traffic capturing, cleared browsing history then clicked the button on my page to execute the Javascript.

    I clicked on Details then Response headers. There were 11 entries in Response headers. All 11 entries had the Key, Server, with a Value of Microsoft-IIS/8.0.

    I clicked the button on the page to execute the Javascript again. I clicked on Details then Response headers. There are 11 entries in Response headers, as before, but this time none of the entries contain the key Server. The result is the same if I click the button again.

    If I clear browsing history the whole process is repeated - Server key is returned the first time only.

    If this is not what I should have done, please advise.

    Thursday, March 6, 2014 5:05 AM
  • Try using "POST" instead of "GET". Alternatively, if using "GET" add a random parameter to the url.
    Thursday, March 6, 2014 11:27 PM
  • "POST" didn't work. I received a "not allowed" error.

    Using "GET" and adding the random parameter to the url (url + "?=" + Math.random) worked.

    Thanks for your help.

    Friday, March 7, 2014 4:37 AM
  • The Date, Cache-Control, and Server headers are stripped out when the entry is committed to the WinINET cache (see the dump below), and thus aren't available when your XHR sends the same request and pulls the response from the cache.

    Stripping of headers like this didn't really matter back in the very old days (IE4) when it was likely introduced, because these headers weren't accessible to pages, but this changed with the introduction of the XmlHttpRequest object.

    You should consider filing a bug on CONNECT about this behavior.

    ENTRY: https://googledrive.com/host/0B8BLd2qPPV7XT2xUekEzV2ZJUzg
    FLAGS: 0x00000041 [NORMAL_CACHE_ENTRY, INTERNAL_HTTP_1_1_CACHE_ENTRY]
    CACHE FILE: C:\Users\lawrence\AppData\Local\Microsoft\Windows\INetCache\IE\K1EVHRDM\0B8BLd2qPPV7XT2xUekEzV2ZJUzg[1].htm
    HIT COUNT: 1
    FILE SIZE: 5,435
    __HEADERS__
    HTTP/1.1 200 OK
    Content-Type: text/html
    Access-Control-Allow-Origin: *
    Access-Control-Allow-Credentials: false
    Access-Control-Allow-Headers: Accept, Accept-Language, Authorization, Cache-Control, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-MD5, Content-Range, Content-Type, Date, GData-Version, Host, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, Origin, OriginToken, Pragma, Range, Slug, Transfer-Encoding, X-ClientDetails, X-GData-Client, X-GData-Key, X-Goog-AuthUser, X-Goog-PageId, X-Goog-Encode-Response-If-Executable, X-Goog-Correlation-Id, X-Goog-Request-Info, X-Goog-Upload-Command, X-Goog-Upload-Content-Disposition, X-Goog-Upload-Content-Length, X-Goog-Upload-Content-Type, X-Goog-Upload-Offset, X-Goog-Upload-Protocol, X-Goog-Visitor-Id, X-HTTP-Method-Override, X-JavaScript-User-Agent, X-Origin, X-Referer, X-Upload-Content-Length, X-Upload-Content-Type, X-Use-HTTP-Status-Code-Override, X-YouTube-VVT, X-YouTube-Page-CL, X-YouTube-Page-Timestamp
    Access-Control-Allow-Methods: GET,OPTIONS
    Alternate-Protocol: 443:quic
    Content-Length: 5435

    Entry Expires: 3/7/2014 5:05:10 PM 130387071100773209
    Last Modified: 3/7/2014 3:26:01 PM 130387011610000000
    Last Synced:   3/7/2014 5:04:50 PM 130387070900773209
    Last Accessed: 3/7/2014 5:04:50 PM 130387070900773209

    • Proposed as answer by EricLaw [Edge] Tuesday, March 11, 2014 6:58 PM
    Friday, March 7, 2014 11:07 PM
  • Unfortunately the unique url parameter ( try +"?uniqParam="+new Date().getTime() ) fills the cache with copies of the same page.

    Another way around this could be to try using a non-existent filename (or filename extension) in the url. For an asynchronous request include:

    if(xmlhttp.status===404){ [do something with xmlhttp.getResponseHeader("Server")] }

    Or why not just use "POST" with a correct url and test for 200 and 405 status - eg

    if(xmlhttp.status===200||xmlhttp.status===405){ [do something with xmlhttp.getResponseHeader("Server")] }

    (Both of the above assume you are not interested in any responseText.)


    • Edited by mystifeid Saturday, March 8, 2014 5:16 PM
    Saturday, March 8, 2014 3:35 PM
  • Yes, using the "HEAD" method is the best solution.
    Sunday, March 9, 2014 7:47 AM
  • The data in my answer is the output of SnapshoTIF, a utility I wrote that enumerates the WinINET cache using the native APIs.

    IE maintains the Last-Modified and Expiration time as native date fields; my recollection is that it regenerates "fake" headers with the values in question when XHR calls the GetAllResponseHeaders method.


    Tuesday, March 11, 2014 7:00 PM