Re: access to Manager
On Sat, May 28, 2011 at 00:27, abdelghni belfkih wrote: > hi guys, > > I can't access to the manager/html cuz i don't know how create a user login. > > Plz help me. > [c'est dans la doc de base] This is in the base documentation of Tomcat. And anyway, I strongly recommend AGAINST the HTML version of it. Why? It requires a Web browser for input. Try the text version instead. Everything is documented. -- Francis Galiegue ONE2TEAM Ingénieur système Mob : +33 (0) 683 877 875 Tel : +33 (0) 178 945 552 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
access to Manager
hi guys, I can't access to the manager/html cuz i don't know how create a user login. Plz help me. -- Élève Ingénieur en TIC Option : *Informatique, Réseaux et Systèmes* Institut National des Postes et Télécommunication Mobile : +212672673731 E-mail : blfkih.i...@gmail.com
Re: Piping tomcat logs to rsyslog
> From: Eric Lorson > To: users@tomcat.apache.org > Cc: > Sent: Friday, May 27, 2011 9:21 AM > Subject: Piping tomcat logs to rsyslog > > > For internal security reasons I need to prevent our tomcat logs from writing > to the webserver local disk. We set up a rsyslog server and want to pipe the > log data directly to rsyslog. > > I am trying to work out how to configure tomcat to send all lpg data to > STDOUT or named pipe and have the rsyslog agent send the data to rsyslog on > a separate server. > > We are on CentOS 5.6, Tomcat 6 and rsyslog 5.8.1. > > I need to know: > 1) do we use the default logging library or log4j > 2) where is this configured in the tomcat config > > Thanks, > Eric >From a Google search: juli logging syslog http://remcojansen.posterous.com/2009/11/how-to-send-tomcats-access-log-to.html Note, I have not tried this. . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Piping tomcat logs to rsyslog
For internal security reasons I need to prevent our tomcat logs from writing to the webserver local disk. We set up a rsyslog server and want to pipe the log data directly to rsyslog. I am trying to work out how to configure tomcat to send all lpg data to STDOUT or named pipe and have the rsyslog agent send the data to rsyslog on a separate server. We are on CentOS 5.6, Tomcat 6 and rsyslog 5.8.1. I need to know: 1) do we use the default logging library or log4j 2) where is this configured in the tomcat config Thanks, Eric -- View this message in context: http://old.nabble.com/Piping-tomcat-logs-to-rsyslog-tp31717657p31717657.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problerm accessing request headers from tomcat
Hi.
I believe that you are making the often-made confusion between "environment values" (or
variables), and HTTP headers content.
In particular, here :
Apache1 inserts the following variables into the requests it forwards to
Apache1 (I suppose you meant Apache2 here)
No. It does not do that. It adds some HTTP headers. This is different, see
below.
. Apache1 (I suppose you meant Apache2 here) can see them, I have checked that using
cgi-bin/printenv (some
values anonymized):
HTTP_X_FORWARDED_FOR="aa.bb.cc.dd"
HTTP_X_FORWARDED_HOST="xxx.yyy.net"
HTTP_X_FORWARDED_PORT="443"
HTTP_X_FORWARDED_PROTOCOL="https"
HTTP_X_FORWARDED_SERVER="aaa.bbb.ccc"
Your check does not show that at all. It shows something that is just confusing enough to
get you confused as to what you are seeing. ;-)
But you have excuses for your confusion, because the Apache documentation itself is very
confusing as to "environment variables".
What the cgi-bin script sees, are indeed "environment values".
These are set by the Apache process (Apache2), just before it executes the cgi-bin script.
So the cgi-bin script sees them in its environment when it runs.
(like with $ENV{'HTTP_X_FORWARDED_PORT'})
But there is no one-to-one relationship between what Apache finds in HTTP request headers,
and the environment values which it sets for the cgi-bin scripts that it runs.
Apache does "convert" some of the request HTTP header values into cgi-bin environment
variables, but :
- the name of the environment variable may be different from the corresponding HTTP header
label (you see this yourself above : a HTTP header named "X-forwarded-for:" has been
passed to the cgi-bin script as the environment value named "HTTP_X_FORWARDED_FOR")
- not all HTTP headers are converted and passed that way
- some environment values passed to the cgi-bin script are not, and never were, HTTP
headers of the request (for example, the cgi-bin environment values "QUERY_STRING", or
"SCRIPT_FILENAME")
On the other hand :
When a HTTP proxy server forwards a HTTP request to another HTTP server via the HTTP
protocol, it forwards *all* the request headers and request content to this other server,
as a HTTP request (otherwise, it would not be a valid HTTP proxy server). But it cannot
forward "environment values", because there is no defined way of doing this over the HTTP
protocol. (*)
But now I see your second post, and your problem is in fact much simpler.
By doing this :
h:outputText style="font: bold 14px sans-serif;"
> value="X_FORWARDED_HOST: #{header['X_FORWARDED_HOST']}" />
what you are actually trying to retrieve, is the content of the HTTP request
header
"X_FORWARDED_HOST:" (I guess), but this HTTP header does not exist in the
request.
What you are giving as a HTTP header name, is actually what the cgi-bin environment value
name was for your cgi-bin.
Which, as I try to explain at long length above, is not the same thing.
So you get back a null, and you think that the header was not there.
But it is there, only under its real HTTP header name.
Try something like
value="X_FORWARDED_HOST: #{header['X-Forwarded-for']}" />"
instead.
(Noise of self-slap on face ?).
(*) However, when the proxy protocol used is AJP (as it is between Apache and Tomcat when
using the mod_jk connector, or the mod_proxy_ajp connector), /then/ some additional values
/can/ be passed along with the request (because the AJP protocol allows that). On the
Tomcat side, these then appear as "request attributes" which the webapp can retrieve (via
request.getAttribute(name)), but not as "environment values" of the Tomcat process for
example.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problerm accessing request headers from tomcat
Hi Martin,
the reverse proxy (gateway) in my case would be "apache1" me thinks. "apache2"
definitely does not use mod_proxy/ProxyPass. It is just loadbalancing two
tomcat
instances using "mod_jk".
My problem is (maybe I was not clear) that "apache2" does see the
X-Forwarded-For, X-Forwarded-Host and X-Forwarded-Server headers apparently
added by "apache1", but that those are not visible in the requests reaching
tomcat. If, just as an experiment, I use "RequestHeader set" in the "apache2"
ssl configuration, tomcat sees them. Same is true for the "_PORT" and
"_PROTOCOL" headers that are added on "apache1" via "RequestHeader set".
Did I express myself better this time? There must be some handling differences
between headers added from mod_proxy (if that is used by apache1 I will not
find
out before some time next week) and those added by mod_headers.
Thanks
Martin :-)
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
- Original Message
> From: Martin Gainty
> To: Tomcat Users List
> Sent: Fri, May 27, 2011 3:29:32 PM
> Subject: RE: Weird problerm accessing request headers from tomcat
>
>
> when your Apache2 is configured as reverse-proxy you are fowarding
>IP,RequestedHost and Proxy-Server specifically:
>
> When acting in a reverse-proxy mode (using the ProxyPass directive, for
>example),
> mod_proxy_http adds several request headers in
> order to pass information to the origin server. These headers
> are:
>
> X-Forwarded-ForThe IP address of the client.X-Forwarded-HostThe original
>host requested by the client in the Host
>
>HTTP request header.X-Forwarded-ServerThe hostname of the proxy
server.
>
> http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
>
> is this not the case?
> Martin
> __
>
>
>
>
>
>
> > Date: Fri, 27 May 2011 05:53:14 -0700
> > From: spamt...@knobisoft.de
> > Subject: Weird problerm accessing request headers from tomcat
> > To: users@tomcat.apache.org; us...@httpd.apache.org
> >
> > Hi,
> >
> > sorry for the crosspost, but I am not sure where to ask. I am trying to
> > understand a weird problem accessing HTTP request headers from a jsf page.
> >
> > The setup is as follows:
> >
> > apache1 -> apache2 -> mod_jk -> tomcat
> >
> > Apache1 is accessible from the Internet and forwards requests to my
>application
>
> > to apache2. I have no direct control over the setup of apache1 and I
> > cannot
>look
>
> > at the configuration. Apache2 (2.0.63 on Linux) is answering requests from
>the
>
> > intranet and forwards them via mod_jk (1.2.30) to two loadbanced tomcats
>(Linux,
>
> > 6.0.32).
> >
> > Apache1 inserts the following variables into the requests it forwards to
> > Apache1. Apache1 can see them, I have checked that using cgi-bin/printenv
>(some
>
> > values anonymized):
> >
> > HTTP_X_FORWARDED_FOR="aa.bb.cc.dd"
> > HTTP_X_FORWARDED_HOST="xxx.yyy.net"
> > HTTP_X_FORWARDED_PORT="443"
> > HTTP_X_FORWARDED_PROTOCOL="https"
> > HTTP_X_FORWARDED_SERVER="aaa.bbb.ccc"
> >
> > If I try to read those variables from the tomcat application using this
> > facelett code:
> >
> > > value="X_FORWARDED_HOST: #{header['X_FORWARDED_HOST']}" />
> >
> > > value="X_FORWARDED_PROTOCOL:
>#{header['X_FORWARDED_PROTOCOL']}"
>
> > />
> >
> > > value="X_FORWARDED_PORT: #{header['X_FORWARDED_PORT']}" />
> >
> > > value="X_FORWARDED_FOR: #{header['X_FORWARDED_FOR']}" />
> >
> > > value="X_FORWARDED_SERVER:
> > #{header['X_FORWARDED_SERVER']}"
>/>
> >
> >
> >
> > Only X_FORWARDED_PORT and X_FORWARDED_PROTOCOL are set. The other three
> > are
> > empty/null. It seem that somewhere they get dropped between Apache2,
> > mod_jk
>and
>
> > Tomcat.
> >
> > Now, I know that _PORT and _PROTOCOL are inserted at Apache1 using
> > 'RequestHeader set X_FORWARDED_PROTOCOL "https"', while I do not know how
>the
>
> > other three are generated. If I add 'RequestHeader set X_FORWARDED_HOST
> > "xxx.yyy.net"' to the configuration from apache2, the application sees
> > that
> > header as well. Confused? so am I :-(
> >
> > Happy weekend
> >
> > Martin
> > --
> > Martin Knoblauch
> > email: k n o b i AT knobisoft DOT de
> > www: http://www.knobisoft.de
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
-
To unsubscribe, e-mail: users-unsubscr...@to
RE: Weird problerm accessing request headers from tomcat
when your Apache2 is configured as reverse-proxy you are fowarding
IP,RequestedHost and Proxy-Server specifically:
When acting in a reverse-proxy mode (using the ProxyPass directive, for
example),
mod_proxy_http adds several request headers in
order to pass information to the origin server. These headers
are:
X-Forwarded-ForThe IP address of the client.X-Forwarded-HostThe original
host requested by the client in the Host
HTTP request header.X-Forwarded-ServerThe hostname of the proxy server.
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
is this not the case?
Martin
__
> Date: Fri, 27 May 2011 05:53:14 -0700
> From: spamt...@knobisoft.de
> Subject: Weird problerm accessing request headers from tomcat
> To: users@tomcat.apache.org; us...@httpd.apache.org
>
> Hi,
>
> sorry for the crosspost, but I am not sure where to ask. I am trying to
> understand a weird problem accessing HTTP request headers from a jsf page.
>
> The setup is as follows:
>
> apache1 -> apache2 -> mod_jk -> tomcat
>
> Apache1 is accessible from the Internet and forwards requests to my
> application
> to apache2. I have no direct control over the setup of apache1 and I cannot
> look
> at the configuration. Apache2 (2.0.63 on Linux) is answering requests from
> the
> intranet and forwards them via mod_jk (1.2.30) to two loadbanced tomcats
> (Linux,
> 6.0.32).
>
> Apache1 inserts the following variables into the requests it forwards to
> Apache1. Apache1 can see them, I have checked that using cgi-bin/printenv
> (some
> values anonymized):
>
> HTTP_X_FORWARDED_FOR="aa.bb.cc.dd"
> HTTP_X_FORWARDED_HOST="xxx.yyy.net"
> HTTP_X_FORWARDED_PORT="443"
> HTTP_X_FORWARDED_PROTOCOL="https"
> HTTP_X_FORWARDED_SERVER="aaa.bbb.ccc"
>
> If I try to read those variables from the tomcat application using this
> facelett code:
>
> value="X_FORWARDED_HOST: #{header['X_FORWARDED_HOST']}" />
>
> value="X_FORWARDED_PROTOCOL:
> #{header['X_FORWARDED_PROTOCOL']}"
> />
>
> value="X_FORWARDED_PORT: #{header['X_FORWARDED_PORT']}" />
>
> value="X_FORWARDED_FOR: #{header['X_FORWARDED_FOR']}" />
>
> value="X_FORWARDED_SERVER: #{header['X_FORWARDED_SERVER']}" />
>
>
>
> Only X_FORWARDED_PORT and X_FORWARDED_PROTOCOL are set. The other three are
> empty/null. It seem that somewhere they get dropped between Apache2, mod_jk
> and
> Tomcat.
>
> Now, I know that _PORT and _PROTOCOL are inserted at Apache1 using
> 'RequestHeader set X_FORWARDED_PROTOCOL "https"', while I do not know how the
> other three are generated. If I add 'RequestHeader set X_FORWARDED_HOST
> "xxx.yyy.net"' to the configuration from apache2, the application sees that
> header as well. Confused? so am I :-(
>
> Happy weekend
>
> Martin
> --
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www: http://www.knobisoft.de
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
Re: Tomcat 5.5.27, session lost, cookies
Il 27/05/2011 15.04, Filippo Machi ha scritto: > @Filippo: Ciao! There are no "strange" or blank character on cookie > value, it's just the JSESSIONID "as is". It's a value generated by > Tomcat, isn't it? > > Ciao Diego, > I meant, maybe there's ANOTHER cookie in the incoming request that contains > one or > more not valid characters and it causes tomcat to fail the parsing of all > other cookies, > included the JSESSIONID one. > ciao > Fil Mmm... no. There are just 2 cookies: JSESSIONID and I18n cookie : the latter contains just values like "IT_it" . Sometimes ALSO a dup JSESSIONID is set, or a "jsessionid" (in lower case) : that's part of our webapp, maybe I should fix it... :-) Thanks, ciao -- Ing. Diego Ruotolo Software developer
Re: Tomcat 5.5.27, session lost, cookies
On Fri, May 27, 2011 at 12:26 PM, Diego Ruotolo wrote: > Hi everybody ! > > Thanks to all of you for your replies. Unfortunately (or fortunately) I > spent the whole morning trying to reproduce the problem but everything > works fine today! > > @Filippo: Ciao! There are no "strange" or blank character on cookie > value, it's just the JSESSIONID "as is". It's a value generated by > Tomcat, isn't it? > Ciao Diego, I meant, maybe there's ANOTHER cookie in the incoming request that contains one or more not valid characters and it causes tomcat to fail the parsing of all other cookies, included the JSESSIONID one. ciao Fil
Weird problerm accessing request headers from tomcat
Hi, sorry for the crosspost, but I am not sure where to ask. I am trying to understand a weird problem accessing HTTP request headers from a jsf page. The setup is as follows: apache1 -> apache2 -> mod_jk -> tomcat Apache1 is accessible from the Internet and forwards requests to my application to apache2. I have no direct control over the setup of apache1 and I cannot look at the configuration. Apache2 (2.0.63 on Linux) is answering requests from the intranet and forwards them via mod_jk (1.2.30) to two loadbanced tomcats (Linux, 6.0.32). Apache1 inserts the following variables into the requests it forwards to Apache1. Apache1 can see them, I have checked that using cgi-bin/printenv (some values anonymized): HTTP_X_FORWARDED_FOR="aa.bb.cc.dd" HTTP_X_FORWARDED_HOST="xxx.yyy.net" HTTP_X_FORWARDED_PORT="443" HTTP_X_FORWARDED_PROTOCOL="https" HTTP_X_FORWARDED_SERVER="aaa.bbb.ccc" If I try to read those variables from the tomcat application using this facelett code: Only X_FORWARDED_PORT and X_FORWARDED_PROTOCOL are set. The other three are empty/null. It seem that somewhere they get dropped between Apache2, mod_jk and Tomcat. Now, I know that _PORT and _PROTOCOL are inserted at Apache1 using 'RequestHeader set X_FORWARDED_PROTOCOL "https"', while I do not know how the other three are generated. If I add 'RequestHeader set X_FORWARDED_HOST "xxx.yyy.net"' to the configuration from apache2, the application sees that header as well. Confused? so am I :-( Happy weekend Martin -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Log4j.properties settings in documentation
All, I think that I have found a problem in the documentation for setting up log4j.properties at http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j. The same text is on the tomcat 6.0 documentation. It specifies log4j.appender.CATALINA.conversionPattern = %d [%t] %-5p %c- %m%n When I run that I receive the following exception log4j:ERROR Could not find value for key log4j.appender.CATALINA.layout log4j:WARN No such property [conversionPattern] in org.apache.log4j.DailyRollingFileAppender. log4j:ERROR No layout set for the appender named [CATALINA]. It works fine if I update the setting to log4j.appender.CATALINA.layout.conversionPattern = %d [%t] %-5p %c- %m%n log4j.appender.CATALINA.layout=org.apache.log4j.PatternLayout The same issue is present for catalina, localhost, manager, host-manager and console appenders. Is this something that I am doing wrong, or is the documentation wrong? Chris P.S. assuming that the documentation is wrong, does everybody stick with juli logging? I mean if this has been wrong since v6, nobody can be using it right? I guess juli logging provides everything most people need?
Re: Tomcat 5.5.27, session lost, cookies
Hi everybody !
Thanks to all of you for your replies. Unfortunately (or fortunately) I
spent the whole morning trying to reproduce the problem but everything
works fine today!
@Filippo: Ciao! There are no "strange" or blank character on cookie
value, it's just the JSESSIONID "as is". It's a value generated by
Tomcat, isn't it?
@Marcos: I have no logs... I tried to log this morning using log4j at
DEBUG level, but, as I said in the beginning, everything works fine today...
@Christopher: here's the access logs, with all the HTTP calls
(everything's fine, these are NOT the logs of the fail scenario):
127.0.0.1 - - [27/May/2011:11:29:41 +0200] "POST
/servlet/it.dianoema.dnweb.library.servlets.Automation HTTP/1.1" 200 2070
127.0.0.1 - - [27/May/2011:11:29:41 +0200] "POST
/servlet/it.dianoema.dnweb.library.servlets.ConsoleServlet HTTP/1.1" 200
1698
127.0.0.1 - - [27/May/2011:11:29:41 +0200] "GET
/servlet/it.dianoema.dnweb.dnlis.servlets.StampaEtichette?azione=PRINT&stampante_autom=false&printer=Etichette
HTTP/1.1" 200 6066
127.0.0.1 - - [27/May/2011:11:29:45 +0200] "POST
/servlet/it.dianoema.dnweb.dnlis.servlets.AzioniSuRichieste HTTP/1.1" 200 7
127.0.0.1 - - [27/May/2011:11:30:12 +0200] "POST
/servlet/it.dianoema.dnweb.dnlis.servlets.GetSkel HTTP/1.1" 200 7
127.0.0.1 - - [27/May/2011:11:30:12 +0200] "GET
/servlet/it.dianoema.dnweb.dnlis.servlets.StampaEtichette?azione=VOID
HTTP/1.1" 200 582
127.0.0.1 - - [27/May/2011:11:30:12 +0200] "GET
/servlet/it.dianoema.dnweb.dnlis.servlets.GetFiltro?TEMPLATE=templates/gsp/head.template
HTTP/1.1" 200 5489
127.0.0.1 - - [27/May/2011:11:30:12 +0200] "GET
/servlet/it.dianoema.dnweb.dngsp.ShowQuery?TEMPLATE=templates%2Fgsp%2Flist.template&ELENCO=Pazienti&SESSION_REM=ALL&QUERY=PazientiGSP&FIELD_Reparto=noe_dnweb&FIELD_ExtCodice=&FIELD_Codice=&FIELD_CodiceRicovero=&FIELD_Cognome=&FIELD_Nome=&FIELD_00_DataUltimaRichiesta=&FIELD_01_DataUltimaRichiesta=&COND_Cognome=+LIKE+&COND_Nome=+LIKE+&COND_00_DataUltimaRichiesta=SHORT_DATE%3E%3D&COND_01_DataUltimaRichiesta=SHORT_DATE%3C%3D&SORTS=&AGG_REP=yes&REP_IN=yes
HTTP/1.1" 200 4
127.0.0.1 - - [27/May/2011:11:30:12 +0200] "GET
/servlet/it.dianoema.dnweb.dnlis.servlets.GetSkel?SKEL=/dnlis/templates/gsp/tail.template&GSP=ON&AMB=OFF
HTTP/1.1" 200 2280
127.0.0.1 - - [27/May/2011:11:30:12 +0200] "GET
/servlet/it.dianoema.dnweb.dnlis.servlets.Context HTTP/1.1" 200 2565
I'll explain you our flow:
we call the servlet Automation that starts a thread who sequentially
calls all the other servlets, when the thread has finished the control
is returned to Automation servlet.
Not all servlet are called by thread: lots of them are invoked because
the previous servlet returned an HTML page containing frames that have a
servlet URL in the src attribute. Let's make an example:
Automation --> Thread started --> Call servlet 1 --> HTML is returned
--> Call servlet 2 (it's in the HTML page) --> Thread end --> Automation
Usually the problem occours when invoking servlet from the HTML page
(servlet 2 in the example above, servlet called GetFiltro in the access
logs).
Things I've tried to do:
- increase size of connector input stream buffer, from 2048 to 4096,
using bufferSize attribute
- force the "Set-Cookie" attribute in every response, forcing the
JSESSIONID cookie
If you want I have the entire HTTP headers of request/response.
I'll try again to reproduce the problem, I will send you more details
when it will occour again.
Thanks everybody!
Best regards
Il 27/05/2011 10.33, Filippo Machi ha scritto:
> Ciao!
> Please read my comment inline..
>
> On Fri, May 27, 2011 at 12:12 AM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Filippo,
>
> On 5/26/2011 10:50 AM, Filippo Machi wrote:
> >>> One of our legacy (non java) server was used to put a blank (' ')
> character
> >>> as value of a cookie.
>
> The value itself is blank, or the value /contains/ a blank?
>
>
> > the value contains a blank
>
>
>
> Please give us an example of a "Cooke:" header from your client and
> maybe we can suggest a solution (a few come to mind, but I'm unwilling
> to describe them until I see an example).
>
>
> > here it's an example, I used firebug to grab the cookie header
> contained in
> > the request:
>
> >
> AA=01*49qmsEhufMY7I6g/OnGT2tN3ThrCZH6vJ342kTDsssuRgEhlqwftbRTaikwi9I3HIx5yoK1ng4tY
> > 5JuIUe3x9o0Jptimu3uvVgeQAKc5htM=;
> > __utma=125866390.1346069185.1295258223.1306326749.1306484681.40;
> > __utmz=125866390.1306326795.39.29.utmcsr=
>
>
> > as you can see there are different cookies, the first one (AA) it's the
> > guilty. It has a blank here
>
> > ...4tY 5Ju...
>
> > thanks
> > Fil
>
>
>
> -chris
>>
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
--
Diego Ruotolo - NoemaLife S.p.A.
Ing. Diego Ruotolo
Software developer
NoemaLife S.p.A.
Via Gobetti, 52
40129 Bologna - ITALY
T +39 051
Re: JkExtractSSL not sending SSL information to tomcat
On 25.05.2011 15:18, Christopher Schultz wrote: > André, > > On 5/24/2011 7:13 PM, André Warnier wrote: >> Christopher Schultz wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Marc, >>> >>> On 5/24/2011 10:56 AM, Marc Boorshtein wrote: I've setup a pretty generic httpd(2.2.19)+mod_jk to tomcat 6 on Oracle Linux 5 (CentOS 5 equiv) with SSL setup. With JkExtractSSL and the correct SSLOptions in the httpd configuration files. I can see the SSL environment variables in /cgi-bin/printenv but no headers or environment variables in the backend tomcat app. Am I missing something? >>> >>> Something just tickled my brain, here: you said "environment variables >>> or headers". The data stored in environment variables on the Apache >>> httpd side are neither stored in environment variables (since the >>> environment is shared, and a multi-threaded server would never work) nor >>> in request headers (because that's not really appropriate). >>> >>> Instead, they are stored in the request /attributes/. >>> >>> Unfortunately, the mod_jk documentation doesn't make that clear. I'll >>> try to find a reference, even if it's only in the source code. >>> >> Checkup JkEnvVar. >> http://grokbase.com/topic/2007/04/19/howto-forward-user-name-from-apache-via-mod-jk-to-tomcat/00UYI-2ef5d4aI6oZhrQPFf3JD0 > > Yeah, except that JkEnvVar puts the environment variable FOO into the > request attribute "FOO", while JkExtractSSL puts them under attribute > keys defined by the servlet specification. That was not clear at all > from the existing documentation (at least not without having read the > servlet spec as well and drawing a logical conclusion). Being late here, I used to suggest taking a look at http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
Filippo Machi wrote: On Fri, May 27, 2011 at 11:20 AM, André Warnier wrote: Filippo Machi wrote: we're using tomcat 7.0.12 Ok. 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : 85.214.x.x (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to "127.0.0.1:8080" - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). there are other clients (browsers) accessing serverA using the server name (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : something like 93.35.x.x And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) One more question : this IP-filter Valve, is that something written in-house ? Yes, we coded the filter. I do not see anything particularly wrong in the server.xml which you sent. But it does confirm that you have a single in Tomcat. One additional question : The crontab PHP script sends a request to Tomcat from time to time. Is that request directed to a specific application that only the PHP script is using, or is that same application also used by other clients ? Yes, we have only one web application used by all our clients, included the php script. Mmm. That's a bit more complicated for what I had in mind. Would it be a problem to have 2 separate instances of that application (one for the PHP script, one for the other clients) ? I have little time now, but what I have in mind would be roughly as follows : - you add a second in your server.xml file, with a hostname of e.g. "internal.company.com" - for that second Host, you create a separate "webapps" directory, e.g. (tomcat_dir)/webapps2 - in that directory, you copy your application, e.g. as (tomcat_dir)/webapps2/yourapp/* (the same application name, and exactly all the same files, no changes) - in the local "hosts" file of your machine, you add the line 127.0.0.1 internal.company.com - you change your PHP script to access "http://internal.company.com:8080"; instead of "http://127.0.0.1:8080"; The rest later, I have to go now.. but think about it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issues with getRemoteAddress
On Fri, May 27, 2011 at 11:20 AM, André Warnier wrote: > Filippo Machi wrote: > >> >> we're using tomcat 7.0.12 >> >> Ok. > > >> 1) You have serverA running Tomcat, and Tomcat listens on port 8080. >>> The (network) IP address of serverA is : >>> >> 85.214.x.x >> >> (apart from the loopback address 127.0.0.1) >> >>> This Tomcat has some IP-based access Valve which : >>> >>> >> we have a filter, not a valve, (a class implementing >> javax.servlet.Filter) >> that authenticates incoming request >> according to: >> - a particular key contained as parameter in the request >> - the ip of the incoming request >> - a cookie >> those checks are applied in the exact order I listed them, if all of them >> fails, then the user >> is redirected to the login page as follows >> >> request.getServletContext() >> .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) >> .forward(request, response); >> >> I don't know whether it matters but we have a chain of filters and the >> authorization one I described is applied >> after a filter that, in some cases perform a forward >> >> >> request.getServletContext().getRequestDispatcher(remappedResource).forward(request, >> response); >> >> but I think it shouldn't be the cause of the issue... >> >> >> - for requests from 127.0.0.1, allows them through without authentication >> >>> - for requests /not/ from 127.0.0.1, requires authentication in the form >>> of >>> a cookie, and if that cookie is not present, returns a login page. >>> >>> The requester IP address is obtained by the Valve using the >>> getRemoteAddress() method. >>> >>> 2) On the same serverA, there is a cron job which runs from time to time. >>> This cron job runs a PHP script, which >>> - connects to "127.0.0.1:8080" >>> - sends a HTTP request over that connection, directed to a specific >>> Tomcat >>> application >>> - receives a response from Tomcat >>> >>> 3) there are also other clients (not on serverA), which access other >>> applications (or the same application) on serverA/Tomcat directly, by >>> addressing their requests to ? >>> (IP or name). >>> >>> >> there are other clients (browsers) accessing serverA using the server name >> >> >> (it cannot be 127.0.0.1:8080, since these clients are not on serverA) >>> >>> The IP's of those clients are : >>> >> something like 93.35.x.x >> >> >>> And what you are seeing in the logs, is that from time to time, a request >>> which seems to come from the PHP script (and should thus have a client IP >>> address of 127.0.0.1 and go through without authentication), instead >>> seems >>> to come from another IP (and thus is caught by the Valve and returns a >>> login >>> page). >>> And you also see this in the log of the PHP script : it shows that it >>> receives a login page, instead of the expected response. (*) >>> >>> >> Yes, that's exactely what we're experiencing (the only detail that differs >> it's that authentication is performed by a filter, not a valve) >> >> >> One more question : this IP-filter Valve, is that something written >>> in-house ? >>> >>> >> Yes, we coded the filter. >> >> >> I do not see anything particularly wrong in the server.xml which you > sent. > But it does confirm that you have a single in Tomcat. > > One additional question : > The crontab PHP script sends a request to Tomcat from time to time. > Is that request directed to a specific application that only the PHP script > is using, or is that same application also used by other clients ? > > > Yes, we have only one web application used by all our clients, included the php script. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Issues with getRemoteAddress
Filippo Machi wrote: we're using tomcat 7.0.12 Ok. 1) You have serverA running Tomcat, and Tomcat listens on port 8080. The (network) IP address of serverA is : 85.214.x.x (apart from the loopback address 127.0.0.1) This Tomcat has some IP-based access Valve which : we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication - for requests /not/ from 127.0.0.1, requires authentication in the form of a cookie, and if that cookie is not present, returns a login page. The requester IP address is obtained by the Valve using the getRemoteAddress() method. 2) On the same serverA, there is a cron job which runs from time to time. This cron job runs a PHP script, which - connects to "127.0.0.1:8080" - sends a HTTP request over that connection, directed to a specific Tomcat application - receives a response from Tomcat 3) there are also other clients (not on serverA), which access other applications (or the same application) on serverA/Tomcat directly, by addressing their requests to ? (IP or name). there are other clients (browsers) accessing serverA using the server name (it cannot be 127.0.0.1:8080, since these clients are not on serverA) The IP's of those clients are : something like 93.35.x.x And what you are seeing in the logs, is that from time to time, a request which seems to come from the PHP script (and should thus have a client IP address of 127.0.0.1 and go through without authentication), instead seems to come from another IP (and thus is caught by the Valve and returns a login page). And you also see this in the log of the PHP script : it shows that it receives a login page, instead of the expected response. (*) Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) One more question : this IP-filter Valve, is that something written in-house ? Yes, we coded the filter. I do not see anything particularly wrong in the server.xml which you sent. But it does confirm that you have a single in Tomcat. One additional question : The crontab PHP script sends a request to Tomcat from time to time. Is that request directed to a specific application that only the PHP script is using, or is that same application also used by other clients ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
"Missing" requests on server - IIS -> ISAPI redirect -> Tomcat 6
Hi, we have a problem that some requests are missing on our application. As far we can see, the requests are arrived at IIS but not at Tomcat. Also we do not know if the request are processed by IIS but there were never problems with our ASP.Net application which runs directly on IIS. I also added the AccessLogValve but AFAICS the request is already lost and not added to logs. For example: The users clicks on a link and the request is sent but it's not arrived at our application. No error logs, no entry in the AccessLog, no entry in the windows event logs and no entry in our application! The request is never arrived at our application and the request seems to be lost... The browser will automatically retry after 120 seconds and the request/response is finished after few seconds or milliseconds. Our environment: Hardware Firewall and Loadbalancer (This should not be a problem because the request arrives at IIS) Windows 2003 32bit with IIS 6 ISAPI redirector 1.2.26.0 Tomcat 6.0.16 Anyone ever had a similiar problem? Thanks! Best regards, Thomas
Re: Tomcat 5.5.27, session lost, cookies
Ciao!
Please read my comment inline..
On Fri, May 27, 2011 at 12:12 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Filippo,
>
> On 5/26/2011 10:50 AM, Filippo Machi wrote:
> > One of our legacy (non java) server was used to put a blank (' ')
> character
> > as value of a cookie.
>
> The value itself is blank, or the value /contains/ a blank?
>
the value contains a blank
>
> Please give us an example of a "Cooke:" header from your client and
> maybe we can suggest a solution (a few come to mind, but I'm unwilling
> to describe them until I see an example).
>
here it's an example, I used firebug to grab the cookie header contained in
the request:
AA=01*49qmsEhufMY7I6g/OnGT2tN3ThrCZH6vJ342kTDsssuRgEhlqwftbRTaikwi9I3HIx5yoK1ng4tY
5JuIUe3x9o0Jptimu3uvVgeQAKc5htM=;
__utma=125866390.1346069185.1295258223.1306326749.1306484681.40;
__utmz=125866390.1306326795.39.29.utmcsr=
as you can see there are different cookies, the first one (AA) it's the
guilty. It has a blank here
...4tY 5Ju...
thanks
Fil
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3e0EcACgkQ9CaO5/Lv0PD6ZgCfZYbQ0mgHBVH7lCiGEiiQ5jwd
> YWsAmwUmoJuGlbNvIRouWyWXLbSPsq6o
> =U5r9
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Issues with getRemoteAddress
Ciao Andrè, thanks for your answer! I really appreciate all the time you spend, thanks again. Please find my inline answers.. On Thu, May 26, 2011 at 7:12 PM, André Warnier wrote: > Hi. > > First, tell us what precise version of Tomcat you are using (x.y.z format). > we're using tomcat 7.0.12 > > Then, one minute I think that I am starting to understand your setup, but > the next minute I am lost again. > Sorry, maybe I wasn't clean enough, but it looks to me that you have quite a clear picture of our setup and issue > > The way I understand it now (please correct whatever needs to be) : > > 1) You have serverA running Tomcat, and Tomcat listens on port 8080. > The (network) IP address of serverA is : > 85.214.x.x (apart from the loopback address 127.0.0.1) > > This Tomcat has some IP-based access Valve which : > we have a filter, not a valve, (a class implementing javax.servlet.Filter) that authenticates incoming request according to: - a particular key contained as parameter in the request - the ip of the incoming request - a cookie those checks are applied in the exact order I listed them, if all of them fails, then the user is redirected to the login page as follows request.getServletContext() .getRequestDispatcher(LOGIN_PAGE_REDIRECT_URL) .forward(request, response); I don't know whether it matters but we have a chain of filters and the authorization one I described is applied after a filter that, in some cases perform a forward request.getServletContext().getRequestDispatcher(remappedResource).forward(request, response); but I think it shouldn't be the cause of the issue... - for requests from 127.0.0.1, allows them through without authentication > - for requests /not/ from 127.0.0.1, requires authentication in the form of > a cookie, and if that cookie is not present, returns a login page. > > The requester IP address is obtained by the Valve using the > getRemoteAddress() method. > > 2) On the same serverA, there is a cron job which runs from time to time. > This cron job runs a PHP script, which > - connects to "127.0.0.1:8080" > - sends a HTTP request over that connection, directed to a specific Tomcat > application > - receives a response from Tomcat > > 3) there are also other clients (not on serverA), which access other > applications (or the same application) on serverA/Tomcat directly, by > addressing their requests to ? > (IP or name). > there are other clients (browsers) accessing serverA using the server name > (it cannot be 127.0.0.1:8080, since these clients are not on serverA) > > The IP's of those clients are : something like 93.35.x.x > (just an idea, to distinguish them from the above) > > And what you are seeing in the logs, is that from time to time, a request > which seems to come from the PHP script (and should thus have a client IP > address of 127.0.0.1 and go through without authentication), instead seems > to come from another IP (and thus is caught by the Valve and returns a login > page). > And you also see this in the log of the PHP script : it shows that it > receives a login page, instead of the expected response. (*) > Yes, that's exactely what we're experiencing (the only detail that differs it's that authentication is performed by a filter, not a valve) > > Or else, what is the problem precisely ? > > One more question : this IP-filter Valve, is that something written > in-house ? > Yes, we coded the filter. > (At some point, we may want to see the content of the conf/server.xml of > your Tomcat also. > Make a copy, remove any sensitive information like exact IP addresses, > passwords etc., and paste it directly into a message here. Do not paste it > as an attachment, this list often strips them). > As requested, but I don't think my colleagues change it too much since we're now setting up our production environment. > > > (*) If this is what happens, it is indeed bizarre, and it should never > happen. > It introduces a strong suspicion that there is something wrong with the > Valve.. > > As a separate comment, not to mix with the above : > In all generality, if your serverA is connected to the Internet, it is not > surprising per se, that your server would receive from time to time a > request, directed to the same URL as the one used by your PHP script, but > coming from an external unknown IP. > That happens all the time, as there are plenty of nefarious bots out there > looking for server weaknesses all the time. > But these external unknown IP clients should then receive the login page in > return. > If your PHP script receives this login page however, then it looks as if > your IP-filter Valve may be mixing up its requests/responses.
Re: Monitoring memory usage of JVM
On Fri, 27 May 2011 09:50:06 +0200, André Warnier wrote: Searching the WWW, I am finding (too) many interpretations of the output of "-verbose:gc" (or "-verbosegc", none of them starting from exactly the format above. I can kind of guess what the above means, but where can I find an "authoritative" interpretation for Sun/Oracle Java 1.6 ? Also, does anyone know if there is a way to specify that instead of the unreadable leading timestamp above, one can get a nicely-formatted one ? (-XX:+PrintGCTimeStamps ?) I use the following options: -Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps We use nice tool from HP (HPJmeter) at work. It parses GC logfile and produces various graphs. I guess you can download it for free from www.hp.com/go/java -- Mikolaj Rydzewski - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Monitoring memory usage of JVM
Pid wrote: On 26/05/2011 21:50, André Warnier wrote: André Warnier wrote: Pid wrote: On 26/05/2011 20:16, Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Monitoring memory usage of JVM I am thinking of a couple of command-line options for the JVM, to dump for example some information each time a GC happens, Try -verbose:gc and -Xloggc: The jmap & jstat commands shipped with the JDK are also useful. Thanks to both. I'll try these out. For now, I have used the "-verbose:gc and -Xloggc:" command-line options, and added the jmap command into one of the other monitoring shell scripts I created. I'll have to wait for the next GC to see the output of the switches. As the application isn't doing anything right now, that could take a while. But a question about "jstat" in the meantime : In the documentation of jstat, it has this to say about the /lvmid/ part : port The default port for communicating with the remote server. If the hostname is omitted or the protocol specifies an optimized, local protocol, then port is ignored. Otherwise, treatment of the port parameter is implementation specific. For the default rmi protocol, the port indicates the port number for the rmiregistry on the remote host. If port is omitted, and protocol indicates rmi, then the default rmiregistry port (1099) is used. Is this the same port which I otherwise set for jconsole, iow via the option : -Dcom.sun.management.jmxremote.port= Yes, AFAIK. There's also a companion utility 'jstatd'. I'll just continue adding here, so that everything stays together. the output of the "-verbose:gc" switch looks as follows : ... 36980.453: [GC 479482K->271910K(994752K), 0.0135340 secs] 37085.411: [GC 511334K->269236K(992320K), 0.0130770 secs] 37750.377: [GC 508660K->276295K(999168K), 0.0124960 secs] 38078.813: [GC 524999K->286052K(997184K), 0.0077580 secs] 38187.341: [GC 534756K->295781K(1004032K), 0.0096650 secs] 38341.838: [GC 553765K->300854K(1001600K), 0.0230050 secs] ... Searching the WWW, I am finding (too) many interpretations of the output of "-verbose:gc" (or "-verbosegc", none of them starting from exactly the format above. I can kind of guess what the above means, but where can I find an "authoritative" interpretation for Sun/Oracle Java 1.6 ? Also, does anyone know if there is a way to specify that instead of the unreadable leading timestamp above, one can get a nicely-formatted one ? (-XX:+PrintGCTimeStamps ?) By the way, I know that there is an over-abudance of articles on the WWW about Java memory tuning, but here is one I found serendipitiously : http://fedora.fiz-karlsruhe.de/docs/Wiki.jsp?page=Java%20Heap%20%26%20GC%20Tuning Even if it appears to have been written mainly for one kind of application, it is short, readable, to-the-point, and I think usable in a broader context. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
