Re: Tomcat 5.0.xx migration

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Uzair,

On 2/9/16 1:11 PM, uzair rashid wrote:
> Most of our business is running Tomcat 7.x.xx or later. But, we
> have a business function of ours that is using Tomcat 5.0.xx.
> Unfortunately, this is causing a lot of issues in terms of
> vulnerability remediation.

You should definitely upgrade anything running Tomcat 5.x to something
later. If possible, Tomcat 8.x would be preferable.

> Apache Tomcat Servlet Host Manager Servlet Cross-Site Scripting 
> Vulnerability

Don't deploy the host manager: no vulnerability at any Tomcat level.

> Apache Tomcat Information Disclosure Vulnerability
> 
> Apache Tomcat Accept-Language Cross-Site Scripting Vulnerability

Though unspecified, these will have no workaround I know of.

> Apache Tomcat JavaDoc Spoofing Vulnerability

This is not a vulnerability in Tomcat itself, but the (Javadoc)
documentation. Nobody should really have to worry about this, unless
you host a copy of the javadoc somewhere in your own environment.

> Apache Tomcat 4, 5 and 6 Examples Web Application Multiple
> Cross-Site Scripting Vulnerabilities
> 
> Apache Tomcat 4 and 5 Cross-Site Scripting Vulnerability in
> Calender Application in JSP Examples
> 
> Apache Tomcat 5 Cross-Site Scripting in implicit-objects.jsp of
> "Examples" Application

Don't deploy the examples: no vulnerability at any Tomcat level.

> Apache Tomcat Multiple Content Length Headers Information
> Disclosure Vulnerability

Not sure.

> Apache Tomcat Multiple Cross-Site Scripting Vulnerabilities in
> Manager and Host Manager Web Applications

Don't deploy the host manager. If you need to deploy the manager
application, make sure you secure it and make sure your web-based
users know not to click on emailed links that take them directly into
the manager application.

> Apache Tomcat 4 and 5 Multiple Cross-Site Scripting
> Vulnerabilities

These are usually issues with an application (e.g. Examples) and not
the server.

> The above is what were are experiencing and we are running Crystal
> Report as well.

What does Crystal Reports have to do with anything?

> Could someone please guide me in the most efficient way to
> upgrade?

http://tomcat.apache.org/migration.html

There are no migration guides from 5.0 -> 8.0, but if you read them
all, you'll know what issues you might face.

> My thought process is 5.0.xx to 5.5 then migration to 6 or 7?

There is no particular reason to upgrade each release one at a time.
You can go from 5.x to 8.x all at once.

> We are running windows 2003. I’m not even sure if it will support
> it?

If Java runs on it, Tomcat will run on it (assuming you have enough
memory to run your own application).

> I am unable to find any process documents or guidance on how to go 
> about the upgrade process and which version could help us in 
> vulnerability remediation. Could someone please help me? This is 
> extremely time sensitive to our business needs.

See the migration guide(s) above.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla6MuMACgkQ9CaO5/Lv0PDjNACfXUgItmPkp4yjaC1R1sZB53c3
ONIAoIOIs9ETF5f6R5WXLdwtefPdVrIO
=61j9
-END PGP SIGNATURE-

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

RE: HSTS missing from HTTPS server on tomcat 8.0.27

[dkumar]

Dear Harrie,

We have already implemented the said configuration of filter. 

Still we are unable to implement HSTS. 
This configuration works absolutely fine on tomcat running running on 
windows, but in the case of unix we aren't able to achieve HSTS. 

Below are the steps followed by us:

We have downloaded latest tomcat tar.gz from tomcat website,
Deployed our application on it, 
Made above changes in conf\web.xml and then started tomcat. no error till 
this point. 
When i started VA testing on the server i get below error :
Note: further occurrences of HTTP header parsing errors will be logged at 
DEBUG level.
 java.lang.IllegalArgumentException: Invalid character (CR or LF) found in 
method name
at 
org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:228)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1010)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:674)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)


and then  VA test results show that HSTS is not configured.

Please note that we followed the above steps for tomcat on windows and 
every thing is absolutely fine and even results of VA test don't contain 
HSTS information.
Any  help is greatly appreciated.



From:   "Harrie Robins" 
To: "'Tomcat Users List'" 
Date:   08-02-2016 20:51
Subject:RE: HSTS missing from HTTPS server on tomcat 8.0.27



Hello!

Missing HSTS is not a vulnerability, as Mark pointed out, it is a feature.
In your web.xml

  
httpHeaderSecurity
 
org.apache.catalina.filters.HttpHeaderSecurityFilter

hstsEnabled
true


hstsMaxAgeSeconds
31536000


hstsIncludeSubDomains
true

true


This will NOT activate HSTS for your application, you will need to add 
this
mapping as well (edit to needs and add to application):


httpHeaderSecurity
/*
REQUEST


Regards,

Harrie

-Original Message-
From: dku...@ccilindia.co.in [mailto:dku...@ccilindia.co.in] 
Sent: maandag 8 februari 2016 15:50
To: 'Tomcat Users List' 
Subject: HSTS missing from HTTPS server on tomcat 8.0.27

Hi,

We are unable to fix the vulnerability of "HSTS missing from HTTPS server" 

on apache tomcat  8.0.27 while running on unix operating system. Below is
the system configuration:

 OS Name:   HP-UX
 OS Version:B.11.31
 Architecture:   IA64N
Java Home:/opt/java8/jre
JVM Version:  1.8.0.04-hp-ux-b2
JVM Vendor:   Hewlett-Packard Company

We have uncommented the httpHeaderSecurity in the filter tag of 
conf/web.xml
file, but still the vulnerability exists. We have also tried with apache
tomcat 8.0.30, but in vain.


Any help to fix this vulnerability is appreciated.

Thanks & Regards
Deepak Kumar
"Disclaimer and confidentiality clause -  This message and any attachments
relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES is
proprietary to CCIL and intended for the original addressee only.
The message may contain information that is confidential and subject to
legal privilege. 
Any views expressed in this message are those of the individual sender. 
If you have received this message in error, please notify the original
sender immediately and destroy the message and copies thereof and any
attachments contained in it .
 If you are not the intended recipient of this message, you are hereby
notified that you must not disseminate, copy, use, distribute, or take any
action in connection therewith. 
 CCIL cannot ensure that the integrity of this communication has been
maintained nor that it is free of errors, viruses, interception and/or
interference. 
CCIL is not liable whatsoever for loss or damage resulting from the 
opening
of this message and/or attachments and/or the use of the information
contained in this message and/or attachments."


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



"Disclaimer and confidentiality clause -
 This message and any attachments relating to official business of CCIL OR ANY 
OF IT'S SUBSIDIARIES is proprietary to CCIL and intended for the original 

Re: Having Java websocket server in tomcat handle ISO8859_1

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 2/8/16 6:25 PM, André Warnier (tomcat) wrote:
> On 08.02.2016 23:31, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> All,
>> 
>> On 2/8/16 3:43 PM, Mark Thomas wrote:
>>> On 08/02/2016 18:41, Jason Ricles wrote:
 I have an application that sends binary websocket messages 
 between a class and the web application using a websocket
 server written in java.
 
 The data being sent from the java class is encoded in a
 binary buffer with the bytes in ISO8859_1. However, when I
 receive the bytes on the websocket server and the web
 application end they are junk (such as -121, -116, etc.) and
 not encoded the correct way that they need to be.
>>> 
>>> The bytes are transmitted as unsigned on the wire (as required
>>> by the WebSocket spec). Java handles them as signed. You need
>>> to convert them. Something like (untested):
>>> 
>>> char c = b & 0xFF;
>> 
>> I had to read this something like 10 times before I convinced
>> myself that this was correct. For those who want to know what
>> this makes any kind of sense (because, at first glance, it does
>> not make any sense), I'll explain it.
>> 
>> For starters, Java uses signed byte primitives but /unsigned/
>> char primitives. For those coming from the C world, that may be
>> confusing. bytes are 8 (signed) bits and chars are 16 (unsigned)
>> bits.
>> 
>> But Java doesn't have any defined arithmetic operations
>> (including bitwise) for anything smaller than an int (32 signed
>> bytes), so the above assignment is actually more like this:
>> 
>> byte b = 0xab; // e.g. char c = (char)  ( ((int)b) & 0xff
>> )
>> 
>> So, first b is widened from 8 bits to 32 bits -- with a 
>> sign-extension. That means that -1 is still -1, it's just
>> represented by a different bit pattern:     
>>    instead of  .
>> 
>> Next, the bitwise && is performed, which zeros-out everything but
>> the bottom 8-bits (now we have      ).
>> Then, that value is cast to char which does practically nothing.
>> 
>> In the above example (-1), we get a final value of 255 for c,
>> which is exactly what you'd expect for an unsigned char whose
>> signed value is -1.
>> 
>> I think the only surprise thing there is that Java widens all
>> types to 32-bit signed int to perform these operations. Without
>> that fact, the above assignment doesn't make much sense. In C,
>> that line of code would do absolutely nothing at all.
>> 
> 
> Would a simpler way to say this not be that in Java, a char is a
> 16-bit integer whose value happens to be the corresponding
> character's Unicode codepoint ?

If you want to be pedantic (and I know you do!), a Java character is a
subset of Unicode codepoints. Unicode specifies more than 2^16
codepoints (or, at least, the range exceeds what 2^16 addresses
covers). If you want to use actual Unicode codepoints, you need to use
Java int -- which is why String.codePointAt returns int and not char.

> Of course his all takes us further away from the OP's original 
> description of the issue, which said "The data being sent from the
> java class is encoded in a binary buffer with the bytes in
> ISO8859_1." Which basically doesn't make sense, unless the data in
> question is originallly text.

Of course it makes no sense at all. Binary is binary and character
encoding is a property of text. Perhaps what he meant was that it
wasn't XML or some fancy Web 2.0 thingy. But of course, he's using
Websocket which is, by definition, Web 2.0. Welcome to the new binary!
Text-encoding of binary data across a text-based channel. Or something
like that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla58lQACgkQ9CaO5/Lv0PC+lACgo1yaNVCR0irOrk5hUSw3iury
+BIAoLQElOEZylktC5u8ZIo5GaurP855
=a2zc
-END PGP SIGNATURE-

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

Re: FW: [PossibleSpam] Re: Tomcat Rewrite Valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

On 2/9/16 9:18 AM, Joe Aldrich wrote:
> This is my first attempt at interaction with the Tomcat Users List.
>  I haven't heard anything back on my response to the initial
> followup by Chris, and I was just checking if there was anything
> else needed from me on this.

I was waiting to see if someone else with more familiarity with the
rewrite valve would speak up. I don't have time to dive into that code
right now, unfortunately.

- -chris

> -Original Message- From: Joe Aldrich Sent: Friday, January
> 29, 2016 5:07 PM To: Tomcat Users List Subject: RE: [PossibleSpam]
> Re: Tomcat Rewrite Valve
> 
> Hello,
> 
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> 
> Joe,
> 
>> On 1/29/16 9:34 AM, Joe Aldrich wrote:
>>> I am using Tomcat 8.0.28 on Windows 10 and am having a problem
>>> with the Rewrite Value. I must include the escaped form of an
>>> ampersand '%26' in the output URL.
>>> 
>>> My rewrite.config has the following:
>>> 
>>> RewriteCond %{QUERY_STRING} ^(.*&)?SCID=8(&.*)?$ RewriteRule 
>>> ^/(product|specs|avail-options|avail-category)\.php$ 
>>> /Product.action?select=Model+4+\%26+4C [R=301,L,NE]
>>> 
>>> I am escaping the percent sign with a backslash, and I have
>>> tried using the NE flag. However, Tomcat always is treating the
>>> percent symbol as a back reference to the above RewriteCond. If
>>> I don't have a second capture group, then I get a 500 error
>>> from a NullPointerException.
> 
>> Can you please post the stack trace from that?
> 
> Here is what I get if I don’t specify a second capture group:
> 
> HTTP Status 500 - No group 2
> 
> type Exception report
> 
> message No group 2
> 
> description The server encountered an internal error that prevented
> it from fulfilling this request.
> 
> exception
> 
> java.lang.IndexOutOfBoundsException: No group 2 
> java.util.regex.Matcher.group(Unknown Source) 
> org.apache.catalina.valves.rewrite.Substitution$RewriteCondBackReferen
ceElement.evaluate(Substitution.java:51)
>
> 
org.apache.catalina.valves.rewrite.Substitution.evaluate(Substitution.ja
va:238)
> org.apache.catalina.valves.rewrite.RewriteRule.evaluate(RewriteRule.ja
va:133)
>
> 
org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java
:292)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
va:79)
>
> 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessL
ogValve.java:616)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
:518)
>
> 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11P
rocessor.java:1091)
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A
bstractProtocol.java:673)
>
> 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint
.java:1500)
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint
.java:1456)
>
> 
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
ead.java:61)
>
> 
java.lang.Thread.run(Unknown Source)
> note The full stack trace of the root cause is available in the
> Apache Tomcat/8.0.28 logs.
> 
> Apache Tomcat/8.0.28
> 
>>> I was working with the documentation on this page:
>>> 
>>> http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
>>> 
>>> The desired output URL would be:
>>> 
>>> http://www.domain.com/Product.html?select=Model+4+%26+4C
> 
>> Presumably, if you don't escape it at all, you get:
>> 
>> http://www.domain.com/Product.html?select=Model+4+%2526+4C
>> 
>> ?
> 
> If I do not use the backslash to escape the percent sign, then
> (with or without the [NE] flag) I get a back-reference resulting in
> a 500 error if there isn't a second capture group. If there is a
> second capture group I get:
> 
> http://www.domain.com/Product.html?select=Model+4+null26+4C
> 
> (where again, null represents there was nothing specified after the
> SCID=8 in the query string).
> 
> If I omit the [NE] flag and keep the backslash to escape the
> percent sign, the escaping of the percent sign fails and I get
> similar results except for the presence of the backslash in the
> output URL as:
> 
> http://www.domain.com/Product.html?select=Model+4+\null26+4C
> 
> 
>>> In the example given for the NE flag on the page reference
>>> above, the percent sign is escaped by a backslash to prevent it
>>> from being treated as a back-reference. This is not working for
>>> me. Instead I get:
>>> 
>>> http://www.domain.com/Product.action?select=Model+4+\null6+4C
>>> 
>>> Where the "null" is due to an empty second back-reference.  I
>>> believe this is a bug in that it is not escaping the percent
>>> sign (making it impossible to create the %26 in the redirect
>>> URL). Or am I misunderstanding something here?
>>> 
>>> As a side question, shouldn't an empty back-reference be blank
>>>  instead of adding 'null' 

FW: [PossibleSpam] Re: Tomcat Rewrite Valve

[Joe Aldrich]

Hello,

This is my first attempt at interaction with the Tomcat Users List. I haven't 
heard anything back on my response to the initial followup by Chris, and I was 
just checking if there was anything else needed from me on this.

Thanks,
Joe

-Original Message-
From: Joe Aldrich 
Sent: Friday, January 29, 2016 5:07 PM
To: Tomcat Users List
Subject: RE: [PossibleSpam] Re: Tomcat Rewrite Valve

Hello,

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe,

>On 1/29/16 9:34 AM, Joe Aldrich wrote:
>> I am using Tomcat 8.0.28 on Windows 10 and am having a problem with 
>> the Rewrite Value. I must include the escaped form of an ampersand 
>> '%26' in the output URL.
>> 
>> My rewrite.config has the following:
>> 
>> RewriteCond %{QUERY_STRING} ^(.*&)?SCID=8(&.*)?$ RewriteRule 
>> ^/(product|specs|avail-options|avail-category)\.php$
>> /Product.action?select=Model+4+\%26+4C [R=301,L,NE]
>> 
>> I am escaping the percent sign with a backslash, and I have tried 
>> using the NE flag. However, Tomcat always is treating the percent 
>> symbol as a back reference to the above RewriteCond. If I don't have 
>> a second capture group, then I get a 500 error from a 
>> NullPointerException.

>Can you please post the stack trace from that?

Here is what I get if I don’t specify a second capture group:

HTTP Status 500 - No group 2

type Exception report

message No group 2

description The server encountered an internal error that prevented it from 
fulfilling this request.

exception

java.lang.IndexOutOfBoundsException: No group 2
java.util.regex.Matcher.group(Unknown Source)

org.apache.catalina.valves.rewrite.Substitution$RewriteCondBackReferenceElement.evaluate(Substitution.java:51)

org.apache.catalina.valves.rewrite.Substitution.evaluate(Substitution.java:238)

org.apache.catalina.valves.rewrite.RewriteRule.evaluate(RewriteRule.java:133)

org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java:292)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)

org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)

org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)

org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)

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

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1500)

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1456)
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Unknown Source)
note The full stack trace of the root cause is available in the Apache 
Tomcat/8.0.28 logs.

Apache Tomcat/8.0.28

>> I was working with the documentation on this page:
>> 
>> http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
>> 
>> The desired output URL would be:
>> 
>> http://www.domain.com/Product.html?select=Model+4+%26+4C

>Presumably, if you don't escape it at all, you get:
>
>http://www.domain.com/Product.html?select=Model+4+%2526+4C
>
>?

If I do not use the backslash to escape the percent sign, then (with or without 
the [NE] flag) I get a back-reference resulting in a 500 error if there isn't a 
second capture group. If there is a second capture group I get:

http://www.domain.com/Product.html?select=Model+4+null26+4C

(where again, null represents there was nothing specified after the SCID=8 in 
the query string).

If I omit the [NE] flag and keep the backslash to escape the percent sign, the 
escaping of the percent sign fails and I get similar results except for the 
presence of the backslash in the output URL as:

http://www.domain.com/Product.html?select=Model+4+\null26+4C


>> In the example given for the NE flag on the page reference above, the 
>> percent sign is escaped by a backslash to prevent it from being 
>> treated as a back-reference. This is not working for me. Instead I
>> get:
>> 
>> http://www.domain.com/Product.action?select=Model+4+\null6+4C
>> 
>> Where the "null" is due to an empty second back-reference.  I believe 
>> this is a bug in that it is not escaping the percent sign (making it 
>> impossible to create the %26 in the redirect URL). Or am I 
>> misunderstanding something here?
>> 
>> As a side question, shouldn't an empty back-reference be blank 
>> instead of adding 'null' to the URL?

>I agree that the "null" is incorrect. That is almost certainly a bug.
>
>[NE] should be preventing escaping of the resulting URL, but that might break 
>if you had user-specified input being re-written, but then not escaped.
>
>I'm not entirely sure if backslash-escaping is expected to work for 

Re: Having Java websocket server in tomcat handle ISO8859_1

[tomcat]

On 09.02.2016 15:06, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 2/8/16 6:25 PM, André Warnier (tomcat) wrote:

On 08.02.2016 23:31, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1

All,

On 2/8/16 3:43 PM, Mark Thomas wrote:

On 08/02/2016 18:41, Jason Ricles wrote:

I have an application that sends binary websocket messages
between a class and the web application using a websocket
server written in java.

The data being sent from the java class is encoded in a
binary buffer with the bytes in ISO8859_1. However, when I
receive the bytes on the websocket server and the web
application end they are junk (such as -121, -116, etc.) and
not encoded the correct way that they need to be.


The bytes are transmitted as unsigned on the wire (as required
by the WebSocket spec). Java handles them as signed. You need
to convert them. Something like (untested):

char c = b & 0xFF;


I had to read this something like 10 times before I convinced
myself that this was correct. For those who want to know what
this makes any kind of sense (because, at first glance, it does
not make any sense), I'll explain it.

For starters, Java uses signed byte primitives but /unsigned/
char primitives. For those coming from the C world, that may be
confusing. bytes are 8 (signed) bits and chars are 16 (unsigned)
bits.

But Java doesn't have any defined arithmetic operations
(including bitwise) for anything smaller than an int (32 signed
bytes), so the above assignment is actually more like this:

byte b = 0xab; // e.g. char c = (char)  ( ((int)b) & 0xff
)

So, first b is widened from 8 bits to 32 bits -- with a
sign-extension. That means that -1 is still -1, it's just
represented by a different bit pattern:     
   instead of  .

Next, the bitwise && is performed, which zeros-out everything but
the bottom 8-bits (now we have      ).
Then, that value is cast to char which does practically nothing.

In the above example (-1), we get a final value of 255 for c,
which is exactly what you'd expect for an unsigned char whose
signed value is -1.

I think the only surprise thing there is that Java widens all
types to 32-bit signed int to perform these operations. Without
that fact, the above assignment doesn't make much sense. In C,
that line of code would do absolutely nothing at all.



Would a simpler way to say this not be that in Java, a char is a
16-bit integer whose value happens to be the corresponding
character's Unicode codepoint ?


If you want to be pedantic (and I know you do!),


this time I hesitated..

 a Java character is a

subset of Unicode codepoints. Unicode specifies more than 2^16
codepoints (or, at least, the range exceeds what 2^16 addresses
covers). If you want to use actual Unicode codepoints, you need to use
Java int -- which is why String.codePointAt returns int and not char.



Well, I was planning to add a proviso about Unicode characters that were not part of the 
Basic Multilingual Plane (and thus with Codepoints above 2exp16-1), but I figured that the 
matter was already confusing enough.

I found a old but good article about this topic :
http://www.javaworld.com/article/2076571/java-se/an-in-depth-look-at-java-s-character-type.html
And this must be the bible :
https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html


Of course his all takes us further away from the OP's original
description of the issue, which said "The data being sent from the
java class is encoded in a binary buffer with the bytes in
ISO8859_1." Which basically doesn't make sense, unless the data in
question is originallly text.


Of course it makes no sense at all. Binary is binary and character
encoding is a property of text. Perhaps what he meant was that it
wasn't XML or some fancy Web 2.0 thingy. But of course, he's using
Websocket which is, by definition, Web 2.0. Welcome to the new binary!
Text-encoding of binary data across a text-based channel. Or something
like that.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla58lQACgkQ9CaO5/Lv0PC+lACgo1yaNVCR0irOrk5hUSw3iury
+BIAoLQElOEZylktC5u8ZIo5GaurP855
=a2zc
-END PGP SIGNATURE-

-
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 6 | Tomcat with APR causing Thread Blocking

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ravi,

On 2/9/16 7:10 AM, Ranjan, Ravi wrote:
> HI Chris,
> 
> Sorry for a delayed response. Here is few information that you
> asked for: 1. Tomcat Native Library version is 1.1.30 and APR
> version is 1.4.8 2.   I am running my tomcat 6.0.41 on Windows 7
> system with Java 7.
> 
> As you said that if APR is not available the Java BIO (blocking
> I/O) connector will be used. For me this connector is working. I am
> still not able to pinpoint to exact difference between these two
> types of connectors, which might be causing/solving the issue.
> 
> Here is the thread dump for the stuck thread:
> 
> "http-8080-2" - Thread t@55 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
> java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at
> java.io.BufferedInputStream.read(BufferedInputStream.java:254) -
> locked <1559b4d1> (a java.io.BufferedInputStream) at
> org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:7
7)

This
> 
stack trace was taken on the server, not the client, right?

If so, this has nothing whatsoever to do with Tomcat. This is a
problem with your web application making a connection to an outside
service that is taking a long time to respond.

Set your timeouts appropriately and you won't have this stuck thread
anymore. But you will have to handle error situations, of course.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla588EACgkQ9CaO5/Lv0PBRGQCfR9Loo2m5rvQSmva7BYTar7JQ
8fUAn1uKghqYKTjbKE99ahnxGtlTaWza
=Vip6
-END PGP SIGNATURE-

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

Re: HSTS missing from HTTPS server on tomcat 8.0.27

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Deepak,

On 2/9/16 6:28 AM, dku...@ccilindia.co.in wrote:
> Dear Harrie,
> 
> We have already implemented the said configuration of filter.
> 
> Still we are unable to implement HSTS. This configuration works
> absolutely fine on tomcat running running on windows, but in the
> case of unix we aren't able to achieve HSTS.
> 
> Below are the steps followed by us:
> 
> We have downloaded latest tomcat tar.gz from tomcat website, 
> Deployed our application on it, Made above changes in conf\web.xml
> and then started tomcat. no error till this point. When i started
> VA testing on the server i get below error : Note: further
> occurrences of HTTP header parsing errors will be logged at DEBUG
> level. java.lang.IllegalArgumentException: Invalid character (CR or
> LF) found in method name at 
> org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(Abstr
actNioInputBuffer.java:228)
>
> 
at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp1
1Processor.java:1010)
>
> 
at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(A
bstractProtocol.java:674)
>
> 
at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoi
nt.java:1500)
>
> 
at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint
.java:1456)
>
> 
at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
ava:1142)
>
> 
at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
java:617)
>
> 
at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThr
ead.java:61)
>
> 
at java.lang.Thread.run(Thread.java:745)
> 
> 
> and then  VA test results show that HSTS is not configured.

It looks like "VA test" has a broken client: it's not issuing a valid
HTTP request.

> Please note that we followed the above steps for tomcat on windows
> and every thing is absolutely fine and even results of VA test
> don't contain HSTS information. Any  help is greatly appreciated.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla5810ACgkQ9CaO5/Lv0PATwACgmXpTJ6AmI1USQqQDm42s13we
W1gAniTXh/dufrGmkM5/pJ2GnNu6divo
=50QF
-END PGP SIGNATURE-

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

Re: Stuck thread when invoking the AsyncContext.complete() method

[Jeroen van Ooststroom]

On 05/02/16 13:46, Jeroen van Ooststroom wrote:

On 05/02/16 12:05, Mark Thomas wrote:

On 05/02/2016 09:00, Mark Thomas wrote:

On 05/02/2016 00:30, Jeroen van Ooststroom wrote:

Hello,

Using Tomcat 8.0.23 and Tomcat 8.0.30 with Java 1.7.0_25 on CentOS 
5.11
we are getting a stuck thread issue when our server is on high(er) 
load.

It seems to happen when one of our non-Container Threads invokes the
AsyncContext.complete() method while the AsyncStateMachine class’ 
state

class member is set to STARTING instead of STARTED, resulting in the
invocation of the Object’s wait() method in the
pauseNonContainerThread() method. It never seems to recover from this.

I tried a couple of things within our source code trying to get around
this:

1. If HttpServletRequest.isAsyncStarted() returns true invoke
AsyncContext.complete(), but if it returns false

That should not be possible. And I think I have figured out what the
problem is. Let me explain.

The expected sequence of processing is:

0) Servlet.service() -> entry
1) Servlet.service() -> call startAsync()
2) Servlet.service() -> start a non-container thread to do some
processing
3) Servlet.service() -> exits
4) non-container thread calls complete()

Each connection has a dedicated async state machine that tracks the
current state of the connection.

At point 0 the state machine is in the state DISPATCHED (a.k.a. not 
async)

At point 1 the state machine transitions to STARTING.
At point 3 the state machine transitions to STARTED.
At point 4 the state machine transitions to COMPLETING, a container
thread is assigned which fires the onComplete() event for any listeners
and then changes state to DISPATCHED.

The point of the waits is to ensure that step 4) always occurs after
step 3). If a non-container thread is paused, the aynsc post-processing
code for container threads will unpause the thread once it completes.

If a non-container thread calls complete() at an inappropriate time 
then

an IllegalStateExcpetion should be thrown.

The problem is that the non-container thread is paused before the check
for the illegal state is made. Therefore, in the case where the
non-container thread is making a call at an inappropriate time, it is
paused and will never be unpaused. We need to check the state is valid
before pausing the thread.

Drat. This is already checked and I missed it when reviewing the code.

That narrows the possible causes down to:
- The container thread never exits the Servlet.service() method. A
thread dump will confirm or eliminate that possibility.
- The container thread experiences an error which causes it not to
unpause the non-container thread. I've been over the code several times
and short of an OOME, ThreadDeath or similar error I don't see how this
could happen.

It would be worth checking the logs before the point where this problem
occurs for any errors.

I'm going to review the code again to see if I can see any other
potential problems.

One option is to refactor the pause method and check periodically if the
thread should still be paused. It might be worth adding some debug
logging to get a better idea of what is going on when this issue occurs.

Mark


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

I can provide you with the logs. What Tomcat-level log settings do you 
want me to use? I can also provide you with the thread dump upon the 
thread being stuck. I can also try to get an isolated test case that 
is able to reproduce the issue, but it will take some time.


Regards,
Jeroen...

Hello Mark,

I have been trying to get an isolated test case reproducing the issue, 
but so far without luck. I'll try to reproduce it again with the 
original application and get a thread dump for you at the time it got 
stuck. Is there any Tomcat-level logging you want to see as well leading 
up to the stuck thread issue?


Thanks,
Jeroen...

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

Re: HSTS missing from HTTPS server on tomcat 8.0.27

[Olaf Kock]

Am 09.02.2016 um 15:10 schrieb Christopher Schultz:
> On 2/9/16 6:28 AM, dku...@ccilindia.co.in wrote:
>
> > and then  VA test results show that HSTS is not configured.
>
> It looks like "VA test" has a broken client: it's not issuing a valid
> HTTP request.

Just to make sure it's not the most obvious things that we're missing here:

HSTS headers /only/ make sense on HTTPS connections, never on HTTP
connections. Also, they'll only work when using the default ports 80 and
443, as any HSTS-redirect will happily rewrite access to
http://www.example.com:8080/ to https://www.example.com:8080/ - and this
might easily result in protocol errors as you now no longer "speak" HTTP
on port 8080, but HTTPS.

Please confirm that
* You're running on ports 80 and 443
* You're expecting the HSTS header purely on https connections
* You're not using ports 8080 and 8443 or any other non-80 and non-443 port

Olaf


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

RE: Tomcat 6 | Tomcat with APR causing Thread Blocking

[Ranjan, Ravi]

HI Chris,

Sorry for a delayed response.
Here is few information that you asked for:
1.  Tomcat Native Library version is 1.1.30 and APR version is 1.4.8
2.  I am running my tomcat 6.0.41 on Windows 7 system with Java 7.

As you said that if APR is not available the Java BIO (blocking I/O) connector 
will be used. For me this connector is working.
I am still not able to pinpoint to exact difference between these two types of 
connectors, which might be causing/solving the issue. 

Here is the thread dump for the stuck thread:

"http-8080-2" - Thread t@55
   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 java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
- locked <1559b4d1> (a java.io.BufferedInputStream)
at 
org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:77)
at 
org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:105)
at 
org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1118)
at 
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager.java:1373)
at 
org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1832)
at 
org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1590)
at 
org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:397)
at 
org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
at 
org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
at 
org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:364)
at 
org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at 
org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at 
org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at 
org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:75)
at org.codehaus.xfire.client.Client.invoke(Client.java:335)
at 
org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at com.sun.proxy.$Proxy62.query(Unknown Source)
at 
com..XXX.web.services.client.XX.sendMessageToServer(XXX.java:53)
.
.
.

Thanks,
Ravi Ranjan

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Saturday, February 06, 2016 4:18 AM
To: Tomcat Users List
Subject: Re: Tomcat 6 | Tomcat with APR causing Thread Blocking

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ravi,

On 2/4/16 2:15 AM, Ranjan, Ravi wrote:
> I am new to this user list and this is the first email I am sending 
> out to you. Hope you will let me know if more 
> information/logs/dump/test case/clarity is required.

Welcome.

> So I am working with Tomcat 6.0.41 (both 64bit and 32 bit). In my 
> Tomcat environment I am using APR (Apache Portable
> Runtime)Listener: (by configuring 
> below property in server.xml)  className="org.apache.catalina.core.AprLifecycleListener"
> SSLEngine="on" />

So far, so good. The only think you didn't mention was the versions of APR and 
tcnative you were using, and your OS.

> I am using below connector, which i assume is a blocking type: 
>  connectionTimeout="2"  redirectPort="8443" />

If you have APR available, then that configuration will give you the APR 
connector. If APR is not available, you'll get the Java BIO (blocking I/O) 
connector.

> In one of my webapp i am running a dll as a Java Process to validate 
> some data. This dll is accessed as a Process whenever is required. I 
> have separate Thread to terminate this Process if not used for few 
> minutes.

(DLL: So this is Microsoft Windows?)

> Now i am facing a weired issue where with Apache Tomcat 6.0.43 (both 
> 64 and 32 bit), the http thread that has started this process gets 
> stuck. From thread dump i get this stack trace:
> 
> "http-8080-2" - Thread t@55 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
> java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at
> 

RE: Relative redirects in light of recent changes

[George Stanchev]

> However, with useRelativeRedirects="false" I see
> 
> GET http://hostname/myapp?m=n=p 
>   ==> 302: "http://hostname/login?a=b=d;
> 
> The questions I have are 2: First, what happened with the trailing slash 
> redirect. I vaguely remember discussions around it but I couldn't find them 
> on the mailing list search index. And secondly but more importantly, in 
> 7.0.64, the HttpServletRequest.sendRedirect() would use the application name 
> to form the Location header value (as in .../myapp/login...) whereas in 
> 7.0.67 the name of the application is missing from the absolute redirect.
> 
> Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

Setting mapperContextRootRedirectEnabled="true" on the Context should fix it.

Mark


Thanks Mark. So if I understand correctly, 7.0.68 will return to adding the 
trailing slash automatically just like 7.0.64 did. That for now can be worked 
around by setting that attribute above on the context for now.

With the trailing slash optional though, the code in 
"org.apache.catalina.connector.Response#toAbsolute(String)" still seems will 
yield wrong redirect URLs for the case where someone is running with trailing 
slash redirect disabled:

String relativePath = request.getDecodedRequestURI();
int pos = relativePath.lastIndexOf('/');
...
} else {
encodedURI = urlEncoder.encodeURL(relativePath, 0, pos);
}

In case of relativePath being "/myapp" (which will be the case when somone runs 
with traliling-slash-redirect being turned off), encodedURI will be "".

So it seems to me either TC should *always* force those 
trailing-slash-redirects or fix the code above to correctly calculate the 
encodedURI from the relativePath...

George

Tomcat 5.0.xx migration

[uzair rashid]

Hello Experts:



Most of our business is running Tomcat 7.x.xx or later. But, we have a
business function of ours that is using Tomcat 5.0.xx. Unfortunately, this
is causing a lot of issues in terms of vulnerability remediation.



Apache Tomcat Servlet Host Manager Servlet Cross-Site Scripting
Vulnerability

Apache Tomcat Information Disclosure Vulnerability

Apache Tomcat Accept-Language Cross-Site Scripting Vulnerability

Apache Tomcat JavaDoc Spoofing Vulnerability

Apache Tomcat 4, 5 and 6 Examples Web Application Multiple Cross-Site
Scripting Vulnerabilities

Apache Tomcat 4 and 5 Cross-Site Scripting Vulnerability in Calender
Application in JSP Examples

Apache Tomcat 5 Cross-Site Scripting in implicit-objects.jsp of "Examples"
Application

Apache Tomcat Multiple Content Length Headers Information Disclosure
Vulnerability

Apache Tomcat Multiple Cross-Site Scripting Vulnerabilities in Manager and
Host Manager Web Applications

Apache Tomcat 4 and 5 Multiple Cross-Site Scripting Vulnerabilities





The above is what were are experiencing and we are running Crystal Report
as well.



Could someone please guide me in the most efficient way to upgrade?



My thought process is 5.0.xx to 5.5 then migration to 6 or 7? We are
running windows 2003. I’m not even sure if it will support it? I am unable
to find any process documents or guidance on how to go about the upgrade
process and which version could help us in vulnerability remediation. Could
someone please help me? This is extremely time sensitive to our business
needs.



Cheers!

Using MANIFEST.MF in Tomcat 8

[Andy Smith]

Hi,
I am currently running Tomcat 8.0.30 on a Red Hat Linux 64 bit O/S (2.6.18). My 
question is, I hope, simple. I want to tell Tomcat to look in a child directory 
of the WEB-INF/lib directory for jar files that contain classes my web app 
requires. For example, I have four main jar files that reside in the 
WEB-INF/lib directory. Under the WEB-INF/lib directory I have a directory that 
contains jar files that support one or more of the main jar files. However no 
matter what I put in the MANIFEST.MF file the jar files in the child 
directories are not located. Here is what I currently have in my 
META-INF/MANIFEST.MF file for the web app context. I only have one library(jar 
file) at this point because I was trying to limit the variables and this is the 
jar file that contains the class that can not be located.
Manifest-Version: 1.0Class-Path: libraries/commons-fileupload-1.2.2.jar
I have also tried the KV Pair,  Dependencies: 
libraries/commons-fileupload-1.2.2.jar.
When I looked at the Tomcat 8 source code, I believe it is trying to read the 
MANIFEST.MF file. So my question is, can I use the MANIFEST.MF file to tell 
Tomcat to look in child directories of the web app context or am I limited to 
the WEB-INF/lib directory only for supporting jar files?
Regards,
Andy Smith

Tomcat feature request

[Jason Ricles]

Is there any formal forum to make a feature request for tomcat?

I noticed I was having a silent failure with a binary websocket with tomcat
since I didn't flip the bytebuffer from write to read and the send kept
failing down at the low level of the code without any error being thrown.
With that in mind, I was thinking it would be useful to explicitly throw
that an error happened since I spent 1.5 days to debug that when I changed
the code I just forgot to flip the bytebuffer and had no excpetion being
thrown, it would thus be very helpful for debugging purposes.

Re: Using MANIFEST.MF in Tomcat 8

[Mark Thomas]

On 9 February 2016 23:44:09 GMT+00:00, Andy Smith 
 wrote:
>Hi,
>I am currently running Tomcat 8.0.30 on a Red Hat Linux 64 bit O/S
>(2.6.18). My question is, I hope, simple. I want to tell Tomcat to look
>in a child directory of the WEB-INF/lib directory for jar files that
>contain classes my web app requires. For example, I have four main jar
>files that reside in the WEB-INF/lib directory. Under the WEB-INF/lib
>directory I have a directory that contains jar files that support one
>or more of the main jar files. However no matter what I put in the
>MANIFEST.MF file the jar files in the child directories are not
>located. Here is what I currently have in my META-INF/MANIFEST.MF file
>for the web app context. I only have one library(jar file) at this
>point because I was trying to limit the variables and this is the jar
>file that contains the class that can not be located.
>Manifest-Version: 1.0Class-Path: libraries/commons-fileupload-1.2.2.jar
>I have also tried the KV Pair,  Dependencies:
>libraries/commons-fileupload-1.2.2.jar.
>When I looked at the Tomcat 8 source code, I believe it is trying to
>read the MANIFEST.MF file. So my question is, can I use the MANIFEST.MF
>file to tell Tomcat to look in child directories of the web app context
>or am I limited to the aWEB-INF/lib directory only for supporting jar
>files?

As per the Servlet specification, Tomcat only looks in WEB-INF/lib for JAR 
files packaged with a web application.

You could use the new (in Tomcat 8) resources implementation to map other files 
(i.e. JARS) into WEB-INF/lib but I'd suggest that it is easier to change the 
build process to put all the JARs in the right place.

Mark



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

RE: Tomcat 6 | Tomcat with APR causing Thread Blocking

[Ranjan, Ravi]

Chris,

Yes the stack trace was taken on server. 
Anyway thanks for your valuable replies, I will continue my research in this 
direction. Since tomcat is out of picture now, I will concentrate on my 
external Process or any redesign that might be required. I will share my 
findings, if hopefully I am able to crack this one.

Regards,
Ravi Ranjan 

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, February 09, 2016 7:42 PM
To: Tomcat Users List
Subject: Re: Tomcat 6 | Tomcat with APR causing Thread Blocking

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ravi,

On 2/9/16 7:10 AM, Ranjan, Ravi wrote:
> HI Chris,
> 
> Sorry for a delayed response. Here is few information that you
> asked for: 1. Tomcat Native Library version is 1.1.30 and APR
> version is 1.4.8 2.   I am running my tomcat 6.0.41 on Windows 7
> system with Java 7.
> 
> As you said that if APR is not available the Java BIO (blocking
> I/O) connector will be used. For me this connector is working. I am 
> still not able to pinpoint to exact difference between these two types 
> of connectors, which might be causing/solving the issue.
> 
> Here is the thread dump for the stuck thread:
> 
> "http-8080-2" - Thread t@55 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
> java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at
> java.io.BufferedInputStream.read(BufferedInputStream.java:254) - 
> locked <1559b4d1> (a java.io.BufferedInputStream) at
> org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:7
7)

This
> 
stack trace was taken on the server, not the client, right?

If so, this has nothing whatsoever to do with Tomcat. This is a problem with 
your web application making a connection to an outside service that is taking a 
long time to respond.

Set your timeouts appropriately and you won't have this stuck thread anymore. 
But you will have to handle error situations, of course.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla588EACgkQ9CaO5/Lv0PBRGQCfR9Loo2m5rvQSmva7BYTar7JQ
8fUAn1uKghqYKTjbKE99ahnxGtlTaWza
=Vip6
-END PGP SIGNATURE-

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


_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.

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

Re: Tomcat feature request

[Mark Thomas]

On 10 February 2016 02:40:20 GMT+00:00, Jason Ricles  
wrote:
>Is there any formal forum to make a feature request for tomcat?

https://bz.apache.org/bugzilla

Mark

>
>I noticed I was having a silent failure with a binary websocket with
>tomcat
>since I didn't flip the bytebuffer from write to read and the send kept
>failing down at the low level of the code without any error being
>thrown.
>With that in mind, I was thinking it would be useful to explicitly
>throw
>that an error happened since I spent 1.5 days to debug that when I
>changed
>the code I just forgot to flip the bytebuffer and had no excpetion
>being
>thrown, it would thus be very helpful for debugging purposes.



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