Apache konvertiert jsp-Seiten fälschlicherweise in "text/plain"

Question

Ich habe ein ziemlich normales Setup, bei dem Apache Proxies Anfragen an ein Servlet in Tomcat über das AJP-Protokoll sendet.

Wir haben dieses Setup auf Apache 2.0.46/Tomcat 5.0.28 seit Jahren ohne Probleme ausgeführt, aber kürzlich auf Apache 2.2.3/Tomcat 5.5 aktualisiert.

Das Problem ist, dass wir festgestellt haben, dass Apache den HTTP-Header "Content-Type" einer Seite, die vom Servlet bedient wird, von "text/html" nach "text/plain ", was dazu führt, dass der Browser die HTML-Quelle anzeigt, anstatt sie zu rendern.

Hat jemand diese Art von Verhalten schon einmal gesehen und weiß, was die Ursache sein könnte? Ich vermute, wir machen etwas Schlechtes in unserem Servlet-Code, dem die alte Version von Tomcat/Apache mehr vergab.

Update: Ich habe bestätigt, dass Apache die Header ändert. Wenn ich direkt zu Tomcat blicke, tritt das Problem nicht auf.

Answer 1

Ok. Habe ich es aus, es ist ein Fehler in dem Servlet-Code war:

Wir waren so etwas wie dies tun serialisierte Java-Objekte als Ergebnis der HTTP-Anfragen zu schreiben:

DeflaterOutputStream dos = new DeflaterOutputStream(response.getOutputStream()); 
ObjectOutputStream oos = new ObjectOutputStream(dos); 
response.setContentType("application/x-java-serialized-object"); 
oos.writeObject(someObject); 

Was war passiert zu sein schien, Die DeflaterOutputStream und ObjectOutputStream würden drei oder vier Anfragen später zu Garbage-Collected kommen, wenn sie noch an den Output-Stream des Response-Objekts angehängt wären und dies würde dazu führen, dass etwas im Stream passiert, das Apache verwirrte und dazu führte, dass es die Header neu schrieb.

ersetzt ich das oben mit:

ByteArrayOutputStream byteStream = new ByteArrayOutputStream(); 
DeflaterOutputStream dos = new DeflaterOutputStream(byteStream); 
oos = new ObjectOutputStream(dos); 
response.setContentType("application/x-java-serialized-object"); 
oos.writeObject(someObject); 
oos.flush(); 
dos.finish(); 
byteStream.writeTo(response.getOutputStream()); 

und das Problem ist verschwunden.

die folgenden Links scheinen ein ähnliches Problem zu beschreiben:

• AJP Flush Packet causing text/plain
• ASF Bugzilla – Bug 43478

Answer 2

Wenn dieses Problem mit Unterbrechungen auftritt, ist es fast sicher, dass etwas im Servlet-Code vorliegt und nicht eine Fehlkonfiguration von Tomcat oder httpd. Haben Sie eine Protokollierung, die Sie aktivieren können, um den Inhalt der HTTP-Header zu drucken?

Um das Problem ein wenig weiter zu isolieren, können Sie auch versuchen, httpd zu umgehen und direkt zu den Tomcat-URLs für Ihre Seiten zu gehen.

Ich habe dieses bestimmte Verhalten nicht vor mir selbst gesehen, so sorry kann ich nicht genauer sein.

Answer 3

Mit Unterbrechungen, meinst du, dass einige Seiten dieses Verhalten zeigen und andere nicht, oder dass es Seiten gibt, die manchmal das Verhalten zeigen und manchmal nicht?

Können Sie eine Protokollierung an die AJP-Schicht anhängen, um HTTP-Header auf dieser Ebene zu protokollieren, damit Sie überprüfen können, ob Apache oder Tomcat die falsche Kopfzeile hinzugefügt haben?

Answer 4

Sie aggregieren zurück zu einem Cluster? Vielleicht ist einer der Server falsch konfiguriert.

Answer 5

Einige Webapps nicht richtig eingestellt MIME-Typen von Inhalten, die sie dienen, aber immer noch richtig funktionieren kann, wenn wird eigenständig bereitgestellt, da Clientanwendungen wie Browser den Typ des Inhalts interpretieren können. Wenn sie jedoch hinter Apache ausgeführt werden, verhalten sich diese Apps nicht korrekt, da Apache einen Standardtyp für text/plain bereitstellt.

Eine Lösung ist es, eine Default Keine Zeile in Apache Virtual Host für diese Web-Anwendungen hinzuzufügen:

DefaultType None 

http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype

Von meinem Blog-Post: http://patternbuffer.wordpress.com/2011/11/30/mime-type-issue-with-apache-mod_jk-and-mod_proxy-serving-plain-text/

Answer 6

ich auch war mit Blick auf Das gleiche Problem wurde gelöst. Wenn ein Problem in nur einem Ordner auftritt, dann gibt es ein Servlet, das die Anfrage/Antwort blockiert und eine benutzerdefinierte Anfrage/Antwort an tomcat anlegt. Tomcat 7.0.x