Chrome Web-Developer Tool Registerkarte sagt Dojo AJAX-Anfragen um 44 Jahre nehmen abzuschließen

Question

Die Chrome Registerkarte Netzwerk in den Web Developer Tools zeigt, dass ein paar meiner AJAX-Anfragen 16.027,8 Tage nehmen abzuschließen. Das ist ... nicht wie lange sie dauern.

Ich kann dies auf mehreren Maschinen replizieren, und zwar in Entwicklungs- und Produktionsumgebungen. Dies geschieht für alle Dojo AJAX-Anfragen, die stattfinden onload. Es ist nicht möglich für andere Webapps oder Anfragen von Drittanbietern (wie AJAX oder Facebook).

Was ist los? Schafft unser Server das irgendwie? Ist es ein Fehler in Chrome-Entwicklungstools (ist es fast sicher, oder?), Und wenn ja, kann man etwas dagegen tun? Es macht den visuellen Wasserfall ziemlich nutzlos, wie Sie sich vorstellen können.

Edit: Nach neuen Informationen scheint dies ein häufiges Problem mit IBM Websphere Commerce-Sites zu sein. Was kann der Server oder der Code verursachen? Schauen Sie hier für Beispiele:

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

Edit 2: Dieses Problem wurde in der neuesten Version von Chrome festgelegt ist.

Answer 1

Dieses Problem bezieht sich nicht auf das Web-Framework oder den Server. Das Problem betrifft die Chrome-Browserversion 31.0.1650.57.

Jetzt Problem ist behoben und wird mit nächsten stabilen Kanal-Update geliefert.Fix diff

Wenn Sie dringend brauchen zu beheben, können Sie aktualisieren Kanal-Version dev. Instructions

Siehe this issue für weitere Details.

Answer 2

Sehr merkwürdig. Kann auch unter OS X Mavericks auf Chrome 31.0.1650.57 neu erstellt werden. Getestet mit Ikea-Link, bemerkte Chrome 16028.7 Tage, 41 ms Latenz für Ressource /us/en/iows/tealium.

Charles Proxy zeigt diese Header:

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 

Der Proxy-App (Charles) berichtet, keine solche ungerade Zeit - es zeigt 40ms.

Der lavieenrose.com-Link verursachte, dass Chrome die Zeit von 16028.7 Tage ebenso berichtet ... das scheint zu sein, gemeinsam zu sein. Charles zeigt:

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 

Meine Schlussfolgerung ist, ist dies nicht eine Antwort des Servers oder Header Problem. Ich denke, das ist ein Chromium oder WebKit Dev Tools Problem.

Hier HEAD der Entwickler-Tools JS Objekt, das die HTTP-Anforderung darstellt, die von der Registerkarte Netzwerk gemacht:

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

Ich bin in set endTime() über die Mathematik fragen:

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; 
    } 
}, 

Noch keine Antworten, aber vielleicht jemand, der mehr darüber weiß, was WebKit/Chromium DevTools so sieht ...