Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bernd,
On 6/1/2011 1:04 PM, Lentes, Bernd wrote:
Okay. Can you post your servlet code, then?
I have to ask our developers.
Okay.
There is no default Content-Type for HTTP responses, so
getting a response directly from Tomcat might cause the
browser to auto-detect content.
That's what i also believe.
Sounds like Martin Kuen and I had the same idea moments apart.
You might want to properly set the Content-Type header in
your servlet code if you aren't already doing it.
How can i do that ?
You'd have to modify the code like this:
response.setContentType("text/html");
(or whatever content type is appropriate in the situation).
Use of mod_headers or something similar may get this taken care of more
quickly, but fixing the code is a better long-term approach.
Sorry guys, but it still does not make sense :
The response is interpreted perfectly OK when it comes through the HTTP Connector of
Tomcat, on port 8080.
But it is not interpreted OK when it comes through the AJP Connector, on port
8009.
If it was a question of a header set or not set by the servlet, it would be the same in
both cases, no ?
Mmmm, now I get a new suspicion :
Because the Tomcat app does not set a content-type :
- in the case where the browser connects directly to Tomcat, the response comes without
content-type, so the browser "sniffs" and guesses itself, and it happens to do it right.
- but in the case where the response goes through Apache httpd, Apache sees that there is
no content-type, and adds a "text/plain" one.
(Nothing to do with AJP/mod_jk, it is Apache who done it)
That should be visible at the browser level, using a plugin like HttpFox (Firefox) or
Fiddler2 (IE).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
