The Chrome Network Tab in the Web Developer Tools shows that a bunch of my AJAX requests are taking 16027.8 days to plete. This is... not how long they are taking.

I can replicate this on multiple machines, and in both development and production environments. This happens for all Dojo AJAX requests that are happening onload. It doesn't happen for other webapp or 3rd party requests (like signin AJAX or facebook).

What is going on? Is our server somehow screwing this up? Is it a bug in chrome dev tools (it almost certainly is, right?), and if so, is there anything that can be done about it? It makes the visual waterfall pretty useless, as you can imagine.

Edit: Upon new information, this seems to be a mon problem with IBM Websphere Commerce sites. What about the server or code could be causing this? Look here for examples:

Edit 2: This issue is fixed in the newest version of Chrome.

The Chrome Network Tab in the Web Developer Tools shows that a bunch of my AJAX requests are taking 16027.8 days to plete. This is... not how long they are taking.

I can replicate this on multiple machines, and in both development and production environments. This happens for all Dojo AJAX requests that are happening onload. It doesn't happen for other webapp or 3rd party requests (like signin AJAX or facebook).

What is going on? Is our server somehow screwing this up? Is it a bug in chrome dev tools (it almost certainly is, right?), and if so, is there anything that can be done about it? It makes the visual waterfall pretty useless, as you can imagine.

Edit: Upon new information, this seems to be a mon problem with IBM Websphere Commerce sites. What about the server or code could be causing this? Look here for examples:

http://www.ikea./us/en/catalog/categories/departments/kitchen/# http://www.lavieenrose./webapp/wcs/stores/servlet/LVER_10052_10001_-1 http://www.ferragamo./shop/en/usa

Edit 2: This issue is fixed in the newest version of Chrome.

• javascript
• ajax
• google-chrome
• websphere
• google-chrome-devtools

Share Follow edited Dec 17, 2013 at 17:56 MattDiamant asked Nov 20, 2013 at 19:16 MattDiamantMattDiamant 8,82144 gold badges3838 silver badges4747 bronze badges 8

• 1 Pretty good latency for that long of a request. – Adam Jenkins Commented Nov 20, 2013 at 19:22
• 1 This is Chrome Version 31.0.1650.57 m on Windows 7, if that's any help. – MattDiamant Commented Nov 20, 2013 at 19:35
• Did you try running it with all the add ons disabled in the browser? – epascarello Commented Nov 20, 2013 at 19:35
• 1 I just ran it again in Incognito mode (which disables extensions), and the results are the same. – MattDiamant Commented Nov 20, 2013 at 19:37
• 1 Just realized that 16041 days ago was January 1, 1970. EPOCH FAIL. – MattDiamant Commented Dec 4, 2013 at 20:46

 |  Show 3 more ments

2 Answers 2

Sorted by: Reset to default 7

This issue is not related to web framework or server. Issue affects Chrome browser version 31.0.1650.57.

Now issue is fixed and will be delivered with next stable channel update. Fix diff

If you need fix urgently, you can update to dev channel version. Instructions

See this issue for more details.

Very odd. Able to recreate on Chrome 31.0.1650.57 on OSX Mavericks as well. Tested w/ ikea link, noticed Chrome reported 16028.7 days, 41ms latency for resource /us/en/iows/tealium.

Charles proxy shows these headers:

HTTP/1.1 304 Not Modified
Content-Type: application/json
Last-Modified: Mon, 18 Nov 2013 18:34:51 GMT
Cache-Control: public, max-age=7200
Date: Sat, 23 Nov 2013 00:32:26 GMT
Connection: keep-alive
Vary: Accept-Encoding

The proxy app (Charles) reports no such odd time - it shows 40ms.

The lavieenrose. link caused Chrome to report time of 16028.7 days as well... that seems to be in mon. Charles shows:

HTTP/1.1 200 OK
Date: Sat, 23 Nov 2013 00:46:37 GMT
Server: IBM_HTTP_Server
Last-Modified: Tue, 19 Jun 2012 13:05:34 GMT
ETag: "5c487f-1a15-4c2d2f01a0380"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1738
Content-Type: application/x-javascript

My conclusion is this isn't a server response or headers issue. I think this is a Chromium or WebKit dev tools issue.

Here's HEAD of the dev tools JS object that represents the http request which rendered by the Network tab:

https://code.google./p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/NetworkRequest.js

I'm wondering about the math in set endTime():

set endTime(x)
{
    if (this.timing && this.timing.requestTime) {
        // Check against accurate responseReceivedTime.
        this._endTime = Math.max(x, this.responseReceivedTime);
    } else {
        // Prefer endTime since it might be from the network stack.
        this._endTime = x;
        if (this._responseReceivedTime > x)
            this._responseReceivedTime = x;
    }
},

No answers just yet, but perhaps someone with more insight into what WebKit/Chromium DevTools may see this...