Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Rainer Jung

Am 17.10.2016 um 22:38 schrieb Mark Juszczec:

On Mon, Oct 17, 2016 at 8:20 AM, Rainer Jung 
wrote:


Am 17.10.2016 um 12:35 schrieb Mark Juszczec:


On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas  wrote:



A small hint. I'd expect those to be % encoded.



Thank you very much for your reply.

I've been thinking the problem is lack of % encoding after reading:

*"Default encoding for GET*
The character set for HTTP query strings (that's the technical term for
'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
specification. The character set is defined to be US-ASCII
. Any character that does not map to
US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
specification says that characters outside of US-ASCII must be encoded
using
 % escape sequences: each character is encoded as a literal % followed by
the two hexadecimal codes which indicate its character code. Thus, a
(US-ASCII
character code 97 = 0x61) is equivalent to %61. There *is no default
encoding for URIs* specified anywhere, which is why there is a lot of
confusion when it comes to decoding these values. "

from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8

Do you know if there's a way to force something (mod_jk, mod_rewrite or
something else) to % encode the data being fed into the AJP port?



You can force nod_jk to %-encode the URI before forwarding:

JkOptions +ForwardURIEscaped



I've tried adding +ForwardURIEscaped in my conf file as follows:

# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURIEscaped -ForwardDirectories

I would have expected mod_jk log to show the data % encoded, but it does
not:

text: J O Ë ‹ L
hex: 0x4a 0x4f 0xc3 0x8b 0x4c

I had expected to see something like:

JO%C3%8BL

Is that reasonable?  Does it make sense?


Yes.


Could something be turning off the encoding?  Do the headers values need to
be set to something specific?


Did you put the directive into the correct VirtualHost?

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



tomcat8 ClassCastException

2016-10-17 Thread musafir
Hi Apache Team,

Got 2 tomcat hosting same web application. Tomcats are  installed on
dedicated centos(6.8) VMs.  Everything was working fine in tomcat7 till
upgrade to tomcat8(8.0.38).

Now on one server, i am getting below error..
java.lang.ClassCastException: java.lang.String cannot be cast to
java.lang.Integer

e.g code iFacType = (Integer)userprofilesettings.get("facilityType");

Can you guys pls help understand
a) why it happens only on one server . is it something to do non
deterministic loader as reported in
https://bz.apache.org/bugzilla/show_bug.cgi?id=57129
b) Since its happening only on one server. is there any quick fix i can
use..fyi,if i downgrade  to tomcat 7 on VM, application works fine.


Regards, neet.


Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Mark Juszczec
On Mon, Oct 17, 2016 at 8:20 AM, Rainer Jung 
wrote:

> Am 17.10.2016 um 12:35 schrieb Mark Juszczec:
>
>> On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas  wrote:
>>
>>
>>> A small hint. I'd expect those to be % encoded.
>>>
>>>
>> Thank you very much for your reply.
>>
>> I've been thinking the problem is lack of % encoding after reading:
>>
>> *"Default encoding for GET*
>> The character set for HTTP query strings (that's the technical term for
>> 'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
>> specification. The character set is defined to be US-ASCII
>> . Any character that does not map to
>> US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
>> specification says that characters outside of US-ASCII must be encoded
>> using
>>  % escape sequences: each character is encoded as a literal % followed by
>> the two hexadecimal codes which indicate its character code. Thus, a
>> (US-ASCII
>> character code 97 = 0x61) is equivalent to %61. There *is no default
>> encoding for URIs* specified anywhere, which is why there is a lot of
>> confusion when it comes to decoding these values. "
>>
>> from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8
>>
>> Do you know if there's a way to force something (mod_jk, mod_rewrite or
>> something else) to % encode the data being fed into the AJP port?
>>
>
> You can force nod_jk to %-encode the URI before forwarding:
>
> JkOptions +ForwardURIEscaped
>
>
I've tried adding +ForwardURIEscaped in my conf file as follows:

# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardKeySize +ForwardURIEscaped -ForwardDirectories

I would have expected mod_jk log to show the data % encoded, but it does
not:

text: J O Ë ‹ L
hex: 0x4a 0x4f 0xc3 0x8b 0x4c

I had expected to see something like:

JO%C3%8BL

Is that reasonable?  Does it make sense?

Could something be turning off the encoding?  Do the headers values need to
be set to something specific?


Re: Is UTF-8 used everywhere for Tomcat 8.5.6?

2016-10-17 Thread Konstantin Kolinko
/2016-10-17 19:59 GMT+03:00 R :
> Hi,
>
> I have a default installation of Tomcat 8.5.6. When I make a POST request
> with a tilde character, and the encoding is set to UTF-8, it seems that my
> servlet handler is decoding it incorrectly. I have to set the character
> encoding on the HttpServletRequest parameter to decode properly, example:
>
>   protected void doPost(HttpServletRequest request, ...) {
>   // I have to set this manually.
>   request.setCharacterEncoding("UTF-8");
>
>   // Decoding works now.
>   String test = request.getParam("test");
>   ...
>   }
>
> Reading the Tomcat docs, it seems like everything should be UTF-8 by
> default. Is there a setting we still have to apply to get UTF-8 to be the
> default encoding?

For GET requests it defaults to UTF-8  (though actually it depends on
STRICT_SERVLET_COMPLIANCE setting. I prefer to explicitly configure
URIEncoding="UTF-8" on a Connector).

For POST requests you need to use
"org.apache.catalina.filters.SetCharacterEncodingFilter" filter (or a
similar 3-rd party filter e.g. the one provided by Spring Framework)
that essentially calls request.setCharacterEncoding() for you.

See webapps/examples/WEB-INF/web.xml for an example.



Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how to write a valve

2016-10-17 Thread Mark Thomas
On 17/10/2016 16:53, André Warnier (tomcat) wrote:



> In this case, the OP originally mentioned "add an attribute to the
> request".
> I have the feeling that the word "attribute" here was not very specific,
> and in reality (since we are talking about an authentication method
> "faking" another one) it may have meant "add a HTTP header" (the OP is
> welcome to correct if I am mistaken).
> Assuming that you were in a Filter, what you would need to do in such a
> "wrapper", would probably be to
> 1) copy the existing request headers in your own, wrapper-specific, new,
> headers collection
> 2) add the additional header to that copied collection
> 3) override all the methods by which one can obtain these headers, to
> return the copied/modified version instead of the original headers
> collection (or member of)
> 
> But maybe in a Valve, you do not need to go through all of that, and you
> can modify the original headers collection directly. (question mark)

Correct. In a Valve, you can modify request headers directly.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Is UTF-8 used everywhere for Tomcat 8.5.6?

2016-10-17 Thread Mark Thomas
On 17/10/2016 17:59, R wrote:
> Hi,
> 
> I have a default installation of Tomcat 8.5.6. When I make a POST request
> with a tilde character, and the encoding is set to UTF-8, it seems that my
> servlet handler is decoding it incorrectly.

The tilde character should not need to be encoded. The byte sequence is
also identical between UTF-8, ISO-8859-1 and ASCII.

You'll need to be more specific about exactly what URL you are passing
to Tomcat.


> I have to set the character
> encoding on the HttpServletRequest parameter to decode properly, example:
> 
>   protected void doPost(HttpServletRequest request, ...) {
>   // I have to set this manually.
>   request.setCharacterEncoding("UTF-8");
> 
>   // Decoding works now.
>   String test = request.getParam("test");
>   ...
>   }
> 
> Reading the Tomcat docs, it seems like everything should be UTF-8 by
> default. Is there a setting we still have to apply to get UTF-8 to be the
> default encoding?

No. Tomcat 8.5.x uses UTF-8 by default.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Apache mod_jk connector question about alias

2016-10-17 Thread Rainer Jung

Am 17.10.2016 um 19:16 schrieb Marc Chamberlin:

Hello -  My apologies if this has already been asked or the wrong mail
list, but Google is not coming up with an answer for me, so here goes...

I am trying to set up the mod_jk connector between an Apache HTTPD
server and Tomcat with the intent of supporting virtual hosts, and
serving static content from the Apache server and forwarding jsp and
servlet requests to Tomcat. Typical scenario I know...

Most of this I have working but the trouble I am having is with the use
an Alias directive for the Apache server. Following instructions for the
JSP examples that came with my distribution for Tomcat 8, I created a
configuration for


 

  # The following line makes apache aware of the location of
  # the /jsp-examples context
  Alias /jsp-examples "/srv/tomcat/webapps/examples/jsp"

  
Options Indexes  FollowSymLinks
AllowOverride None
# Controls who can get stuff from this server.

Require all granted


Order allow,deny
Allow from all

  

  # Mounted stuff goes via tomcat (ajp13)
  JkMount /jsp-examples tomcatWorker1
  JkMount /jsp-examples/* tomcatWorker1
  # Serve html, css, js, jpg, png and gif using Apache
  JkUnMount /*.html tomcatWorker1
  JkUnMount /*.css tomcatWorker1
  JkUnMount /*.js tomcatWorker1
  JkUnMount /*.jpg  tomcatWorker1
  JkUnMount /*.png  tomcatWorker1
  JkUnMount /*.gif  tomcatWorker1



I am actually defining this in the context of a virtual host and if
necessary I can post its configuration as well.

Using the JK debug level and monitoring the mod_jk.log file I can see
what is going wrong, I just don't know how to rectify it -


[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to
ajp13 pos=4 len=469 max=8192
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208):  12 34 01
D1 02 02 00 08 48 54 54 50 2F 31 2E 31  - .4..HTTP/1.1
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): 0010 00 00 0E
2F 6A 73 70 2D 65 78 61 6D 70 6C 65 73  - .../jsp-examples
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): 0020 2F 00 00
0D 31 39 32 2E 31 36 38 2E 31 30 2E 31  - /...192.168.10.1


This excerpt shows that the Apache server is sending a message to the
Tomcat worker telling it to find a resource "/jsp-examples" which of
course doesn't really exist and so Tomcat reports a "Not Found" failure.
What I want is for the Apache server to send the actual location that
this alias is mapped to i.e. "/examples/jsp", which is what actually
exists in the Tomcat context. I can fool Tomcat into handling this alias
request by creating a link named jsp-examples -> examples/jsp within the
Tomcat webapps directory but that seems like a hack and not something I
want to have to do/maintain for all the other resources I will want to
handle via alias commands.

Is there a magic incantation that I am missing?  Thanks in advance for
suggestions/help Marc...


Alias maps URIs to local file system directories.
JkMount maps URIs to remote back end requests.

You can not change JkMount forwarding using Alias (except that if you 
have a comflict between Alias and JkMount only one of them wins).


As far as I understand you are not really trying to map requests to the 
local web server file system, but instead want to forward to a Tomcat 
back end but change the URI path which is used when accessing Apache to 
something else being used to acces Tomcat. E.g. the URI 
/jsp-examples/something gets used when accessing Apache and mod_jk 
should send this request as /examples/jsp/something to the Tomcat back end.


If you really need to change URIs, then often mod_proxy is much easier 
to set up, because it has specific directives for this (ProxyPass etc.).


With mod_jk you would first need to use mod_rewrite RewriteRules to 
change the URI, and then JkMount to forward them. More details can be 
found at


http://tomcat.apache.org/connectors-doc/common_howto/proxy.html#URL%20Rewriting

The rest of this docs page might be useful as well.

Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Apache mod_jk connector question about alias

2016-10-17 Thread Marc Chamberlin
Hello -  My apologies if this has already been asked or the wrong mail 
list, but Google is not coming up with an answer for me, so here goes...


I am trying to set up the mod_jk connector between an Apache HTTPD 
server and Tomcat with the intent of supporting virtual hosts, and 
serving static content from the Apache server and forwarding jsp and 
servlet requests to Tomcat. Typical scenario I know...


Most of this I have working but the trouble I am having is with the use 
an Alias directive for the Apache server. Following instructions for the 
JSP examples that came with my distribution for Tomcat 8, I created a 
configuration for



 

  # The following line makes apache aware of the location of
  # the /jsp-examples context
  Alias /jsp-examples "/srv/tomcat/webapps/examples/jsp"

  
Options Indexes  FollowSymLinks
AllowOverride None
# Controls who can get stuff from this server.

Require all granted


Order allow,deny
Allow from all

  

  # Mounted stuff goes via tomcat (ajp13)
  JkMount /jsp-examples tomcatWorker1
  JkMount /jsp-examples/* tomcatWorker1
  # Serve html, css, js, jpg, png and gif using Apache
  JkUnMount /*.html tomcatWorker1
  JkUnMount /*.css tomcatWorker1
  JkUnMount /*.js tomcatWorker1
  JkUnMount /*.jpg  tomcatWorker1
  JkUnMount /*.png  tomcatWorker1
  JkUnMount /*.gif  tomcatWorker1



I am actually defining this in the context of a virtual host and if 
necessary I can post its configuration as well.


Using the JK debug level and monitoring the mod_jk.log file I can see 
what is going wrong, I just don't know how to rectify it -


[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug] 
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to 
ajp13 pos=4 len=469 max=8192
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug] 
ajp_connection_tcp_send_message::jk_ajp_common.c (1208):  12 34 01 
D1 02 02 00 08 48 54 54 50 2F 31 2E 31  - .4..HTTP/1.1
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug] 
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): 0010 00 00 0E 
2F 6A 73 70 2D 65 78 61 6D 70 6C 65 73  - .../jsp-examples
[Mon Oct 17 09:28:01.145 2016] [30237:139868423546816] [debug] 
ajp_connection_tcp_send_message::jk_ajp_common.c (1208): 0020 2F 00 00 
0D 31 39 32 2E 31 36 38 2E 31 30 2E 31  - /...192.168.10.1


This excerpt shows that the Apache server is sending a message to the 
Tomcat worker telling it to find a resource "/jsp-examples" which of 
course doesn't really exist and so Tomcat reports a "Not Found" failure. 
What I want is for the Apache server to send the actual location that 
this alias is mapped to i.e. "/examples/jsp", which is what actually 
exists in the Tomcat context. I can fool Tomcat into handling this alias 
request by creating a link named jsp-examples -> examples/jsp within the 
Tomcat webapps directory but that seems like a hack and not something I 
want to have to do/maintain for all the other resources I will want to 
handle via alias commands.


Is there a magic incantation that I am missing?  Thanks in advance for 
suggestions/help Marc...




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Is UTF-8 used everywhere for Tomcat 8.5.6?

2016-10-17 Thread R
Hi,

I have a default installation of Tomcat 8.5.6. When I make a POST request
with a tilde character, and the encoding is set to UTF-8, it seems that my
servlet handler is decoding it incorrectly. I have to set the character
encoding on the HttpServletRequest parameter to decode properly, example:

  protected void doPost(HttpServletRequest request, ...) {
  // I have to set this manually.
  request.setCharacterEncoding("UTF-8");

  // Decoding works now.
  String test = request.getParam("test");
  ...
  }

Reading the Tomcat docs, it seems like everything should be UTF-8 by
default. Is there a setting we still have to apply to get UTF-8 to be the
default encoding?

Thanks


Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-17 Thread Tullio Bettinazzi
I monitored it using Yourkit profiler and I didn't see any extreme GC.

I noticed anotehr thing : looking for 4 users which had the problem they seems 
to have the problem "in sequence".

The first user "stops" for 4 seconds then another one "stops" and so on : they 
don't seem to stop at the sam time (as it would be expected in case of GC) but 
in sequence.

Tks



Da: André Warnier (tomcat) 
Inviato: lunedì 17 ottobre 2016 18.01
A: users@tomcat.apache.org
Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67

On 17.10.2016 17:52, Tullio Bettinazzi wrote:
> I didn't find any solution to my problem.
>
> Could someone provide suggestions or a strategy to find the solution ?
>

"I don't see relevant garbage collection : heap size and permgen have correct 
dimentions."

Define "correct".  Are you really *logging* the JVM Garbage Collection, and do 
you *know*
that this is not the issue ?

(Note that 4 seconds seems an awfully long time for a GC; but one would want to 
eliminate
this with certainty, before looking any further).


>
>
> 
> Da: Martijn Bos 
> Inviato: lunedì 3 ottobre 2016 21.05
> A: Tomcat Users List
> Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67
>
> On 2016-10-03 07:56:34, Tullio Bettinazzi wrote:
>> I've an application under tomcat.
>> When only a one or two users works on it everithing is ok.
>> When the number of users grows the application slows down.
>> Is not a memory nor a cpu problem : using top I see the system resources 
>> quite free.
>> I don't see relevant garbage collection : heap size and permgen have correct 
>> dimentions.
>> No other applications are running on the system.
>> I log more or less every relevant operation in my system (db query and so 
>> on) and I see that every slowdown is concentered in a single operation.
>> I mean all operations take "normal" time but one or two of them take 4 
>> seconds more.
>> The "slowing" operations are not the same in different executions, and 
>> theydo not have a specific type (not only DB query, not only DB stored 
>> procedures, not only.).
>> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
>> more or less) and then it restarts.
>> I don't think it's a "queue" problem because otherwise the wait time would 
>> be unperdictable and not a "fixed" 4 seconds time.
>> I don't know any parameter impacting on that behaviour.
>> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
>> Could someone suggest a solution for my problem or, at least, an 
>> investigation strategy.
>> Tks
>>
>> Tullio
>>
>
>
> The few examples that you mention are all database related (query/stored 
> procedure).
> Can it be that your connection pool (if used) combined with not closing 
> connections is part of the problem.
>
> I can imagine :
> 1)
> Maybe you run out of conenctions, because connections are not properly closed.
> And also the connection pool teminates connections when they are not used for 
> 4 seconds.
> After 4 seconds the pool can recreate connections again.
>
> or 2)
> Maybe your connection pool has very limited connections.
> With one or two users this limited number of connections in the pool will 
> suffice.
> If there are more users, the max. number of connections isn't enough.
> The pool then has to wait for connections to become fee again.
>
>
> (uhhI'm not an expert at all, but the above came immediately to my mind)
>
> --
> Met vriendelijke groet,
>
> Martijn Bos
> +31 6 39477001
>
> (Public pgp-key : http://maboc.nl/pubkey.maboc.asc)
maboc.nl
maboc.nl
-BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 
mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk 
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...



> maboc.nl
maboc.nl
maboc.nl
-BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 
mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk 
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...



> maboc.nl
> -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 
> mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk 
> sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...
>
>
>
>


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[ANN] Apache Tomcat 6.0.47 available

2016-10-17 Thread Violeta Georgieva
The Apache Tomcat team announces the immediate availability of Apache
Tomcat 6.0.47.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages and Java Expression Language technologies.

This release contains a number of bug fixes and improvements compared to
version 6.0.45. The notable changes since 6.0.45 include:
- Update to Tomcat Native Library version 1.2.10.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-6.0-doc/changelog.html

Note: This version has 3 zip binaries: a generic one and
  two bundled with Tomcat native binaries for Windows
  operating systems running on different CPU architectures.

Downloads:
http://tomcat.apache.org/download-60.cgi

Migration guides from Apache Tomcat 5.5.x:
http://tomcat.apache.org/migration.html

- The Apache Tomcat team


Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-17 Thread tomcat

On 17.10.2016 17:52, Tullio Bettinazzi wrote:

I didn't find any solution to my problem.

Could someone provide suggestions or a strategy to find the solution ?



"I don't see relevant garbage collection : heap size and permgen have correct 
dimentions."

Define "correct".  Are you really *logging* the JVM Garbage Collection, and do you *know* 
that this is not the issue ?


(Note that 4 seconds seems an awfully long time for a GC; but one would want to eliminate 
this with certainty, before looking any further).







Da: Martijn Bos 
Inviato: lunedì 3 ottobre 2016 21.05
A: Tomcat Users List
Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67

On 2016-10-03 07:56:34, Tullio Bettinazzi wrote:

I've an application under tomcat.
When only a one or two users works on it everithing is ok.
When the number of users grows the application slows down.
Is not a memory nor a cpu problem : using top I see the system resources quite 
free.
I don't see relevant garbage collection : heap size and permgen have correct 
dimentions.
No other applications are running on the system.
I log more or less every relevant operation in my system (db query and so on) 
and I see that every slowdown is concentered in a single operation.
I mean all operations take "normal" time but one or two of them take 4 seconds 
more.
The "slowing" operations are not the same in different executions, and theydo 
not have a specific type (not only DB query, not only DB stored procedures, not 
only.).
It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
more or less) and then it restarts.
I don't think it's a "queue" problem because otherwise the wait time would be 
unperdictable and not a "fixed" 4 seconds time.
I don't know any parameter impacting on that behaviour.
I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
Could someone suggest a solution for my problem or, at least, an investigation 
strategy.
Tks

Tullio




The few examples that you mention are all database related (query/stored 
procedure).
Can it be that your connection pool (if used) combined with not closing 
connections is part of the problem.

I can imagine :
1)
Maybe you run out of conenctions, because connections are not properly closed.
And also the connection pool teminates connections when they are not used for 4 
seconds.
After 4 seconds the pool can recreate connections again.

or 2)
Maybe your connection pool has very limited connections.
With one or two users this limited number of connections in the pool will 
suffice.
If there are more users, the max. number of connections isn't enough.
The pool then has to wait for connections to become fee again.


(uhhI'm not an expert at all, but the above came immediately to my mind)

--
Met vriendelijke groet,

Martijn Bos
+31 6 39477001

(Public pgp-key : http://maboc.nl/pubkey.maboc.asc)
maboc.nl
maboc.nl
-BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 
mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk 
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: how to write a valve

2016-10-17 Thread tomcat

On 17.10.2016 16:57, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/14/16 6:08 AM, Mark Thomas wrote:

On 14/10/2016 10:51, André Warnier (tomcat) wrote:

On 14.10.2016 10:05, Mark Thomas wrote:

On 13/10/2016 16:04, Campbell, Lance wrote:

Tomcat 8.0.38

In my Eclipse development environment when particular
servlet requests are made I want to simulate going through
Shibboleth prior to Tomcat handling the request.  I wanted to
see if this will work.

In Eclipse within each dynamic web application I would add a
valve to the context.xml file.

The valve would:

1)  Check the URL request.

2)  If the URL string matches a list then it will add
particular name value pairs to the request.

Example of a possible valve:




1)  Can a valve actually identify a particular URL path?


Yes. Valves have access to Tomcat's internal request and
response objects.


2)  Can a valve add an attribute to the request prior to
the servlet getting the request?


Yes.


Apologies for barging in.  Does that mean that, at this point,
the request is still "mutable" ? (at the servlet filter level, it
isn't, as far as I know).


Mostly, yes since a Valve has direct access to the internals.

In a Filter you are limited to what you can do with
HttpServletRequest. It isn't completely immutable (setAttribute(),
setCharacterEncoding(), changeSessionId()) but you have a lot less
scope for changing the request.


In both cases (Filter, Valve), it's possible to wrap the request
object (HttpServletRequest in the case of a Filter, (Tomcat) Request
in the case of a Valve) and basically change anything you want. There
are certainly things you can't do and expect everything to work -- for
example, disconnecting the input streams, etc. but many things are
possible including intercepting calls to the request methods, which is
of course the most interesting thing that you can do in general.


In this case, the OP originally mentioned "add an attribute to the request".
I have the feeling that the word "attribute" here was not very specific, and in reality 
(since we are talking about an authentication method "faking" another one) it may have 
meant "add a HTTP header" (the OP is welcome to correct if I am mistaken).
Assuming that you were in a Filter, what you would need to do in such a "wrapper", would 
probably be to

1) copy the existing request headers in your own, wrapper-specific, new, 
headers collection
2) add the additional header to that copied collection
3) override all the methods by which one can obtain these headers, to return the 
copied/modified version instead of the original headers collection (or member of)


But maybe in a Valve, you do not need to go through all of that, and you can modify the 
original headers collection directly. (question mark)




Tomcat does not include wrapper classes for its Request and Response
objects, but there are examples includes in a long-standing Bugzilla
issue[1] that anyone is welcome to use.

In general, I would say that anything that *can* be done in a Filter
*should* be done in a Filter (as opposed to a Valve). In the OP's
case, it might not be entirely possible if his operation needs to
affect the way that authentication is done, since that is typically
done (for container-based authentication) in Valves before any Filter
is called.

- -chris

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Strange wait time in my application - Tomcat 7.0.67

2016-10-17 Thread Tullio Bettinazzi
I didn't find any solution to my problem.

Could someone provide suggestions or a strategy to find the solution ?

Tks



Da: Martijn Bos 
Inviato: lunedì 3 ottobre 2016 21.05
A: Tomcat Users List
Oggetto: Re: Strange wait time in my application - Tomcat 7.0.67

On 2016-10-03 07:56:34, Tullio Bettinazzi wrote:
> I've an application under tomcat.
> When only a one or two users works on it everithing is ok.
> When the number of users grows the application slows down.
> Is not a memory nor a cpu problem : using top I see the system resources 
> quite free.
> I don't see relevant garbage collection : heap size and permgen have correct 
> dimentions.
> No other applications are running on the system.
> I log more or less every relevant operation in my system (db query and so on) 
> and I see that every slowdown is concentered in a single operation.
> I mean all operations take "normal" time but one or two of them take 4 
> seconds more.
> The "slowing" operations are not the same in different executions, and theydo 
> not have a specific type (not only DB query, not only DB stored procedures, 
> not only.).
> It seems like if the thread is frozen for a fixed amount fo time (4 seconds 
> more or less) and then it restarts.
> I don't think it's a "queue" problem because otherwise the wait time would be 
> unperdictable and not a "fixed" 4 seconds time.
> I don't know any parameter impacting on that behaviour.
> I use Tomcat 7.0.32 with JVM 1.7.0.67 on a Linux server.
> Could someone suggest a solution for my problem or, at least, an 
> investigation strategy.
> Tks
>
> Tullio
>


The few examples that you mention are all database related (query/stored 
procedure).
Can it be that your connection pool (if used) combined with not closing 
connections is part of the problem.

I can imagine :
1)
Maybe you run out of conenctions, because connections are not properly closed.
And also the connection pool teminates connections when they are not used for 4 
seconds.
After 4 seconds the pool can recreate connections again.

or 2)
Maybe your connection pool has very limited connections.
With one or two users this limited number of connections in the pool will 
suffice.
If there are more users, the max. number of connections isn't enough.
The pool then has to wait for connections to become fee again.


(uhhI'm not an expert at all, but the above came immediately to my mind)

--
Met vriendelijke groet,

Martijn Bos
+31 6 39477001

(Public pgp-key : http://maboc.nl/pubkey.maboc.asc)
maboc.nl
maboc.nl
-BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 
mQENBFJ6LpgBCADL9w2eicatZKiw4xijCVC8WZpcPOr2So6jFfQ6nWk3bTXoVsHk 
sYgdLIFeCn9Wn+EeC+CSoosyMcUeijKH5yVqc/mcg0 ...





Re: how to write a valve

2016-10-17 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/14/16 6:08 AM, Mark Thomas wrote:
> On 14/10/2016 10:51, André Warnier (tomcat) wrote:
>> On 14.10.2016 10:05, Mark Thomas wrote:
>>> On 13/10/2016 16:04, Campbell, Lance wrote:
 Tomcat 8.0.38
 
 In my Eclipse development environment when particular
 servlet requests are made I want to simulate going through
 Shibboleth prior to Tomcat handling the request.  I wanted to
 see if this will work.
 
 In Eclipse within each dynamic web application I would add a
 valve to the context.xml file.
 
 The valve would:
 
 1)  Check the URL request.
 
 2)  If the URL string matches a list then it will add
 particular name value pairs to the request.
 
 Example of a possible valve:
 
 
 
 
 1)  Can a valve actually identify a particular URL path?
>>> 
>>> Yes. Valves have access to Tomcat's internal request and
>>> response objects.
>>> 
 2)  Can a valve add an attribute to the request prior to
 the servlet getting the request?
>>> 
>>> Yes.
>> 
>> Apologies for barging in.  Does that mean that, at this point,
>> the request is still "mutable" ? (at the servlet filter level, it
>> isn't, as far as I know).
> 
> Mostly, yes since a Valve has direct access to the internals.
> 
> In a Filter you are limited to what you can do with
> HttpServletRequest. It isn't completely immutable (setAttribute(),
> setCharacterEncoding(), changeSessionId()) but you have a lot less
> scope for changing the request.

In both cases (Filter, Valve), it's possible to wrap the request
object (HttpServletRequest in the case of a Filter, (Tomcat) Request
in the case of a Valve) and basically change anything you want. There
are certainly things you can't do and expect everything to work -- for
example, disconnecting the input streams, etc. but many things are
possible including intercepting calls to the request methods, which is
of course the most interesting thing that you can do in general.

Tomcat does not include wrapper classes for its Request and Response
objects, but there are examples includes in a long-standing Bugzilla
issue[1] that anyone is welcome to use.

In general, I would say that anything that *can* be done in a Filter
*should* be done in a Filter (as opposed to a Valve). In the OP's
case, it might not be entirely possible if his operation needs to
affect the way that authentication is done, since that is typically
done (for container-based authentication) in Valves before any Filter
is called.

- -chris

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=45014
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYBOa/AAoJEBzwKT+lPKRY+GoQAKTCrNRDzJlo9ZVJW4KkaWXr
hdkBBfQDSIcfnuPXratMdz9WBpyXBVocdq+tqPuDCAhnsT+0hbND+hnHKGW07IZ2
Q5kfZZNc9t9WEMFWo/wUkdmlC55VMxGIRHfLplhbv6ldBv6/XB5JfgBUNUXVCmfq
GzFQ6Es5IG3/5iTD79RypYU2yZ38or4eNff6Os/MKOFajUFDKjnzlTGUa5hN8T7z
aNg7IKrFWgQhqFt8jBHLpTGJt28vNZ/kriEr47YbiO5MviC6mYi15fhdMEMaG0JT
RsNUhLlLuBuCscdElG93LYNDOL8MEwwR3gXRfpq2nfdW9cIY3w8xmgd+mY/VpaIj
DnULQ6Ghx7XD/kJWM4dSutRjPWKFKiaGO4kTnDwEPRLACr2O6YZlFzldrAWtbWpf
GTDtjssFcX7xD/tWjHzD37kfiCAnJjZTGBAEDQcdKwD0M9wLxqIzSaZqRewlTOKT
wjy76PnJE3HFUjRRAXh6iEBRFyb+J9En6i7jGPsplV0aLk6gQB3d8vH0Ggw2qUJz
uIFV5zuNacAqvEvIHb9wBAFxhUlGrftewQpGUK5ZaNjIpgcOeH5KphoAY8KcNKsO
SrcS/i6vS/Uxtiu9JaCk0zMdqIyc1rHHm/UigjjAg5chOvC1KlMeHRgrb7SVPx8z
9cSDZ3M+LFWXGKvyP/rx
=kP1+
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Long running socket reads

2016-10-17 Thread Rallavagu



On 10/14/16 1:01 AM, Mark Thomas wrote:

On 12/10/2016 16:22, Rallavagu wrote:

Tomcat 7.0.70 - Sun JDK 1.7.0_80

I have following long running thread (almost 5 sec).


No you don't. That thread isn't doing it any work. It is blocking,
waiting for I/O.


Well, I got in impression because the thread shows as "RUNNABLE" in tow 
thread dumps in a row.





It appears to be reading data from socket


Sort of correct. It is waiting for data to arrive.

I suppose it is waiting for the data to arrive from slow clients?




(external resource potentially).


Wrong.


Wonder how I
could go about debug these kind of threads to understand which external
resource is it spending more time on reading. Thank.


The stack trace contains class names and line numbers. The source code
is freely available. While the class names themselves provide a broad
hint as to what this thread is waiting for, you always have the option
of looking at the source code.

In this case start with these:
AbstractHttp11Processor line 994
Http11Processor line 168


Here is what at line 168 of Http1Processor

if (!inputBuffer.fill()) {
throw new EOFException(sm.getString("iib.eof.error"));
}

I couldnt make much out of this. But, I assume that this thread is 
waiting for client to finish sending the data?


Thanks for the response.



Mark



"http-bio-28080-exec-523" daemon prio=10 tid=0x7fc5e403e000
nid=0x3cbd runnable [0x7fc51ce0d000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:516)

at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501)

at
org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)

at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:994)

at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:623)

at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)

- locked <0x0006e20ac9e8> (a
org.apache.tomcat.util.net.SocketWrapper)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:745)

-
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...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Rainer Jung

Am 17.10.2016 um 12:35 schrieb Mark Juszczec:

On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas  wrote:


On 17/10/2016 08:30, Mark Thomas wrote:

On 16/10/2016 19:09, Mark Juszczec wrote:

Hello

I have Tomcat 8.0.28 running on CentOS Linux 7.2.1511 behind Apache

2.4.6


I'm using AJP 1.3 for communication between Apache and Tomcat

Its all powered by Java 1.8

I'm having a problem with international characters when I send them as

the

request *URI* (which is used by GET requests and this is a GET request).

Let's say I get the string AOËL

mod_jk log  logs the bytes with the message

 "ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to

ajp13

pos=4 len=1411 max=8192" (at
ajp_connection_tcp_send_message::jk_ajp_common.c) shows them to be:

  41 4f c3 8b 4c

AFAIK this means the correct bytes are being sent to AJP.  Is that

correct?


That is the correct UTF-8 byte encoding for the characters AOËL.


A small hint. I'd expect those to be % encoded.



Thank you very much for your reply.

I've been thinking the problem is lack of % encoding after reading:

*"Default encoding for GET*
The character set for HTTP query strings (that's the technical term for
'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
specification. The character set is defined to be US-ASCII
. Any character that does not map to
US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
specification says that characters outside of US-ASCII must be encoded using
 % escape sequences: each character is encoded as a literal % followed by
the two hexadecimal codes which indicate its character code. Thus, a (US-ASCII
character code 97 = 0x61) is equivalent to %61. There *is no default
encoding for URIs* specified anywhere, which is why there is a lot of
confusion when it comes to decoding these values. "

from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8

Do you know if there's a way to force something (mod_jk, mod_rewrite or
something else) to % encode the data being fed into the AJP port?


You can force nod_jk to %-encode the URI before forwarding:

JkOptions +ForwardURIEscaped

(see http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html)

You might need to experiment whether that really fixes your issues, e.g. 
when parts of the URI are already %-encoded etc.


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Mixed authentication

2016-10-17 Thread tomcat

On 17.10.2016 11:51, Brugnerotto Angélique wrote:

Good morning everybody.

We use Tomcat 6 for an internal web site.
Actually, the authentication is negociate with SSO. It works fine. When we 
access the web site, the Windows authentication of the Windows session Windows 
is resumed.

We would like to publish this site in external.
We have problems with negociate authentification.

We have tried to put the mixed authentication with Form authentification.

It works but the problem is that when we access the site, we have a page with a 
form and 2 choices :
- Put the username/password
   - A button to use Windows authentication
We have followed this tutorial : 
http://code.dblock.org/2010/05/27/to...-w-waffle.html

What we would like to do is that the web site tries automatically to do a 
negociate authentication and only if it can't, to show a form. We don't find 
how to do this. Is it possible ? Can you help us ?



Hello Angélique.
What you are trying to do may be difficult, even impossible.
One problem is that the browser will not even *try* Windows Integrated Authentication, if 
the workstation where it runs is not part of the same domain as the server (or at least a 
"trusted" server).

(That is for security reasons, as WIA is only deemed "safe" within the same 
domain).
So the browser will then (probably, depending on how the PC and the server are set up) 
automatically revert to HTTP Basic authentication (meaning that the browser built-in login 
popup dialog will appear).

But that is not "form authentication".

Note that one of the comments on the page which you mention above, says pretty much the 
same thing : see " Atdavie • 4 years ago "
(Full link : 
http://code.dblock.org/2010/05/27/tomcat-single-sign-on-mixed-with-form-authentication-w-waffle.html)


The whole issue is fairly complex, and has to do with discrepancies between what the HTTP 
protocol foresees or not as valid authentication methods (of which "form" is not one), and 
how the Windows (Microsoft-specific) authentication works.


I would suggest that you stay with your current solution, it is the simplest 
one.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Round Robin LoadBalance/Failover Configuration for Apache

2016-10-17 Thread Jayaram Ponnusamy
Hi Christopher,

Thanks for the reply. I am new to Apache and Tomcat, Our Tomcat is not
cluster and Sticky is not enabled.
Could you please let me know which one will be help to avoid failover if
one Tomcat went down.

Thanks
Jayaram

On Sun, Oct 16, 2016 at 10:32 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jayaram,
>
> On 10/13/16 1:00 AM, Jayaram Ponnusamy wrote:
> > Hi All,
> >
> > Currently we have two webServers (WA and WB) and two Tomcat Servers
> > (TA, TB). WA configured for TA and WB configured for TB. How to
> > configure Loadbalance and Failover between these two Servers.
> >
> > For Eg. WA is connected with TA, if TA failed then WA should
> > connect TB, Similarly WB connect TA if TB is failed.
> >
> > It may simple, but I am new to Apache. Most of the LB example
> > described for 1WEB and TWO AppServer. Kindly please help me to
> > solve this problem
> >
> > Given workers.properties details below. Kindly please help me to
> > solve this issue.
> >
> > WEB-A's workers.properties worker.list=wa worker.wa.type=ajp13
> > worker.wa.host=ta worker.wa.port=9009
> >
> > WEB-B's workers.properties worker.list=wb worker.wb.type=ajp13
> > worker.wb.host=tb worker.wb.port=9009
>
> Are your Tomcat instances in a cluster? Do you want them to be? Are
> you using sticky sessions? Do you want to use sticky sessions?
>
> Is it okay for users who are failed-over to the other server to have
> to re-authenticate with your application to continue?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYA9XAAAoJEBzwKT+lPKRY0esQAMium0WaEZLtznE5pMmSAu28
> SwP4p/wGv5QiVXm7RDcIqIEG1oTa/6KVRUukmNE695i293qAIBhZI/HM7whip038
> C3X/IG/3e+pe06wt31osnzKbwWEDdnWaLKyGXaF3N1fzaII5MBxPst/mDMhmfclK
> oIgFBIgwTuKA760HL0yWIph7Slg4DSg/ZkJxdSKM2wXkf+oJq+e2/mJOBgpgbm82
> fz5JYL6FIWEobbONKLbZNEFL+670Xc+IxD+irkqwhURGihelyQ9ads9Sz2JpoT9J
> gpeEwmtu4pXi7RYlA67/qST/gVmYlfWWaurcpfWiEZhwXz0cotx73AmBEJCSr7Ml
> nkXLbhJThx4YWpZtjmrBfXAd4Z4SW6W9rCB/VmB1QtL+pEv5n2lsi6bOV+vA3BxK
> oAbicf/CI6HRUyE2Ar+IPmjtSnxu1n7q/ZhLkIkcQF/05VuEoQ92eVqoRvoM2dSA
> aQDYZAL9IiAtHrb5fq+r6vHowRlCtZP1rTHniXoUnILRHCA1xeMU1VN60XzWbUwo
> 11a+C37ZeAStlnpH2TbRptwdGFY78F2H2GBDdw4s/xrU1MvYaN1x3H+b2CJhBFMm
> CFhpWtGsE5WDMYVd/ujelB9FgzPcryKlUSBvNnRpzm5qntO2orS5CTfUFhQVsFU/
> Mm0GELyJ+oVLRGRTp8sJ
> =8Q5b
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


--


Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Mark Juszczec
On Mon, Oct 17, 2016 at 4:29 AM, Mark Thomas  wrote:

> On 17/10/2016 08:30, Mark Thomas wrote:
> > On 16/10/2016 19:09, Mark Juszczec wrote:
> >> Hello
> >>
> >> I have Tomcat 8.0.28 running on CentOS Linux 7.2.1511 behind Apache
> 2.4.6
> >>
> >> I'm using AJP 1.3 for communication between Apache and Tomcat
> >>
> >> Its all powered by Java 1.8
> >>
> >> I'm having a problem with international characters when I send them as
> the
> >> request *URI* (which is used by GET requests and this is a GET request).
> >>
> >> Let's say I get the string AOËL
> >>
> >> mod_jk log  logs the bytes with the message
> >>
> >>  "ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to
> ajp13
> >> pos=4 len=1411 max=8192" (at
> >> ajp_connection_tcp_send_message::jk_ajp_common.c) shows them to be:
> >>
> >>   41 4f c3 8b 4c
> >>
> >> AFAIK this means the correct bytes are being sent to AJP.  Is that
> correct?
> >
> > That is the correct UTF-8 byte encoding for the characters AOËL.
>
> A small hint. I'd expect those to be % encoded.
>

Thank you very much for your reply.

I've been thinking the problem is lack of % encoding after reading:

*"Default encoding for GET*
The character set for HTTP query strings (that's the technical term for
'GET parameters') can be found in sections 2 and 2.1 the "URI Syntax"
specification. The character set is defined to be US-ASCII
. Any character that does not map to
US-ASCII must be encoded in some way. Section 2.1 of the URI Syntax
specification says that characters outside of US-ASCII must be encoded using
 % escape sequences: each character is encoded as a literal % followed by
the two hexadecimal codes which indicate its character code. Thus, a (US-ASCII
character code 97 = 0x61) is equivalent to %61. There *is no default
encoding for URIs* specified anywhere, which is why there is a lot of
confusion when it comes to decoding these values. "

from http://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8

Do you know if there's a way to force something (mod_jk, mod_rewrite or
something else) to % encode the data being fed into the AJP port?

Mark


Mixed authentication

2016-10-17 Thread Brugnerotto Angélique
Good morning everybody.

We use Tomcat 6 for an internal web site.
Actually, the authentication is negociate with SSO. It works fine. When we 
access the web site, the Windows authentication of the Windows session Windows 
is resumed.

We would like to publish this site in external.
We have problems with negociate authentification.

We have tried to put the mixed authentication with Form authentification. 

It works but the problem is that when we access the site, we have a page with a 
form and 2 choices :
   - Put the username/password
  - A button to use Windows authentication
We have followed this tutorial : 
http://code.dblock.org/2010/05/27/to...-w-waffle.html

What we would like to do is that the web site tries automatically to do a 
negociate authentication and only if it can't, to show a form. We don't find 
how to do this. Is it possible ? Can you help us ?

Thanks a lot for your help.
Have a nice day.
Best Regards,
Angélique Brugnerotto


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Mark Thomas
On 17/10/2016 08:30, Mark Thomas wrote:
> On 16/10/2016 19:09, Mark Juszczec wrote:
>> Hello
>>
>> I have Tomcat 8.0.28 running on CentOS Linux 7.2.1511 behind Apache 2.4.6
>>
>> I'm using AJP 1.3 for communication between Apache and Tomcat
>>
>> Its all powered by Java 1.8
>>
>> I'm having a problem with international characters when I send them as the
>> request *URI* (which is used by GET requests and this is a GET request).
>>
>> Let's say I get the string AOËL
>>
>> mod_jk log  logs the bytes with the message
>>
>>  "ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to ajp13
>> pos=4 len=1411 max=8192" (at
>> ajp_connection_tcp_send_message::jk_ajp_common.c) shows them to be:
>>
>>   41 4f c3 8b 4c
>>
>> AFAIK this means the correct bytes are being sent to AJP.  Is that correct?
> 
> That is the correct UTF-8 byte encoding for the characters AOËL.

A small hint. I'd expect those to be % encoded.

Mark


> 
> 
>> Running remote debugging via Spring Tool Suite to hook up to my code shows
>> me I receive:
>>
>> 41 4f c3 c3 83 c2 c2 8b 4c
> 
> That is not valid UTF-8. If the UTF-8 bytes had been treated as
> ISO-8859-1 and then re-encoded as UTF-8 I'd expect to see:
> 
> 41 4f c3 83 c2 8b 4c
> 
>> I have verified the incorrect bytes appear as early in the call stack as
>> when CoyoteAdapter.process() is invoked
> 
> I think you need to go a little further up the stack to track this down.
> 
>> I have UTF-8 specified as URIEncoding in ajp  and it has had no
>> effect.
> 
> That is the change I would have expected was required.
> 
>> Ive also specified  useBodyEncodingForURI as true with no effect.
> 
> That won't help for a GET request.
> 
>> Conventional wisdom says the data is getting inadvertently as ISO-8859-1
>> somewhere along the line. Since the data is correct (per mod_jk.log)
>> heading into AJP and incorrect once CoyoteAdapter.java starts handling it
>> somehow, something is going wrong when the data is interpreted after being
>> read from the AJP port.
>>
>> Is that correct?
> 
> It looks to be something like that.
> 
>> I am at a loss as to how to correct this.  The only 2 things the docs say
>> are to use URIEnocding="UTF-8" and  useBodyEncodingForURI="true".  I'm
>> doing that and its not working.
>>
>> I am at a loss about what else to try or where to look.
>>
>> If you were faced with this, what would you try?  Any advice or suggestions
>> will be greatly appreciated.
> 
> I'd dig into the connector code. You need to figure out where those
> bytes are being transformed and why.
> 
> Mark
> 
> 
> -
> 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...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat 8, AJP 1.3 UTF-8/ISO-8859-1 conversion problem

2016-10-17 Thread Mark Thomas
On 16/10/2016 19:09, Mark Juszczec wrote:
> Hello
> 
> I have Tomcat 8.0.28 running on CentOS Linux 7.2.1511 behind Apache 2.4.6
> 
> I'm using AJP 1.3 for communication between Apache and Tomcat
> 
> Its all powered by Java 1.8
> 
> I'm having a problem with international characters when I send them as the
> request *URI* (which is used by GET requests and this is a GET request).
> 
> Let's say I get the string AOËL
> 
> mod_jk log  logs the bytes with the message
> 
>  "ajp_connection_tcp_send_message::jk_ajp_common.c (1208): sending to ajp13
> pos=4 len=1411 max=8192" (at
> ajp_connection_tcp_send_message::jk_ajp_common.c) shows them to be:
> 
>   41 4f c3 8b 4c
> 
> AFAIK this means the correct bytes are being sent to AJP.  Is that correct?

That is the correct UTF-8 byte encoding for the characters AOËL.


> Running remote debugging via Spring Tool Suite to hook up to my code shows
> me I receive:
> 
> 41 4f c3 c3 83 c2 c2 8b 4c

That is not valid UTF-8. If the UTF-8 bytes had been treated as
ISO-8859-1 and then re-encoded as UTF-8 I'd expect to see:

41 4f c3 83 c2 8b 4c

> I have verified the incorrect bytes appear as early in the call stack as
> when CoyoteAdapter.process() is invoked

I think you need to go a little further up the stack to track this down.

> I have UTF-8 specified as URIEncoding in ajp  and it has had no
> effect.

That is the change I would have expected was required.

> Ive also specified  useBodyEncodingForURI as true with no effect.

That won't help for a GET request.

> Conventional wisdom says the data is getting inadvertently as ISO-8859-1
> somewhere along the line. Since the data is correct (per mod_jk.log)
> heading into AJP and incorrect once CoyoteAdapter.java starts handling it
> somehow, something is going wrong when the data is interpreted after being
> read from the AJP port.
> 
> Is that correct?

It looks to be something like that.

> I am at a loss as to how to correct this.  The only 2 things the docs say
> are to use URIEnocding="UTF-8" and  useBodyEncodingForURI="true".  I'm
> doing that and its not working.
> 
> I am at a loss about what else to try or where to look.
> 
> If you were faced with this, what would you try?  Any advice or suggestions
> will be greatly appreciated.

I'd dig into the connector code. You need to figure out where those
bytes are being transformed and why.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org