You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Lentes, Bernd" <be...@helmholtz-muenchen.de> on 2011/05/31 20:09:29 UTC
specifying the content-type
Hi,
first, i'm new to tomcat and i'm not a java developer.
My collegues developed a web application i have to deploy now. I'm using tomcat6 on a sles 11 sp1 box.
I configured a httpd (apache 2.2.10) in front of the tomcat, which communicates with tomcat using AJP.
When i open one link, i don't see the desired web page, but the source code of it. Using tcpdump shows me that the content type in the http-header is text/plain. Ok, that's the reason why i see the source code. Can i configure the content-type which is delivered by tomcat ? I tried using mod_mime_magic on httpd, but this module just helps specifying the content-type of static files. Our content is dynamic.
Thanks in advance.
Bernd
--
Bernd Lentes
Systemadministration
Institut für Entwicklungsgenetik
HelmholtzZentrum münchen
bernd.lentes@helmholtz-muenchen.de
phone: +49 89 3187 1241
fax: +49 89 3187 3826
http://www.helmholtz-muenchen.de/idg
Toleranz beinhaltet das Recht, den Intoleranten gegenüber nicht tolerant zu sein
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bernd,
>
> On 6/7/2011 2:23 PM, Lentes, Bernd wrote:
>> Christopher Schultz wrote:
>>> How did you do it? If you use <META HTTP-EQUIV="Content-Type"
>>> CONTENT="text/html" />, it should override any Content-Type
>>> sent in the HTTP response headers
>> Yes, we used this. But http://de.selfhtml.org/html/kopfdaten/meta.htm#zeichenkodierung (unfortunally only in german) says
>> "Im Konfliktfall, also wenn der Webserver im HTTP-Header eine hiervon abweichende Angabe sendet, wird üblicherweise die Angabe des HTTP-Headers verwendet.", which means that, if you have the META in the HTML-file and also the content-type in the HTTP-Header, mostly the HTTP-Header "wins".
>
> You're right. I had it wrong: the HTTP header overrides the content of
> the document.
Well, it /should/. According to the HTTP RFC.
However, many IE versions (which unfortunately is still the most-widely used browser in
corporate environments) don't give a damn about the Content-type sent by the server, if it
conflicts with their own sniffing of the content.
http://lmgtfy.com?q=ie+and+content-type
>
>>>> Our developers try now to use the
>>>> response.setContentType("text/html"); method to configure the
>>>> content-type in the HTTP-Header.
>>> This is the proper way to do things. Using <META> does not hurt.
>>>
.. at least if both are consistent.
Meanwhile, and as long as your developers are fixing this, you may want to suggest to them
that they also add a character set indication to the Content-type, like :
Content-type: text/html;charset=UTF-8
using for example : response.setContentType("text/html; charset=UTF-8");
(if of course the pages you do send back are encoded using that character set/encoding).
And also add it to your <meta> tag, like so :
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8" />
That will save you other problems down the line, if any of these pages can also submit any
data back to the server, like in
<input name="STADT" value="München">
So to maximise your chances of everything working correctly in a country where not
everyone speaks only English, the following elements should agree :
- the type (text/html) and charset indicated by the server in the Content-type header
- the type and charset indicated in the <meta> tag in the page itself
- the way the page itself was created on the server (with a UTF-8 aware editor, and saved
as UTF-8 without BOM)
In addition, if the page contains a <form> tag, make sure it has the following attribute :
<form .... accept-charset="UTF-8">
The reason for all the above is that HTTP and HTML for historical reasons tend to default
to ISO-8859-1 as a character set, while everything to do with Java (like Tomcat) tends to
default to Unicode/UTF-8. And by not being very precise and consistent, you always run
the risk of mixing them up, which for languages like German leads to very difficult to
debug data corruption problems, the least of which is losanges with "?" in them in your
pages, instead of umlauts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: specifying the content-type
Posted by Rainer Jung <ra...@kippdata.de>.
On 07.06.2011 21:29, Christopher Schultz wrote:
> Bernd,
>
> On 6/7/2011 2:23 PM, Lentes, Bernd wrote:
>> Christopher Schultz wrote:
>>>
>>> How did you do it? If you use <META HTTP-EQUIV="Content-Type"
>>> CONTENT="text/html" />, it should override any Content-Type
>>> sent in the HTTP response headers
>
>> Yes, we used this. But http://de.selfhtml.org/html/kopfdaten/meta.htm#zeichenkodierung (unfortunally only in german) says
>> "Im Konfliktfall, also wenn der Webserver im HTTP-Header eine hiervon abweichende Angabe sendet, wird üblicherweise die Angabe des HTTP-Headers verwendet.", which means that, if you have the META in the HTML-file and also the content-type in the HTTP-Header, mostly the HTTP-Header "wins".
>
> You're right. I had it wrong: the HTTP header overrides the content of
> the document.
With respect to text/plain sent by Apache: This is due to:
http://httpd.apache.org/docs/2.2/en/mod/core.html#defaulttype
So setting
DefaultType none
in Apache should put you into the same browser auto-detect situation
than when talking to Tomcat directly (assuming minimal version Apache
2.2.7). In fact for the forthcoming Apache 2.4 the default has been
switched to none :)
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: specifying the content-type
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bernd,
On 6/7/2011 2:23 PM, Lentes, Bernd wrote:
> Christopher Schultz wrote:
>>
>> How did you do it? If you use <META HTTP-EQUIV="Content-Type"
>> CONTENT="text/html" />, it should override any Content-Type
>> sent in the HTTP response headers
>
> Yes, we used this. But http://de.selfhtml.org/html/kopfdaten/meta.htm#zeichenkodierung (unfortunally only in german) says
> "Im Konfliktfall, also wenn der Webserver im HTTP-Header eine hiervon abweichende Angabe sendet, wird üblicherweise die Angabe des HTTP-Headers verwendet.", which means that, if you have the META in the HTML-file and also the content-type in the HTTP-Header, mostly the HTTP-Header "wins".
You're right. I had it wrong: the HTTP header overrides the content of
the document.
>>> Our developers try now to use the
>>> response.setContentType("text/html"); method to configure the
>>> content-type in the HTTP-Header.
>>
>> This is the proper way to do things. Using <META> does not hurt.
>>
>> So... did it work?
>>
>
> Using the META didn't work, the other way they'll try in the next days. I will inform you.
If you want to be lazy with your code, you could use a Filter to set the
Content-Type of all responses to text/html before the servlet gets a
chance to set anything. If the servlet overrides it, everything is okay.
If not, the Content-Type remains set to text/html.
It's basically the same as using DefaultType in httpd but would require
you to do more work. :(
>
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3ufDAACgkQ9CaO5/Lv0PDsHwCgoMbKhbz20nCj8t8WTY1ZoP+O
AuIAn0Qx5Kse+nHp0jqv8rVJcCkdkdPE
=27hs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Christopher Schultz wrote:
>
> Lentes,
>
> On 6/7/2011 11:36 AM, Lentes, Bernd wrote:
> > first we tried to set the content-type in the <Head> ... </Head>
> > section in the html file. That didn't work.
>
> How did you do it? If you use <META HTTP-EQUIV="Content-Type"
> CONTENT="text/html" />, it should override any Content-Type
> sent in the HTTP response headers
Yes, we used this. But http://de.selfhtml.org/html/kopfdaten/meta.htm#zeichenkodierung (unfortunally only in german) says
"Im Konfliktfall, also wenn der Webserver im HTTP-Header eine hiervon abweichende Angabe sendet, wird üblicherweise die Angabe des HTTP-Headers verwendet.", which means that, if you have the META in the HTML-file and also the content-type in the HTTP-Header, mostly the HTTP-Header "wins".
>
> > Our developers try now to use the
> > response.setContentType("text/html"); method to configure the
> > content-type in the HTTP-Header.
>
> This is the proper way to do things. Using <META> does not hurt.
>
> So... did it work?
>
Using the META didn't work, the other way they'll try in the next days. I will inform you.
> > What i also found out is that you can use a defaulttype
> directive in
> > your Apache configuration.
>
> Yes, you can do that, but you should instead code your
> servlets to return the proper Content-Type.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3uaisACgkQ9CaO5/Lv0PArOQCeLEPqHIn2ePvZNl84Eu6ywlaA
> 6HkAoJJqxDlbi6rGbttOjWyoO3Pi7XWs
> =6EuJ
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: specifying the content-type
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lentes,
On 6/7/2011 11:36 AM, Lentes, Bernd wrote:
> first we tried to set the content-type in the <Head> ... </Head>
> section in the html file. That didn't work.
How did you do it? If you use <META HTTP-EQUIV="Content-Type"
CONTENT="text/html" />, it should override any Content-Type sent in the
HTTP response headers
> Our developers try now to use the
> response.setContentType("text/html"); method to configure the
> content-type in the HTTP-Header.
This is the proper way to do things. Using <META> does not hurt.
So... did it work?
> What i also found out is that you can use a defaulttype directive in
> your Apache configuration.
Yes, you can do that, but you should instead code your servlets to
return the proper Content-Type.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3uaisACgkQ9CaO5/Lv0PArOQCeLEPqHIn2ePvZNl84Eu6ywlaA
6HkAoJJqxDlbi6rGbttOjWyoO3Pi7XWs
=6EuJ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: AW: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Hi,
first we tried to set the content-type in the <Head> ... </Head> section in the html file. That didn't work.
Our developers try now to use the response.setContentType("text/html"); method to configure the content-type in the HTTP-Header.
What i also found out is that you can use a defaulttype directive in your Apache configuration.
This sets the content-type of all what httpd is not able to recognize.
Further information: http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype
I will keep you informed.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: AW: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
...
For whatever reason, httpd wants to send a
> content-type and makes the default (text/plain) explicit for you if none
> is present.
..
per RFC 2616 :
7.2.1 Type
...
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field
defining the media type of that body. If and only if the media type is not given by a
Content-Type field, the recipient MAY attempt to guess the media type via inspection of
its content and/or the name extension(s) of the URI used to identify the resource. If the
media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
So I guess that Apache httpd is trying to do the right thing, as per the HTTP RFC.
I would not be utterly surprised if httpd went to some length about this, and did some
sniffing of its own on the response body, before it decides between "text/plain" and
"application/octet-stream".
And yes, this must be one of these rare case where IE happens to be in conformance with
the RFC, when it sniffs a content that has no Content-type header.
Based upon long experience, I think that this is purely an oversight by the IE developers
however.
;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: specifying the content-type
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 6/2/2011 4:02 PM, André Warnier wrote:
> As others already mentioned, setting the proper header at the Tomcat
> webapp level would be the best solution (and a "clean" application
> should do that anyway).
+1
The lack of a header being set by the webapp is what triggers this
seemingly-strange behavior. For whatever reason, httpd wants to send a
content-type and makes the default (text/plain) explicit for you if none
is present.
With no content-type, most clients will do whatever they think makes
sense, which is usually an auto-detect. Since the page actually contains
HTML markup, the browser makes an educated guess.
The "source" view of the page is simply the client doing exactly what
it's been told to do :)
I'll bet MSIE will work no matter what, because it tends to ignore the
Content-Type header and use it's "best" "judgment" all the time. I
haven't checked to see if MSIE9 or MSIE10 have stopped doing that.
(MSIE9 really turned out to be a great browser, honestly.)
> Trying to set the header at the Apache httpd level is not so clean,
+1
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3s3RMACgkQ9CaO5/Lv0PBZXACcDEIU5CwQE4CsVdZB/vTKBBy0
W+YAoJrd8BhgCZ2r9qEt4xIIUbTA63Y3
=lnem
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
Lentes, Bernd wrote:
> Andre Warnier wrote:
>
>> 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).
>
>
> I mentioned that already :
>
> tcpdump shows that the content delivered by httpd has a content-type of text/plain, the content delivered by tomcat has no content-type. So Andre,
> your assumption is right.
> httpfox would show the same.
>
> I will check if i'm able to set the content-type in httpd, otherwise our developers have to add a header in the http-response, setting the right content type, or we will try a meta element in the head of the
> html code, setting the content-type.
>
As others already mentioned, setting the proper header at the Tomcat webapp level would be
the best solution (and a "clean" application should do that anyway).
Trying to set the header at the Apache httpd level is not so clean, because for instance
there may be different kinds of responses/documents sent by Tomcat (now or in the future),
and not all will be html in nature (think of images, stylesheets e.g.). (and I also saw
javascript files in your Tomcat directories, if I recall correctly.
So in the end your header-setting logic at the Apache level would have to be quite
complicated to do the job correctly.
By the way, my initial scepticism and suppositions were wrong of course, but I was just
following a logical path of most likely to less likely, using the available information.
Most people coming to this list for help are less thorough than you are, and easily fall
prey to the kind of misconfiguration which I mentioned. Luckily for me in a way, because
it provides me with some areas in which I can at least try to help.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
>
>
> Andre Warnier wrote:
>
> >
> > 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).
> >
for the sake of completeness: setting the contenttype using this method worked fine.
Thanks for your help.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
AW: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Andre Warnier wrote:
>
> 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).
I mentioned that already :
tcpdump shows that the content delivered by httpd has a content-type of text/plain, the content delivered by tomcat has no content-type. So Andre,
your assumption is right.
httpfox would show the same.
I will check if i'm able to set the content-type in httpd, otherwise our developers have to add a header in the http-response, setting the right content type, or we will try a meta element in the head of the
html code, setting the content-type.
I will keep you informed.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: specifying the content-type
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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.
Good luck,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3miz0ACgkQ9CaO5/Lv0PBdcgCgpjCnxikUYyTdjdkp1SJU8+DH
qaMAn0DYaJIVz8H55ynT+4+aWvZ44urP
=N3Nq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Christopher Schulz wrote:
>
> On 6/1/2011 5:18 AM, Lentes, Bernd wrote:
> > I use JKMount, and DocumentRoot of httpd and webapps of
> tomcat are not
> > overlapping.
> >
> > [snip]
> >
> > We don't use jsp, we have servlets.
>
> Okay. Can you post your servlet code, then?
I have to ask our developers.
>
> 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.
>
> It's possible that Apache httpd wants to use a Content-Type
> and defaults to text/plain for some reason.
>
> 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 ?
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bernd,
On 6/1/2011 5:18 AM, Lentes, Bernd wrote:
> I use JKMount, and DocumentRoot of httpd and webapps of tomcat are
> not overlapping.
>
> [snip]
>
> We don't use jsp, we have servlets.
Okay. Can you post your servlet code, then?
There is no default Content-Type for HTTP responses, so getting a
response directly from Tomcat might cause the browser to auto-detect
content.
It's possible that Apache httpd wants to use a Content-Type and defaults
to text/plain for some reason.
You might want to properly set the Content-Type header in your servlet
code if you aren't already doing it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3mSFAACgkQ9CaO5/Lv0PBtKQCZAb7EA5ORK2d/cMwodfBiFE/x
umcAnioj4Ujz0sI76Cn/WvqZG7ULnmVy
=Tagb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Christopher Schultz wrote:
>
> On 5/31/2011 2:09 PM, Lentes, Bernd wrote:
> > box. I configured a httpd (apache
> > 2.2.10) in front of the tomcat, which communicates with
> tomcat using
> > AJP.
>
> Do you actually require httpd for your setup? If Tomcat works
> fine on it's own, maybe that's how you should run it...
>
A lot of people recommended that. It's likely that we will deploy more webapps later.
> > When i open one link, i don't see the desired web page, but
> the source
> > code of it.
>
> Do you see the HTML source code, or the JSP source code
> (obviously, only if you are requesting a .jsp file)?
>
I see HTML code.
> If the former, it's likely to be a Content-Type issue as you
> have guessed. Look for broken "Header" directives in
> httpd.conf, especially for the VirtualHost you are using and
> especially in any <Location> sections that you use for your
> JkMount directives.
There are not Header directives.
>
> If the latter, you are probably missing JkMount (or they are
> broken) directives and you are probably either setting
> DocumentRoot to the webapp's root (which is often considered
> very dangerous) or using "Alias" to achieve the same effect.
>
I use JKMount, and DocumentRoot of httpd and webapps of tomcat are not overlapping.
> If you choose to use DocumentRoot = webapp root or a similar "Alias"
> setup, /make sure you know what you are doing/. If you aren't
> careful, you can end up making your "secret" passwords and
> stuff available to any remote user (oops).
>
> > Using tcpdump shows me that the content type in the http-header is
> > text/plain. Ok, that's the reason why i see the source code. Can i
> > configure the content-type which is delivered by tomcat ? I tried
> > using mod_mime_magic on httpd, but this module just helps
> specifying
> > the content-type of static files. Our content is dynamic.
>
> First, let's make sure that the .jsp files are being
> executed. If not, you are chasing the wrong problem.
We don't use jsp, we have servlets.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3lSDkACgkQ9CaO5/Lv0PCzEwCeO1UbGc1WL3QjlpGUWB+jnIA7
> NzcAnRUvspPSP7dRy5imscTvRQcqf/FJ
> =Zyac
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bernd,
On 5/31/2011 2:09 PM, Lentes, Bernd wrote:
> box. I configured a httpd (apache
> 2.2.10) in front of the tomcat, which communicates with tomcat using
> AJP.
Do you actually require httpd for your setup? If Tomcat works fine on
it's own, maybe that's how you should run it...
> When i open one link, i don't see the desired web page, but the
> source code of it.
Do you see the HTML source code, or the JSP source code (obviously, only
if you are requesting a .jsp file)?
If the former, it's likely to be a Content-Type issue as you have
guessed. Look for broken "Header" directives in httpd.conf, especially
for the VirtualHost you are using and especially in any <Location>
sections that you use for your JkMount directives.
If the latter, you are probably missing JkMount (or they are broken)
directives and you are probably either setting DocumentRoot to the
webapp's root (which is often considered very dangerous) or using
"Alias" to achieve the same effect.
If you choose to use DocumentRoot = webapp root or a similar "Alias"
setup, /make sure you know what you are doing/. If you aren't careful,
you can end up making your "secret" passwords and stuff available to any
remote user (oops).
> Using tcpdump shows me that the content type in
> the http-header is text/plain. Ok, that's the reason why i see the
> source code. Can i configure the content-type which is delivered by
> tomcat ? I tried using mod_mime_magic on httpd, but this module just
> helps specifying the content-type of static files. Our content is
> dynamic.
First, let's make sure that the .jsp files are being executed. If not,
you are chasing the wrong problem.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3lSDkACgkQ9CaO5/Lv0PCzEwCeO1UbGc1WL3QjlpGUWB+jnIA7
NzcAnRUvspPSP7dRy5imscTvRQcqf/FJ
=Zyac
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Martin Kuen wrote:
>
> Hi Bernd,
>
> I think your colleagues forgot/didn't want to set the
> content-type in the servlet(-code)?
Yes, i also think they forgot. They are Bioinformatics and don't know much about protocols and web servers.
>
> text/plain is apache default for anything it doesn't know (if I recall
> correctly)
> If no content-type is set by the servlet, no content-type is
> delivered.
> No content-type set by the servlet causes *your browser* to
> start guessing.
> text/html is a pretty solid guess for a browser.
>
> Often a servlet can only generate one kind of content-type.
> If that's the case there's no point in making it configurable.
>
> However, you could use mod_headers to have this set/added by
> apache . . .
>
I will check this out.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by Martin Kuen <ma...@gmail.com>.
Hi Bernd,
I think your colleagues forgot/didn't want to set the content-type in the
servlet(-code)?
text/plain is apache default for anything it doesn't know (if I recall
correctly)
If no content-type is set by the servlet, no content-type is delivered.
No content-type set by the servlet causes *your browser* to start guessing.
text/html is a pretty solid guess for a browser.
Often a servlet can only generate one kind of content-type. If that's the
case there's no point in making it configurable.
However, you could use mod_headers to have this set/added by apache . . .
Best Regards,
Martin
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Pid wrote:
>
> On 01/06/2011 10:55, Lentes, Bernd wrote:
> > lrwxrwxrwx 1 root root 20 Apr 18 16:33 webapps ->
> /srv/tomcat6/webapps/
>
> What is in the webapps dir? A directory called 'mouseidgenes'?
>
Yes.
> If so, what is the file tree in that directory?
>
vm53200-12:~ # l /srv/tomcat6/webapps/mouseidgenes
total 268
drwxr-xr-x 6 tomcat tomcat 4096 May 30 16:55 ./
drwxrwxr-x 8 root tomcat 4096 May 30 16:55 ../
-rw-r--r-- 1 tomcat tomcat 1481 May 20 15:02 Applet.htm
-rw-r--r-- 1 tomcat tomcat 2443 May 9 16:21 Download.html
drwxr-xr-x 2 tomcat tomcat 4096 May 30 16:55 File_Ressources/
-rw-r--r-- 1 tomcat tomcat 2798 May 23 14:35 IDGenesStyle.css
-rw-r--r-- 1 tomcat tomcat 6088 Apr 13 10:40 LinkedSelection.js
drwxr-xr-x 2 tomcat tomcat 4096 May 30 16:55 META-INF/
-rw-r--r-- 1 tomcat tomcat 498 Apr 13 11:53 MailingList.html
drwxr-xr-x 4 tomcat tomcat 4096 May 30 17:03 WEB-INF/
drwxr-xr-x 6 tomcat tomcat 4096 May 30 16:55 classes/
-rw-r--r-- 1 tomcat tomcat 2032 Apr 13 11:54 contact.html
-rw-r--r-- 1 tomcat tomcat 7239 May 9 16:13 help.html
-rw-r--r-- 1 tomcat tomcat 2500 Apr 13 11:55 home.html
-rw-r--r-- 1 tomcat tomcat 443 May 11 13:16 ind2_old.html
-rw-r--r-- 1 tomcat tomcat 378 May 20 15:59 ind_old.html
-rw-r--r-- 1 tomcat tomcat 434 Apr 29 22:31 intSearch_old.html
-rw-r--r-- 1 tomcat tomcat 85925 May 11 09:40 jquery.min.js
-rw-r--r-- 1 tomcat tomcat 37133 Apr 20 12:47 jquery.validate.js
-rw-r--r-- 1 tomcat tomcat 4731 May 4 14:14 main_new.htm
-rw-r--r-- 1 tomcat tomcat 1409 May 20 14:47 menu.htm
-rw-r--r-- 1 tomcat tomcat 1930 Mar 25 10:22 terminAuswahl.js
-rw-r--r-- 1 tomcat tomcat 14537 May 4 09:44 tidy.html
-rw-r--r-- 1 tomcat tomcat 28948 May 9 13:55 xhtml2fo.xsl
> What is "/mouseidgenes/InputData"? Is it a servlet or a JSP?
It's a servlet.
Extract from web.xml:
...
<servlet>
<servlet-name>InputData</servlet-name>
<servlet-class>input.InputData</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>InputData</servlet-name>
<url-pattern>/InputData</url-pattern>
</servlet-mapping>
...
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by Pid <pi...@pidster.com>.
On 01/06/2011 10:55, Lentes, Bernd wrote:
> lrwxrwxrwx 1 root root 20 Apr 18 16:33 webapps -> /srv/tomcat6/webapps/
What is in the webapps dir? A directory called 'mouseidgenes'?
If so, what is the file tree in that directory?
What is "/mouseidgenes/InputData"? Is it a servlet or a JSP?
p
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Andre Warnier wrote:
> Lentes, Bernd wrote:
> > Hi,
> >
> > first, i'm new to tomcat and i'm not a java developer.
>
> You have all my sympathy.
>
> > My collegues developed a web application i have to deploy
> now. I'm using tomcat6 on a sles 11 sp1 box.
> > I configured a httpd (apache 2.2.10) in front of the
> tomcat, which communicates with tomcat using AJP.
> > When i open one link, i don't see the desired web page, but
> the source code of it. Using tcpdump shows me that the
> content type in the http-header is text/plain.
>
> That is typical of a bad/dangerous configuration of Apache,
> mod_jk and Tomcat.
> You are probably
> a) allowing Apache to "see" the contents of the Tomcat
> webapps directory directly (e.g. by setting the Apache
> DocumentRoot = the Tomcat webapps dir.)
No.
webapps=/srv/tomcat6/webapps
DocumentRoot=/srv/www/htdocs
> b) not properly indicating to Apache/mod_jk that these URLs
> must be proxied to Tomcat via mod_jk (JkMount instructions).
>
mod_jk.conf:
...
JkMount /mouseidgenes/* appl01
...
> As a consequence, when you request from Apache a URL like
> (for example) "/myapp/something.jsp", Apache goes directly to
> that file and serves it back to the browser. Of course since
> Apache does not know what a .jsp file is, it treats it as
> plaint text and that is what it says in the Content-type header.
>
>
> Do the following test to confirm the above :
> request the URL "/myapp/WEB-INF/web.xml"
> (where "myapp" is the first part of the URL for a Tomcat application).
HTTP Error 404.
>
> > Can i configure the content-type which is delivered by tomcat ?
>
> You can, but you should not have to, because it is not the
> problem here.
> Tomcat never receives the request for that file;
It does receive the request. I log all the AJP stuff, and you see there, among others:
This is the request from the client:
...
[Tue May 31 20:51:46 2011] [24717:4165998336] [debug] init_ws_service::mod_jk.c (888): Service protocol=HTTP/1.1 method=GET host=(null) addr=146.107.135.80 n
ame=vm53200-12 port=80 auth=(null) user=(null) laddr=146.107.35.101 raddr=146.107.135.80 uri=/mouseidgenes/InputData
...
The reponse:
...
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_unmarshal_response::jk_ajp_common.c (608): status = 200
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_unmarshal_response::jk_ajp_common.c (615): Number of headers is = 0
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): received from ajp13 pos=0 len=8188 max=8192
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0000 03 1F F8 3C 48 65 61 64 3E 3C 74 69 74
6C 65 3E - ...<Head><title>
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0010 4D 6F 75 73 65 49 44 47 65 6E 65 73 3C
2F 74 69 - MouseIDGenes</ti
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0020 74 6C 65 3E 3C 2F 68 65 61 64 3E 0A 0D
0A 3C 73 - tle></head>...<s
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0030 63 72 69 70 74 20 74 79 70 65 3D 27 74
65 78 74 - cript.type='text
[Tue May 31 20:51:48 2011] [24717:4165998336] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0040 2F 6A 61 76 61 73 63 72 69 70 74 27 20
73 72 63 - /javascript'.src
...
> If you want further help, give us an idea of the layout on
> disk of your Apache and Tomcat directories, and of the URLs
> that should be processed by Tomcat.
>
OK:
vm53200-12:/etc/apache2 # l /usr/share/tomcat6/
total 12
drwxr-xr-x 3 root root 4096 Apr 18 16:33 ./
drwxr-xr-x 200 root root 4096 May 30 08:00 ../
drwxr-xr-x 2 root root 4096 Apr 18 16:33 bin/
lrwxrwxrwx 1 root root 12 Apr 18 16:33 conf -> /etc/tomcat6/
lrwxrwxrwx 1 root root 15 Apr 18 16:33 lib -> ../java/tomcat6/
lrwxrwxrwx 1 root root 16 Apr 18 16:33 logs -> /var/log/tomcat6/
lrwxrwxrwx 1 root root 23 Apr 18 16:33 temp -> /var/cache/tomcat6/temp/
lrwxrwxrwx 1 root root 20 Apr 18 16:33 webapps -> /srv/tomcat6/webapps/
lrwxrwxrwx 1 root root 18 Apr 18 16:33 work -> /var/cache/tomcat6/
vm53200-12:/etc/apache2 # l /srv/www/
total 16
drwxr-xr-x 4 root root 4096 Apr 17 17:46 ./
drwxr-xr-x 5 root root 4096 Apr 18 16:33 ../
drwxr-xr-x 2 root root 4096 Apr 17 17:49 cgi-bin/
drwxr-xr-x 3 root root 4096 May 23 18:08 htdocs/
URL that should be processed:
http://vm53200-12/mouseidgenes/InputData
(talking to httpd in front of tomcat, result is source code in the browser)
http://vm53200-12:8080/mouseidgenes/InputData
(talking directly to tomcat coyote, result is a correctly displayed web page).
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
Lentes, Bernd wrote:
> Hi,
>
> first, i'm new to tomcat and i'm not a java developer.
You have all my sympathy.
> My collegues developed a web application i have to deploy now. I'm using tomcat6 on a sles 11 sp1 box.
> I configured a httpd (apache 2.2.10) in front of the tomcat, which communicates with tomcat using AJP.
> When i open one link, i don't see the desired web page, but the source code of it. Using tcpdump shows me that the content type in the http-header is text/plain.
That is typical of a bad/dangerous configuration of Apache, mod_jk and Tomcat.
You are probably
a) allowing Apache to "see" the contents of the Tomcat webapps directory directly
(e.g. by setting the Apache DocumentRoot = the Tomcat webapps dir.)
b) not properly indicating to Apache/mod_jk that these URLs must be proxied to Tomcat via
mod_jk (JkMount instructions).
As a consequence, when you request from Apache a URL like (for example)
"/myapp/something.jsp", Apache goes directly to that file and serves it back to the
browser. Of course since Apache does not know what a .jsp file is, it treats it as plaint
text and that is what it says in the Content-type header.
Do the following test to confirm the above :
request the URL "/myapp/WEB-INF/web.xml"
(where "myapp" is the first part of the URL for a Tomcat application).
If you see the content of the web.xml file in the browser, then the above is probably
true, because Tomcat would never show the content of that file (or anything else in a
WEB-INF directory).
(The reason why I mention above that it is "dangerous", is that by doing that you also
allow Apache to completely go around whatever access security would be configured in Tomcat.)
> Ok, that's the reason why i see the source code.
Yes
> Can i configure the content-type which is delivered by tomcat ?
You can, but you should not have to, because it is not the problem here.
Tomcat never receives the request for that file; it is Apache only which reads that file
and sends it back. So changing something in Tomcat won't help.
> I tried using mod_mime_magic on httpd,
but this module just helps specifying the content-type of static files. Our content is
dynamic.
Yes, and that is like putting new paint on top of schimmel.
You should fix the configuration first.
If you want further help, give us an idea of the layout on disk of your Apache and Tomcat
directories, and of the URLs that should be processed by Tomcat.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Pid wrote:
> >
> >>
> >> Your configuration of mod_jk below looks correct (except a small
> >> detail, see JkMount).
> >> But I must say that it is difficult to believe that the request is
> >> actually forwarded to Tomcat, and that Tomcat then fails
> to recognise
> >> the file as a JSP page, and returns it as "text/plain" source.
> >
> > The content is dynamically delivered by a servlet, not a jsp-file.
>
> And is that Servlet setting the Content-type header to "text/html" ?
>
No. Our developers (they are bioinformatics) don't know much about HTTP and web servers.
I have to talk to them next week.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by Pid <pi...@pidster.com>.
On 03/06/2011 10:22, André Warnier wrote:
> Pid wrote:
>> On 01/06/2011 13:13, Lentes, Bernd wrote:
>>> Andre Warnier wrote:
>>>
>>>> Your configuration of mod_jk below looks correct (except a
>>>> small detail, see JkMount).
>>>> But I must say that it is difficult to believe that the
>>>> request is actually forwarded to Tomcat, and that Tomcat then
>>>> fails to recognise the file as a JSP page, and returns it as
>>>> "text/plain" source.
>>> The content is dynamically delivered by a servlet, not a jsp-file.
>>
>> And is that Servlet setting the Content-type header to "text/html" ?
>>
> No, it doesn't, and that is the source of the problem. See my previous
> post.
Yeah, I saw it after I'd posted...
p
Re: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
> On 01/06/2011 13:13, Lentes, Bernd wrote:
>> Andre Warnier wrote:
>>
>>> Your configuration of mod_jk below looks correct (except a
>>> small detail, see JkMount).
>>> But I must say that it is difficult to believe that the
>>> request is actually forwarded to Tomcat, and that Tomcat then
>>> fails to recognise the file as a JSP page, and returns it as
>>> "text/plain" source.
>> The content is dynamically delivered by a servlet, not a jsp-file.
>
> And is that Servlet setting the Content-type header to "text/html" ?
>
No, it doesn't, and that is the source of the problem. See my previous post.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: specifying the content-type
Posted by Pid <pi...@pidster.com>.
On 01/06/2011 13:13, Lentes, Bernd wrote:
> Andre Warnier wrote:
>
>>
>> Your configuration of mod_jk below looks correct (except a
>> small detail, see JkMount).
>> But I must say that it is difficult to believe that the
>> request is actually forwarded to Tomcat, and that Tomcat then
>> fails to recognise the file as a JSP page, and returns it as
>> "text/plain" source.
>
> The content is dynamically delivered by a servlet, not a jsp-file.
And is that Servlet setting the Content-type header to "text/html" ?
p
RE: RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Igor Cimicov wrote:
>
> Are you using virtual host maybe? If so, the JkMount
> directive has to be inside VirtualHost and not in the global
> apache conf file.
>
> Igor
No.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: RE: specifying the content-type
Posted by Igor Cicimov <ic...@gmail.com>.
Are you using virtual host maybe? If so, the JkMount directive has to be
inside VirtualHost and not in the global apache conf file.
Igor
On Jun 1, 2011 10:14 PM, "Lentes, Bernd" <be...@helmholtz-muenchen.de>
wrote:
Andre Warnier wrote: > > Your configuration of mod_jk below looks correct
(except a > small detail,...
The content is dynamically delivered by a servlet, not a jsp-file.
> Particularly if, as you said earlier, when you access the > same URL on
Tomcat directly, via port...
Yes.
> > The <Connector>'s in Tomcat (the one for HTTP port 8080, and > the one
for AJP on port 8009) ar...
tcpdump shows that the content delivered by httpd has a content-type of
text/plain, the content delivered by tomcat has no content-type.
> > So something in the symptoms you report does not fit. > > Can you : > -
stop Apache > - clear t...
OK:
This should be the beginning of the request forwarded by httpd to tomcat:
...
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
map_uri_to_worker::jk_uri_worker_map.c (682): Attempting to map URI
'/mouseidgenes/InputData' from 1 map
s
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
find_match::jk_uri_worker_map.c (503): Attempting to map context URI
'/mouseidgenes/*=appl01' source 'Jk
Mount'
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
find_match::jk_uri_worker_map.c (516): Found a wildchar match
'/mouseidgenes/*=appl01'
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] jk_handler::mod_jk.c
(2222): Into handler jakarta-servlet worker=appl01 r->proxyreq=0
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
wc_get_worker_for_name::jk_worker.c (115): found a worker appl01
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
wc_maintain::jk_worker.c (323): Maintaining worker appl01
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
wc_get_name_for_type::jk_worker.c (292): Found worker type 'ajp13'
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
init_ws_service::mod_jk.c (888): Service protocol=HTTP/1.1 method=GET
host=(null) addr=146.107.135.80 na
me=vm53200-12 port=80 auth=(null) user=(null) laddr=146.107.35.101
raddr=146.107.135.80 uri=/mouseid...
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_get_endpoint::jk_ajp_common.c (2587): acquired connection pool slot=0
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_marshal_into_msgb::jk_ajp_common.c (553): ajp marshaling done
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_service::jk_ajp_common.c (2058): processing appl01 with 2 retries
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_send_request::jk_ajp_common.c (1352): (appl01) all endpoints are
disconnected, detected by connect c
heck (0), cping (0), send (0)
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
jk_open_socket::jk_connect.c (448): socket TCP_NODELAY set to On
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
jk_open_socket::jk_connect.c (548): trying to connect socket 13 to
127.0.0.1:8009
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
jk_open_socket::jk_connect.c (574): socket 13 connected to 127.0.0.1:8009
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connect_to_endpoint::jk_ajp_common.c (878): Connected socket 13 to (
127.0.0.1:8009)
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (934): sending to ajp13
pos=4 len=433 max=8192
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (934): 0000 12 34 01 AD
02 02 00 08 48 54 54 50 2F 3
1 2E 31 - .4......HTTP/1.1
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (934): 0010 00 00 17 2F
6D 6F 75 73 65 69 64 67 65 6
E 65 73 - .../mouseidgenes
...
And this should be the beginning of the response:
...
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1117): received from ajp13
pos=0 len=10 max=8192
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0000 04 00 C8 00
02 4F 4B 00 00 00 00 00 00 0
0 00 00 - .....OK.........
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_unmarshal_response::jk_ajp_common.c (608): status = 200
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_unmarshal_response::jk_ajp_common.c (615): Number of headers is = 0
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1117): received from ajp13
pos=0 len=8188 max=8192
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0000 03 1F F8 3C
48 65 61 64 3E 3C 74 69 74 6
C 65 3E - ...<Head><title>
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0010 4D 6F 75 73
65 49 44 47 65 6E 65 73 3C 2
F 74 69 - MouseIDGenes</ti
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug]
ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0020 74 6C 65 3E
3C 2F 68 65 61 64 3E 0A 0D 0
A 3C 73 - tle></head>...<s
...
You see the beginning of the html source code.
> > So what I suspect, is that when you look at the mod_jk log, > you see
lines that show that in...
vm53200-12:/etc/apache2 # grep -i decline /var/log/apache2/mod_jk.log
vm53200-12:/etc/apache2 #
nothing found.
Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit
und Umwelt (GmbH) Ingol...
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Andre Warnier wrote:
>
> Your configuration of mod_jk below looks correct (except a
> small detail, see JkMount).
> But I must say that it is difficult to believe that the
> request is actually forwarded to Tomcat, and that Tomcat then
> fails to recognise the file as a JSP page, and returns it as
> "text/plain" source.
The content is dynamically delivered by a servlet, not a jsp-file.
> Particularly if, as you said earlier, when you access the
> same URL on Tomcat directly, via port 8080, the same document
> displays correctly.
Yes.
>
> The <Connector>'s in Tomcat (the one for HTTP port 8080, and
> the one for AJP on port 8009) are just interfaces that
> receive a request in some format, translate it to a common
> internal format, and then forward it in that internal format
> to the internal Tomcat machinery (which is the same in both
> cases). So whether a request is originally received on the
> HTTP Connector or on the AJP Connector, should not make a
> difference in terms of how Tomcat processes the same URL.
> And the result should be returned the same way in both cases.
tcpdump shows that the content delivered by httpd has a content-type of text/plain, the content delivered by tomcat has no content-type.
>
> So something in the symptoms you report does not fit.
>
> Can you :
> - stop Apache
> - clear the mod_jk log
> - restart Apache
> - then issue just one request to "mouseidgenes" through
> Apache (port 80)
> - then edit the mod_jk log, find the lines specific to that
> one request, and paste them here
>
OK:
This should be the beginning of the request forwarded by httpd to tomcat:
...
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] map_uri_to_worker::jk_uri_worker_map.c (682): Attempting to map URI '/mouseidgenes/InputData' from 1 map
s
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] find_match::jk_uri_worker_map.c (503): Attempting to map context URI '/mouseidgenes/*=appl01' source 'Jk
Mount'
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] find_match::jk_uri_worker_map.c (516): Found a wildchar match '/mouseidgenes/*=appl01'
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] jk_handler::mod_jk.c (2222): Into handler jakarta-servlet worker=appl01 r->proxyreq=0
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] wc_get_worker_for_name::jk_worker.c (115): found a worker appl01
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] wc_maintain::jk_worker.c (323): Maintaining worker appl01
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] wc_get_name_for_type::jk_worker.c (292): Found worker type 'ajp13'
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] init_ws_service::mod_jk.c (888): Service protocol=HTTP/1.1 method=GET host=(null) addr=146.107.135.80 na
me=vm53200-12 port=80 auth=(null) user=(null) laddr=146.107.35.101 raddr=146.107.135.80 uri=/mouseidgenes/InputData
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_get_endpoint::jk_ajp_common.c (2587): acquired connection pool slot=0
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_marshal_into_msgb::jk_ajp_common.c (553): ajp marshaling done
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_service::jk_ajp_common.c (2058): processing appl01 with 2 retries
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_send_request::jk_ajp_common.c (1352): (appl01) all endpoints are disconnected, detected by connect c
heck (0), cping (0), send (0)
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] jk_open_socket::jk_connect.c (448): socket TCP_NODELAY set to On
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] jk_open_socket::jk_connect.c (548): trying to connect socket 13 to 127.0.0.1:8009
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] jk_open_socket::jk_connect.c (574): socket 13 connected to 127.0.0.1:8009
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connect_to_endpoint::jk_ajp_common.c (878): Connected socket 13 to (127.0.0.1:8009)
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (934): sending to ajp13 pos=4 len=433 max=8192
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (934): 0000 12 34 01 AD 02 02 00 08 48 54 54 50 2F 3
1 2E 31 - .4......HTTP/1.1
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_send_message::jk_ajp_common.c (934): 0010 00 00 17 2F 6D 6F 75 73 65 69 64 67 65 6
E 65 73 - .../mouseidgenes
...
And this should be the beginning of the response:
...
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): received from ajp13 pos=0 len=10 max=8192
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0000 04 00 C8 00 02 4F 4B 00 00 00 00 00 00 0
0 00 00 - .....OK.........
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_unmarshal_response::jk_ajp_common.c (608): status = 200
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_unmarshal_response::jk_ajp_common.c (615): Number of headers is = 0
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): received from ajp13 pos=0 len=8188 max=8192
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0000 03 1F F8 3C 48 65 61 64 3E 3C 74 69 74 6
C 65 3E - ...<Head><title>
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0010 4D 6F 75 73 65 49 44 47 65 6E 65 73 3C 2
F 74 69 - MouseIDGenes</ti
[Wed Jun 01 14:04:31 2011] [26662:405231360] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1117): 0020 74 6C 65 3E 3C 2F 68 65 61 64 3E 0A 0D 0
A 3C 73 - tle></head>...<s
...
You see the beginning of the html source code.
>
> So what I suspect, is that when you look at the mod_jk log,
> you see lines that show that indeed mod_jk received the
> request URL from Apache, and is trying to match it to one of
> its internally mapped URLs.
> But you may be missing the line that says, in the end, that
> mod_jk could not match the URL, and is returning a response
> "declined" to Apache.
>
>
vm53200-12:/etc/apache2 # grep -i decline /var/log/apache2/mod_jk.log
vm53200-12:/etc/apache2 #
nothing found.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
Re: specifying the content-type
Posted by Pid <pi...@pidster.com>.
On 01/06/2011 11:04, André Warnier wrote:
>> JkMount /mouseidgenes/* appl01
>
> This will forward a request like "/mouseidgenes/index.jsp", but will not
> forward the URL "/mouseidgenes". You may want to add
> JkMount /mouseidgenes appl01
There is a syntax method to address this situation:
JkMount /mouseidgenes/|* appl01
p
Re: specifying the content-type
Posted by André Warnier <aw...@ice-sa.com>.
Lentes, Bernd wrote:
> Charles Caldarale wrote:
>
>>> when talking with a web browser directly to tomcat (port 8080), the
>>> web page is shown correctly.
>> Are you sure the original request on port 80 is actually
>> making it through httpd all the way to Tomcat? The symptoms
>> you're reporting are characteristic of a misconfigured httpd
>> not forwarding anything to Tomcat. Post your mod_jk config
>> for someone (probably not me) to look at.
>>
>
> Currently i'm logging the whole AJP-stuff between httpd and tomcat (that's a lot). This shows that httpd forwards the request to tomcat, and tomcat delivers the response.
>
Your configuration of mod_jk below looks correct (except a small detail, see JkMount).
But I must say that it is difficult to believe that the request is actually forwarded to
Tomcat, and that Tomcat then fails to recognise the file as a JSP page, and returns it as
"text/plain" source.
Particularly if, as you said earlier, when you access the same URL on Tomcat directly, via
port 8080, the same document displays correctly.
The <Connector>'s in Tomcat (the one for HTTP port 8080, and the one for AJP on port 8009)
are just interfaces that receive a request in some format, translate it to a common
internal format, and then forward it in that internal format to the internal Tomcat
machinery (which is the same in both cases). So whether a request is originally received
on the HTTP Connector or on the AJP Connector, should not make a difference in terms of
how Tomcat processes the same URL. And the result should be returned the same way in both
cases.
So something in the symptoms you report does not fit.
Can you :
- stop Apache
- clear the mod_jk log
- restart Apache
- then issue just one request to "mouseidgenes" through Apache (port 80)
- then edit the mod_jk log, find the lines specific to that one request,
and paste them here
To explain :
when a module like mod_jk is installed in Apache, then Apache will forward *every* request
to mod_jk. It is mod_jk which then examines the URL, and decides if it wants to handle
this request or not.
If not, it returns a code to Apache saying "I decline the request", and then Apache looks
for another response handler to handle this.(*)
If mod_jk decides to handle the request (because it matches one of the URLs that it has
been asked to handle, via the JkMount directives), /then/ it forwards it to Tomcat, waits
for the Tomcat response, and returns this response to Apache (which returns it to the
browser).
(*) Apache does the same for any other "handlers" that have been installed. Each of them
is called in turn with the same URL. The first one who decides to handle the request wins.
If no handlers decide to process this request (and all return "declined"), then eventually
Apache will process the request with its own default handler. That one finds the
requested file on disk somwhere under the Apache DocumentRoot, and returns it to the
browser with a Content-type that is what the default Apache handler thinks it is.
(in this case, plain text).
So what I suspect, is that when you look at the mod_jk log, you see lines that show that
indeed mod_jk received the request URL from Apache, and is trying to match it to one of
its internally mapped URLs.
But you may be missing the line that says, in the end, that mod_jk could not match the
URL, and is returning a response "declined" to Apache.
> My mod_jk.conf:
>
> # Load mod_jk module
> # LoadModule jk_module libexec/mod_jk.so
>
> # Declare the module for <IfModule directive> (remove this line on Apache 2.0.x)
> # AddModule mod_jk.c
>
> # Where to find workers.properties
> # JkWorkersFile /etc/httpd/conf/workers.properties
>
> # Where to put jk shared memory
> JkShmFile /var/log/apache2/mod_jk.shm
>
> # Where to put jk logs
> JkLogFile /var/log/apache2/mod_jk.log
>
> # Set the jk log level [debug/error/info]
> JkLogLevel debug
>
> # Select the timestamp log format
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
>
> JkRequestLogFormat "%r %s %w %V"
>
> JKWorkerProperty worker.appl01.type=ajp13
> JKWorkerProperty worker.appl01.host=localhost
> JKWorkerProperty worker.appl01.port=8009
> JKWorkerProperty worker.list=appl01
>
> # Send servlet for context /mouseidgenes to worker named appl01
> JkMount /mouseidgenes/* appl01
This will forward a request like "/mouseidgenes/index.jsp", but will not
forward the URL "/mouseidgenes". You may want to add
JkMount /mouseidgenes appl01
>
> # Send JSPs for context /examples to worker named worker1
> # JkMount /examples/*.jsp worker1
>
>
> Bernd
>
> Helmholtz Zentrum München
> Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
> Ingolstädter Landstr. 1
> 85764 Neuherberg
> www.helmholtz-muenchen.de
> Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
> Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
> Registergericht: Amtsgericht München HRB 6466
> USt-IdNr: DE 129521671
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
Charles Caldarale wrote:
>
> > when talking with a web browser directly to tomcat (port 8080), the
> > web page is shown correctly.
>
> Are you sure the original request on port 80 is actually
> making it through httpd all the way to Tomcat? The symptoms
> you're reporting are characteristic of a misconfigured httpd
> not forwarding anything to Tomcat. Post your mod_jk config
> for someone (probably not me) to look at.
>
Currently i'm logging the whole AJP-stuff between httpd and tomcat (that's a lot). This shows that httpd forwards the request to tomcat, and tomcat delivers the response.
My mod_jk.conf:
# Load mod_jk module
# LoadModule jk_module libexec/mod_jk.so
# Declare the module for <IfModule directive> (remove this line on Apache 2.0.x)
# AddModule mod_jk.c
# Where to find workers.properties
# JkWorkersFile /etc/httpd/conf/workers.properties
# Where to put jk shared memory
JkShmFile /var/log/apache2/mod_jk.shm
# Where to put jk logs
JkLogFile /var/log/apache2/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel debug
# Select the timestamp log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkRequestLogFormat "%r %s %w %V"
JKWorkerProperty worker.appl01.type=ajp13
JKWorkerProperty worker.appl01.host=localhost
JKWorkerProperty worker.appl01.port=8009
JKWorkerProperty worker.list=appl01
# Send servlet for context /mouseidgenes to worker named appl01
JkMount /mouseidgenes/* appl01
# Send JSPs for context /examples to worker named worker1
# JkMount /examples/*.jsp worker1
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671
RE: specifying the content-type
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Lentes, Bernd [mailto:bernd.lentes@helmholtz-muenchen.de]
> Subject: RE: specifying the content-type
> when talking with a web browser directly to tomcat (port 8080),
> the web page is shown correctly.
Are you sure the original request on port 80 is actually making it through httpd all the way to Tomcat? The symptoms you're reporting are characteristic of a misconfigured httpd not forwarding anything to Tomcat. Post your mod_jk config for someone (probably not me) to look at.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
RE: specifying the content-type
Posted by "Lentes, Bernd" <be...@helmholtz-muenchen.de>.
>
> Hi,
>
> first, i'm new to tomcat and i'm not a java developer.
> My collegues developed a web application i have to deploy
> now. I'm using tomcat6 on a sles 11 sp1 box.
> I configured a httpd (apache 2.2.10) in front of the tomcat,
> which communicates with tomcat using AJP.
> When i open one link, i don't see the desired web page, but
> the source code of it. Using tcpdump shows me that the
> content type in the http-header is text/plain. Ok, that's the
> reason why i see the source code. Can i configure the
> content-type which is delivered by tomcat ? I tried using
> mod_mime_magic on httpd, but this module just helps
> specifying the content-type of static files. Our content is dynamic.
>
> Thanks in advance.
>
>
> Bernd
>
appendix:
when talking with a web browser directly to tomcat (port 8080), the web page is shown correctly.
Tomcat itself delivers in the http-header no content-type.
Bernd
Helmholtz Zentrum München
Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH)
Ingolstädter Landstr. 1
85764 Neuherberg
www.helmholtz-muenchen.de
Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe
Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum
Registergericht: Amtsgericht München HRB 6466
USt-IdNr: DE 129521671