HTTP-Anforderung gibt 200 OK aber keine inhaltliche Reaktion
In der Entwicklung eine bestimmte web-site, ich habe eine intermittierende Problem beim laden der Seite im Firefox (noch nicht in der Lage gewesen, zu vergleichen, in IE oder Chrome). Die Website lädt mehrere javascript-Dateien, css-stylesheets, Bilder, usw.. Gelegentlich eine oder mehrere der Dateien nicht korrekt geladen. Die Antwort gibt einen status 200 OK, aber der content-length gibt an, 0. Dies geschieht auf unterschiedliche Dateien an unterschiedlichen Zeiten. Wenn es eine javascript-Datei nicht laden, die Seite funktioniert nicht richtig, aber kann immer noch anzeigen von Inhalten. Wenn es passiert, werden die index.html Datei, die nicht geladen, Firefox zeigt nur eine leere Seite mit dem folgenden html-Code:
<html>
<head></head>
<body><pre></pre></body>
</html>(Ich glaube, das kommt von Firefox als Standard - "leere" Seite anzeigen)
Scheint es, dass frühere erfolgreiche Lasten kann abgerufen werden ordnungsgemäß aus dem browser-cache, und die Antwort ist der status 304 not Modified. Nach einem Fehler wird die Ressource das nächste mal angefordert wird, sehen wir eine response status 200 OK-die nachfolgenden Anfragen wieder reagiert (304) ist.
Hier sind Beispiele für die request - /response-Header, wie berichtet, von Firebug:
Allgemeinen Erfolg Fall: (Response Status: 304 not Modified, Content-length: 288)
- Request-Header:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<shouldn't matter>
Host: ???.???.???.???:8442
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT
If-None-Match: W/"228-1398777506000"
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0 Antwort-Header:
Cache-Control: no-cache
Date: Tue, 29 Apr 2014 13:36:35 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Pragma: No-cache
Server: Apache-Coyote/1.1 Antwort-Header Aus Dem Cache:
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 288
Content-Type: text/javascript
Date: Tue, 29 Apr 2014 13:36:35 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT
Pragma: No-cache
Server: Apache-Coyote/1.1 Die Cache-tab in Firebug zeigt Folgendes an:
Data Size: 288
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 81
Last Fetched: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT) Fehlgeschlagen Fall: (Response Status: 200 OK Content-length: 0)
- Request-Header:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<same as above>
Host: ???.???.???.???:8442
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT
If-None-Match: W/"228-1398777506000"
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0 Antwort-Header:
Content-Length: 0
Date: Tue, 29 Apr 2014 13:36:28 GMT
Server: Apache-Coyote/1.1 Die Cache-tab in Firebug zeigt Folgendes an:
Data Size:
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 83
Last Fetched: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT) Nächsten Erfolg Fall: (Response Status: 200 OK Content-length: 288)
- Request-Header:
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<same as above>
Host: ???.???.???.???:8442
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0 Antwort-Header:
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 288
Content-Type: text/javascript
Date: Tue, 29 Apr 2014 13:37:03 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT
Pragma: No-cache
Server: Apache-Coyote/1.1 Die Cache-tab in Firebug zeigt Folgendes an:
Data Size: 288
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 85
Last Fetched: Tue Apr 29 2014 08:28:54 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:53 GMT-05:00 (CDT) Sind wir das hosting der Website in der JBoss-EAP-v6.1, und ich habe versucht, das in Firefox 10, 17 und 24 mit dem gleichen Ergebnis. Ich verstehe, es gibt neuere Versionen verfügbar sind (ganz zu schweigen von den verschiedenen Browsern), aber Sie sind nicht unbedingt eine option für uns. Ich hoffe die Lösung ist eine einfache änderung der Konfiguration, aber meine versuche, bei der Suche nach dieser Ausgabe habe ich nicht gesehen, dass jemand das gleiche problem, also kann es nicht so einfach. Ich freue mich über jede Anregungen. Auch, bitte lassen Sie mich wissen, wenn ich mehr Informationen liefern (z.B., web.xml, jboss.conf, etc)
Anderen Produkte in der Mischung:
- Require.js v2.1.2
- Java 1.6
- CAS 3.2.1
- Atmosphäre 2.1.3
Update: ich habe im wesentlichen ausgeschlossen, die Möglichkeit der ein cache-Problem. Implementiert habe ich eine cache-busting-Modul laden-Prozess wie bereits in der RequireJS-API Seite, und ich sehe immer noch das problem. Dieses mal jedoch, anstatt alle 304 status-codes, Sie sind alle 200.
Update 2: ich habe die Quelle für JBossWeb 7.2.0.Finale und arbeitete debugging dieses Problems. Offenbar gibt es eine Klasse namens org.apache.coyote.http11.Http11ConnectionHandler, die verwaltet einen pool von Http11Processor Instanzen, jede mit Ihrer eigenen Request-und Response-Objekte. Wenn eine Anfrage abgeschlossen ist, wird die Http11Processor wird "recycelt" und wieder in den pool.
Scheint es, dass es ein threading-Problem in der recycling-Logik, weil Sie die Antwort.recyceln soll, um die "engagierten" auf false, aber meine (bedingte) Haltepunkt unmittelbar nach Aufruf von Antwort.recycle() Stoppt mit Antwort.verpflichtet == true. Dies ist, was bewirkt, dass die fehlgeschlagenen Antworten später auf. Wenn ein Http11Processor enthält eine bereits begangene Response-Objekt, die Antwort kann nicht verwendet werden, um wieder alle Informationen. Es antwortet einfach mit dem Status: 200 Content-Length: 0.
Dies scheint passiert zu sein, wenn ich in der Nähe eine website, die hat eine Atmosphäre, die Verbindung mit Server-Side-Events. Bin ich mit der Atmosphäre in Verbindung falsch? Gibt es spezielle cleanup-Logik sollte ich umsetzen?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Nach viel Untersuchung und Debuggen habe ich herausgefunden, dass die Atmosphäre der Bibliothek zu dürfen, manipulieren, ein Antwort-Objekt hatte, wurden recycelt und gewöhnungsbedürftig für eine spätere Anfrage. Die betroffenen Antwort gegeben wurde, ein status 200, content-Länge 0, und es begangen wurde, so dass keine weiteren änderungen vorgenommen werden könnten. Die Pech-Anfrage-thread, ist angesichts dieser "beschädigt" Response-Instanz nicht verwendet werden, um den eigentlichen Inhalt.
Um zu verhindern, dass diese änderung Auswirkungen auf die JBoss-server, ich habe Folgendes in der jboss.Eigenschaften Datei:
Andere Möglichkeit ist die Verwendung eines Security MANAGERS.
(Siehe den Abschnitt zur Sicherheit diese Seite, und der Beratung in den letzten paar Absätze diese Seite)
Diese offenbar verhindert, dass das recycling von Anfragen und Antworten, so dass wir immer eine neue Antwort-Instanz für jede Anforderung.
Haben Sie wahrscheinlich ein try-catch-block, der beim schlucken den Fehler und erzeugt keine Ausgabe. Es könnte sein, die Protokollierung der Fehler irgendwo.