Bei der Entwicklung einer bestimmten Website habe ich ein zeitweiliges Problem beim Laden der Website in Firefox (konnte nicht in IE oder Chrome vergleichen). Die Website lädt mehrere Javascript-Dateien, CSS-Stylesheets, Bilder usw. Gelegentlich können eine oder mehrere der Dateien nicht ordnungsgemäß geladen werden. Die Antwort zeigt einen Status von 200 OK an, aber die Inhaltslänge gibt 0 an. Dies geschieht auf verschiedenen Dateien zu unterschiedlichen Zeiten. Wenn es sich um eine JavaScript-Datei handelt, die nicht geladen werden kann, funktioniert die Website nicht ordnungsgemäß, aber möglicherweise weiterhin Inhalt. Wenn es passiert, die Datei index.html sein, die nicht geladen werden kann, zeigt Firefox eine leere Seite mit dem folgenden html:HTTP-Anfrage gibt 200 OK, aber keinen Inhalt als Antwort
<html>
<head></head>
<body><pre></pre></body>
</html>
(Ich glaube, das als Standard von Firefox kommt „leer“ Seitenaufruf)
Es scheint, dass vorherige erfolgreiche Ladevorgänge ordnungsgemäß aus dem Browser-Cache abgerufen werden können und der Antwortstatus 304 nicht geändert lautet. Nach einem Fehler sehen wir das nächste Mal, wenn die Ressource angefordert wird, einen Antwortstatus von 200 OK, wobei nachfolgende Anforderungen erneut mit 304 antworten.
Hier sind Beispiele für die Request/Response-Header, wie Firebug berichtet:
Allgemeine Erfolgsfall: (Antwort Status: 304 nicht geändert, 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 Sockel:
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 von 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 Registerkarte Cache 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: (Antwort Status: 200 OK, Content-length: 0)
Anforderungsheader:
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 Registerkarte Cache 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)
Weiter Erfolgsfall: (Antwort Status: 200 OK, Content-length: 288)
Anforderungsheader:
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 Registerkarte Cache 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)
wir die Seite in JBoss-EAP v6.1 hosten, und ich habe schon versucht, diese in Firefox 10, 17 und 24 mit den gleichen Ergebnissen. Ich verstehe, dass es neuere Versionen gibt (nicht zu erwähnen verschiedene Browser), aber sie sind nicht unbedingt eine Option für uns. Ich hoffe, dass die Lösung eine einfache Konfigurationsänderung ist, aber bei meinen Versuchen, nach diesem Problem zu suchen, habe ich niemanden gesehen, der das gleiche Problem hat, also ist es vielleicht nicht so einfach. Ich freue mich über Vorschläge. Bitte lassen Sie mich auch wissen, wenn ich weitere Informationen bereitstellen muss (z. B. web.xml, jboss.conf, etc
)Weitere Produkte in der Mischung:
- Require.js v2.1.2
- Java 1.6
- CAS 3.2.1
- Atmosphäre 2.1.3
Update: Ich habe die Möglichkeit eines Cache-Problems im Wesentlichen ausgeschlossen. Ich implementiert einen Cache-Busting-Modul Ladeprozess wie in der RequireJS API Seite vorgeschlagen, und ich immer noch das Problem sehen. Diesmal sind sie jedoch statt aller 304 Statuscodes alle 200er.
Update 2: ich die Quelle für jbossweb 7.2.0.Final heruntergeladen und bearbeitet dieses Problem durch das Debuggen. Offenbar gibt es eine Klasse org.apache.coyote.http11.Http11ConnectionHandler genannt, die einen Pool von Http11Processor Instanzen unterhalten, jede mit ihren eigenen Request und Response-Objekten. Wenn eine Anfrage abgeschlossen ist, wird der Http11Processor "recycled" und in den Pool zurückgelegt.
Es scheint, dass in der Wiederverwendungslogik ein Threading-Problem auftreten kann, da Response.recycle das "committed" auf false setzen soll, aber mein (bedingter) Haltepunkt unmittelbar nach dem Aufruf von response.recycle() stoppt mit antwort.committed == wahr. Dies verursacht später die fehlgeschlagenen Antworten. Wenn ein Http11Processor ein bereits festgeschriebenes Response-Objekt enthält, kann die Response nicht zum Zurückgeben von Informationen verwendet werden. Es reagiert einfach mit Status: 200, Content-Length: 0
Dies scheint der Fall zu sein, wenn ich eine Webseite zu schließen, die eine Atmosphäre Verbindung hat, die Server-Side-Events verwendet. Benutzt ich die Atmosphere-Verbindung nicht richtig? Gibt es eine spezielle Bereinigungslogik, die ich implementieren sollte?
Hallo, ich benutze jboss eap 6.4, primefaces 5.3 und Atmosphäre 2.4.8. Ich habe genau das selbe Problem wie du, aber nachdem ich die org.apache.catalina.connector.RECYCLE_FACADES Eigenschaft zu standalone.xml hinzugefügt habe, bin ich auf eine Ausnahme gestoßen (Interceptor Atmosphere LifeCycle abgestürzt. Die Verarbeitung wird mit einem anderen Interceptor fortgesetzt: java.lang .IllegalStateException: JBWEB000057: Das Anforderungsobjekt wurde wiederverwendet und ist nicht mehr mit dieser Fassade verknüpft). Haben Sie ein ähnliches Problem festgestellt? – bluebloodedboy
Ich habe diese Ausnahme gesehen. Ich habe eine Menge anderer Arbeiten um Atmosphere getan, die AtmosphereResource-Instanzen aufräumen, hauptsächlich aufgrund der Tatsache, dass ich den BlockingIOCometSupport verwende (nur wegen eines Mangels an AsyncIO-Unterstützung). In unserer Anwendung gibt es genügend Durchläufe durch AtmosphereResources, dass diese Ausnahme keine drastischen Probleme verursacht hat (die wir bisher bemerkt haben). – pacifier21