A fatal error has been detected by the Java Runtime Environment libjvm

[Vijay Kumar]

Hi Team,

We have a web application installed in Tomcat 7.0.47. This was working fine
till last week but suddenly its failing due to Java Fatal error as
specified below.

Could any one please suggest how to know the root cause for this issue.
Attached the log for reference.

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x2ab58b1e5ef1, pid=26026, tid=1108834624
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build
1.7.0_45-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode
linux-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.so+0x7e4ef1]  Node::rematerialize() const+0x1
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

Thanks,
Vijay G

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

[SECURITY] CVE-2016-8747 Apache Tomcat Information Disclosure

[Mark Thomas]

CVE-2016-8747 Apache Tomcat Information Disclosure

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0.M11 to 9.0.0.M15
Apache Tomcat 8.5.7 to 8.5.9

Description
The refactoring to make wider use of ByteBuffer introduced a regression
that could cause information to leak between requests on the same
connection. When running behind a reverse proxy, this could result in
information leakage between users. All HTTP connector variants are
affected but HTTP/2 and AJP are not affected.

Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.0.M17 or later
  (Apache Tomcat 9.0.0.M16 has the fix but was not released)
- Upgrade to Apache Tomcat 8.5.11 or later
  (Apache Tomcat 8.5.10 has the fix but was not released)
Earlier versions are not affected

Credit:
This issue was identified by the Tomcat security team.

History:
2017-03-13 Original advisory

References:
[1] http://tomcat.apache.org/security-9.html
[2] http://tomcat.apache.org/security-8.html

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

Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

[Mark Thomas]

On 13/03/17 15:23, Chandrashekar H.S wrote:
> Hi All,
> We have recently upgraded tomcat from 8.0.30 to 8.5.11.
> 
> The tomcat 8.5.11 rejects the requested URI with below error.
> Requested URI: 
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name="oma_pocbuddylist"]/entry[@uri="tel:+919742700996"]

There are multiple potential problems:
- '+' is often used to encode ' ' so the telephone number may end up
  with a leading ' ' rather than a leading '+'
- '[' and ']' should be encoded but - for now - Tomcat will let you get
  away without encoding them
- '"' must be encoded and Tomcat will no longer accept it in unencoded
  form due to CVE-2016-6816.

So '"' is your immediate problem and I don't see Tomcat optionally
allowing '"' due to the risk of different servers handling it different
ways creating the possibility request / response injection.

> The server accepts the request if the DQUOTE(") is replaced with text %22 as 
> mentioned below
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name=%22oma_pocbuddylist%22]/entry[@uri=%22tel:+
>  919742700996%22]

Note that you really need to encode '+', '[' and ']' as well.

> Please help me to fix this at the server side, since the client or URI 
> requester is already in production/field.

The best solution is to fix the non-spec compliance in the client. As an
interim solution if you can find a lenient reverse proxy (generally all
HTTP servers are getting stricter over time so any solution you find may
only be temporary) then you should be able to fix the URL in the reverse
proxy before it is passed to Tomcat.

Patching Tomcat locally is another option but going that route needs
very careful consideration of the risks.

Mark


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

Re: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

[Mark Eggers]

First of all, sorry for the wrapping. Hint - turn on message wrapping
when writing to the mailing list.

Anyway, responses are at the end.

On 3/13/2017 8:23 AM, Chandrashekar H.S wrote:
> Hi All,
> We have recently upgraded tomcat from 8.0.30 to 8.5.11.
> 
> The tomcat 8.5.11 rejects the requested URI with below error.
> Requested URI: 
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name="oma_pocbuddylist"]/entry[@uri="tel:+919742700996"]
> 
> Mar 13, 2017 5:05:20 PM org.apache.coyote.http11.Http11Processor service
> INFO: Error parsing HTTP request header
> Note: further occurrences of HTTP header parsing errors will be logged at 
> DEBUG level.
> java.lang.IllegalArgumentException: Invalid character found in the request 
> target. The valid characters are defined in RFC 7230 and RFC 3986
>at 
> org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:471)
> at 
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667)
> at 
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> at 
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
> at 
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
> at 
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> 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)
> 
> The server accepts the request if the DQUOTE(") is replaced with text %22 as 
> mentioned below
> /poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name=%22oma_pocbuddylist%22]/entry[@uri=%22tel:+
>  919742700996%22]
> 
> Please help me to fix this at the server side, since the client or URI 
> requester is already in production/field.
> 
> Regards,
> Chandra
> 
> 

There are two ways to this issue.

1. Front your Apache Tomcat with Apache HTTPD and mod_jk

This is the least invasive to your code. However, it depends on Apache
HTTPD being lenient with RFC 7230 and RFC 3986. How ling that lasts is
up to that project.

a. Read the docs on how to configure Apache HTTPD / Tomcat / mod_jk

https://tomcat.apache.org/connectors-doc/
https://tomcat.apache.org/connectors-doc/webserver_howto/apache.html

b. Use the excellent uriworkers.properties file found in the source at:

[distribution-root]/conf

where [distribution-root] is tomcat-connectors-1.2.42-src as I write this.

c. Note the defaults with respect to encoding

From the second link above:

Using JkOptions ForwardURIProxy, the forwarded URI will be partially
reencoded after processing inside Apache and before forwarding to
Tomcat. This will be compatible with local URL manipulation by
mod_rewrite and with URL encoded session ids.

JkOptions +ForwardURIProxy

This is the default as of version 1.2.24.

This may solve your problem. It solved ours, but our issue is with a
request parameter, not the entire URI.

Note that this is not a fix - and may NOT work for your use case.

2. Fix the code

If you are sending this GET via AJAX and javascript, there is a very
simple solution - encode the URI.

For an entire URL, the following function call is all you need:

var encoded_uri = encodeURI("unencoded uri);

Then use the encoded_uri value to make the request.

As I said above, our issue is with a request parameter, so the
developers will use the following:

var encoded_param = encodeURIComponent("unencoded request paramenter");

Then use the encoded_param value to make the request.

3. If you're not using AJAX / javascript

Then you have a lot of work to do, especially if method 1 above does not
solve your problem.

. . . just my two cents.
/mde/



signature.asc
Description: OpenPGP digital signature

java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

[Chandrashekar H . S]

Hi All,
We have recently upgraded tomcat from 8.0.30 to 8.5.11.

The tomcat 8.5.11 rejects the requested URI with below error.
Requested URI: 
/poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name="oma_pocbuddylist"]/entry[@uri="tel:+919742700996"]

Mar 13, 2017 5:05:20 PM org.apache.coyote.http11.Http11Processor service
INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG 
level.
java.lang.IllegalArgumentException: Invalid character found in the request 
target. The valid characters are defined in RFC 7230 and RFC 3986
   at 
org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:471)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:667)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
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)

The server accepts the request if the DQUOTE(") is replaced with text %22 as 
mentioned below
/poc-root/resource-lists/users/tel:+918197119913/index/~~/resource-lists/list[@name=%22oma_pocbuddylist%22]/entry[@uri=%22tel:+
 919742700996%22]

Please help me to fix this at the server side, since the client or URI 
requester is already in production/field.

Regards,
Chandra

Re: POST + 500 + Response returns no content

[Marc Boorshtein]

>
>
>
>
>> E.g. "Transfer-Encoding: chunked" and "Content-Length" are mutually
>> exclusive, cannot be used at the same time, cannot be used more than
>> once. They should not be blindly copied.
>>
>
> Good question on that, I can take a look.  I remove Content-Length from
> the downstream response but I'll also see if removing Transfer-Encoding
> helps.
>
>
>
>>
>>
it looks like we have a winner!  I added Transfer-Encoding to the list of
downstream response headers to ignore and it looks like its working.

Thanks

Re: POST + 500 + Response returns no content

[Marc Boorshtein]

>
>
>
> Status 500 means that some error happened during processing.
>
> Is there anything in the logs? Exceptions?
>
>
The 500 was generated by a downstream Tomcat 8.5.11 server, this one is
just trying to proxy the message.



> Maybe the browser closes the connection by its own decision, without
> reading the response? (Thus a
> org.apache.catalina.connector.ClientAbortException happens. I think it
> may be logged as status 500).
>
>
Usually you get an error on Tomcat when that happens


>
> If I see correctly, ProxyResponse copies the headers from somewhere
> (from a proxied response?).
>
> Are those headers sane and correct?
>
>
They're being proxied from the downstream server which is another tomcat.



> E.g. "Transfer-Encoding: chunked" and "Content-Length" are mutually
> exclusive, cannot be used at the same time, cannot be used more than
> once. They should not be blindly copied.
>

Good question on that, I can take a look.  I remove Content-Length from the
downstream response but I'll also see if removing Transfer-Encoding helps.



>
> The status code is coped from somewhere. Does it have the expected value
> (200)?
>
>
In this case 500 is expected since input didn't pass validation.


> Is the text in those headers (and status message) correct 7-bit
> US-ASCII characters?
>
>
> Can this be tested with a simple browser like Curl or Wget  that can
> log response headers?
> Or a simple raw client (telnet, puTTY).
>
>

i can see the headers in chrome and firefox.  Nothing out of the ordinary.


>
> I do not see anything in changelog for 8.0.40-8.0.41 that could result
> in such change in behaviour. Maybe configurations of the two systems
> are different?
>
>
No changes.  I have a source2image process that builds the docker container
https://github.com/TremoloSecurity/OpenUnisonS2IDocker so when a new
version comes out i just up the version number to get it pulled.


> Make sure that there are no duplicate jars in WEB-INF/lib.
> Sometimes building a project pulls in several copies of the same
> library, and the order of jars in WEB-INF/lib is random and depends on
> version of Java. Thus you won't know what version wins.
>
>
I don't think this is the issue since it happens ONLY on Post+500, not
Post+200



> Do both systems use the same connector type (bio/nio/apr,  ajp/http/https)?
>
>
>
both systems are using the same docker image base so exactly the same
except for the webapp


> Try running WireShark, to inspect network traffic?
> https://www.wireshark.org/


encrypted so not good


>
>
> Try running with a debugger?
> https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
>
>
yes, i have verified that my code is sending the expected data to Tomcat,
Tomcat is not doing anything with that data though.


Thanks
Marc

Re: POST + 500 + Response returns no content

[Marc Boorshtein]

>
>
> I'm working directly with the servlet api.  Whats odd is it worked fine in
> 8.0.39.  The response is set first:
>
>
>
Also, I just verified the issue doesn't occur using undertow 1.3.25

Re: Trivial DataSource ResourceLink error

[Enrico Olivelli]

2017-03-13 12:44 GMT+01:00 Konstantin Kolinko :

> 2017-03-13 13:44 GMT+03:00 Enrico Olivelli :
> > Hi,
> > I'm trying to setup a DataSource configured in GlobalNamingResources in
> > server.xml.
> > https://tomcat.apache.org/tomcat-8.5-doc/config/context.
> html#Resource_Links
> >
> > in server.xml I have:
> >
> >  
> > 
> >  >   type="org.apache.catalina.UserDatabase"
> >   description="User database that can be updated and saved"
> >   factory="org.apache.catalina.users.
> MemoryUserDatabaseFactory"
> >   pathname="conf/tomcat-users.xml" />
> >
> >>   auth="Container"
> >   type="javax.sql.DataSource"
> >   driverClassName="net.sourceforge.jtds.jdbc.Driver"
> >   url="jdbc:jtds:sqlserver://x"
> >   username="x"
> >   password=""
> >   maxTotal="20"
> >   validationQuery="select 1"
> >   maxIdle="10"
> >   maxWaitMillis="-1" />
> >  
> >
> >
> > In context.xml I have
>
> Which context.xml file?
> It must be META-INF/context.xml in the webapp or
> conf/// .xml in Tomcat.
>
> A common mistake is to edit the global conf/context.xml file.
>
> > 
> > 
>
> The "path" attribute is not allowed here. (It is allowed only when
> defining  directly in conf/server.xml).
>


it is META-INF/context.xml in the webapp, I cannot remove the 'path'
attribute because without it NetBeans will not deploy the App (this is
surely an issue for NB)



>
> >  > name="jdbc/DobermonDatabase"
> > global="jdbc/DobermonDatabase"
> > type="javax.sql.DataSource"
> > factory="org.apache.naming.factory.DataSourceLinkFactory"
> > />
>
> I usually omit the "factory" attribute in a ResourceLink.  Setting
> "name", "global" and "type" is enough.
>


by omitting the factory="org.apache.naming.factory.DataSourceLinkFactory"
all works as espected




I wonder if there is a more "portable" way of declaring the resource link
in web.xml without the context.xml file in the web app

But for me at this time the context.xml solution is OK


Thank you very much !


>
> Otherwise it looks good.
>
> >
> > 
> >
> > In web.xml I have
> > http://java.sun.com/xml/ns/j2ee;
> >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> > http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
> >  version="2.4">
>
> Servlet 2.4 spec, really?  You want to stay compatible with Tomcat 5.5?
>
> Note that you can use "validate" function in an XML editor to validate
> this file against its schema (web-app_2_4.xsd).
>
> > Dobermon
> >
> > 
> > DB Connection
> > jdbc/DobermonDatabase
> > javax.sql.DataSource
> > Container
> > 
> > 
> >
> > My code is:
> >  protected Connection getConnection() throws SQLException,
> NamingException {
> > InitialContext ic = new InitialContext();
> > DataSource ds = (DataSource)
> > ic.lookup("java:comp/env/jdbc/DobermonDatabase");
> > return ds.getConnection();
> > }
> >
> >
> > I am using Tomcat 8.5.9, I get this error:
> >  java.lang.NullPointerException
> > at
> > org.apache.naming.factory.DataSourceLinkFactory.getObjectInstance(
> DataSourceLinkFactory.java:64)
> > at
> > javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> > at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
> > at org.apache.naming.SelectorContext.lookup(
> SelectorContext.java:163)
> > at javax.naming.InitialContext.lookup(InitialContext.java:417)
> > at dobermon.QueryResource.getConnection(QueryResource.java:36)
> >
> >
> > If I declare the datasource inside context.xml no error is thrown and I
> get
> > access the database
> >
> > I want to use GlobalNamingResources without hardcoding username/password
> in
> > context.xml, that is committed to my shared source repository.
> >
> > Any ideas ?
> > Is there any trivial error ?
>
> Any other errors at startup time? In catalina log, in localhost log?
>
> You may test whether the global Resource is declared correctly:
> start Tomcat without your webapp,
> connect as JMX client (with jconsole)
> and look whether your db connection pool is listed as a bean in jconsole.
>
> (http://tomcat.apache.org/presentations.html
> See 

Re: Trivial DataSource ResourceLink error

[Konstantin Kolinko]

2017-03-13 13:44 GMT+03:00 Enrico Olivelli :
> Hi,
> I'm trying to setup a DataSource configured in GlobalNamingResources in
> server.xml.
> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Resource_Links
>
> in server.xml I have:
>
>  
> 
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>
>  auth="Container"
>   type="javax.sql.DataSource"
>   driverClassName="net.sourceforge.jtds.jdbc.Driver"
>   url="jdbc:jtds:sqlserver://x"
>   username="x"
>   password=""
>   maxTotal="20"
>   validationQuery="select 1"
>   maxIdle="10"
>   maxWaitMillis="-1" />
>  
>
>
> In context.xml I have

Which context.xml file?
It must be META-INF/context.xml in the webapp or
conf/// .xml in Tomcat.

A common mistake is to edit the global conf/context.xml file.

> 
> 

The "path" attribute is not allowed here. (It is allowed only when
defining  directly in conf/server.xml).

>  name="jdbc/DobermonDatabase"
> global="jdbc/DobermonDatabase"
> type="javax.sql.DataSource"
> factory="org.apache.naming.factory.DataSourceLinkFactory"
> />

I usually omit the "factory" attribute in a ResourceLink.  Setting
"name", "global" and "type" is enough.

Otherwise it looks good.

>
> 
>
> In web.xml I have
> http://java.sun.com/xml/ns/j2ee;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
>  version="2.4">

Servlet 2.4 spec, really?  You want to stay compatible with Tomcat 5.5?

Note that you can use "validate" function in an XML editor to validate
this file against its schema (web-app_2_4.xsd).

> Dobermon
>
> 
> DB Connection
> jdbc/DobermonDatabase
> javax.sql.DataSource
> Container
> 
> 
>
> My code is:
>  protected Connection getConnection() throws SQLException, NamingException {
> InitialContext ic = new InitialContext();
> DataSource ds = (DataSource)
> ic.lookup("java:comp/env/jdbc/DobermonDatabase");
> return ds.getConnection();
> }
>
>
> I am using Tomcat 8.5.9, I get this error:
>  java.lang.NullPointerException
> at
> org.apache.naming.factory.DataSourceLinkFactory.getObjectInstance(DataSourceLinkFactory.java:64)
> at
> javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
> at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
> at org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at dobermon.QueryResource.getConnection(QueryResource.java:36)
>
>
> If I declare the datasource inside context.xml no error is thrown and I get
> access the database
>
> I want to use GlobalNamingResources without hardcoding username/password in
> context.xml, that is committed to my shared source repository.
>
> Any ideas ?
> Is there any trivial error ?

Any other errors at startup time? In catalina log, in localhost log?

You may test whether the global Resource is declared correctly:
start Tomcat without your webapp,
connect as JMX client (with jconsole)
and look whether your db connection pool is listed as a bean in jconsole.

(http://tomcat.apache.org/presentations.html
See "Monitoring Apache Tomcat with JMX" presentation from ApacheCon 2016)

You may also try running with a debugger,
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging

Best regards,
Konstantin Kolinko

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

Re: POST + 500 + Response returns no content

[Konstantin Kolinko]

2017-03-12 15:32 GMT+03:00 Marc Boorshtein :
> Mark & Olaf,
>
> I'm working directly with the servlet api.  Whats odd is it worked fine in
> 8.0.39.  The response is set first:
>
> https://github.com/TremoloSecurity/OpenUnison/blob/1.0.9/unison/unison-server-core/src/main/java/com/tremolosecurity/proxy/filter/PostProcess.java
> - lines 110-121
>
> Then I set the cookies and the headers:
>
> https://github.com/TremoloSecurity/OpenUnison/blob/1.0.9/unison/unison-server-core/src/main/java/com/tremolosecurity/proxy/ConfigSys.java
> line 310 -->
> https://github.com/TremoloSecurity/OpenUnison/blob/1.0.9/unison/unison-server-core/src/main/java/com/tremolosecurity/proxy/ProxyResponse.java
> line 205
>
> Finally, I'm writing the actual content:
>
> https://github.com/TremoloSecurity/OpenUnison/blob/1.0.9/unison/unison-server-core/src/main/java/com/tremolosecurity/proxy/ConfigSys.java
> line 316 --> line 515
>
> I setup traces and have verified that the codes are being set properly, the
> response isn't committed until AFTER I write the content but for some
> reason the data isn't going back to the browser (the headers aren't either
> so its not just the content).  The only thing thats sent back is the status
> code.

Status 500 means that some error happened during processing.

Is there anything in the logs? Exceptions?

Maybe the browser closes the connection by its own decision, without
reading the response? (Thus a
org.apache.catalina.connector.ClientAbortException happens. I think it
may be logged as status 500).


If I see correctly, ProxyResponse copies the headers from somewhere
(from a proxied response?).

Are those headers sane and correct?

E.g. "Transfer-Encoding: chunked" and "Content-Length" are mutually
exclusive, cannot be used at the same time, cannot be used more than
once. They should not be blindly copied.

The status code is coped from somewhere. Does it have the expected value (200)?

Is the text in those headers (and status message) correct 7-bit
US-ASCII characters?


Can this be tested with a simple browser like Curl or Wget  that can
log response headers?
Or a simple raw client (telnet, puTTY).


I do not see anything in changelog for 8.0.40-8.0.41 that could result
in such change in behaviour. Maybe configurations of the two systems
are different?

Make sure that there are no duplicate jars in WEB-INF/lib.
Sometimes building a project pulls in several copies of the same
library, and the order of jars in WEB-INF/lib is random and depends on
version of Java. Thus you won't know what version wins.

Do both systems use the same connector type (bio/nio/apr,  ajp/http/https)?


Try running WireShark, to inspect network traffic?
https://www.wireshark.org/

Try running with a debugger?
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging

Best regards,
Konstantin Kolinko

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

Trivial DataSource ResourceLink error

[Enrico Olivelli]

Hi,
I'm trying to setup a DataSource configured in GlobalNamingResources in
server.xml.
https://tomcat.apache.org/tomcat-8.5-doc/config/context.html#Resource_Links

in server.xml I have:

 



  
 


In context.xml I have








In web.xml I have
http://java.sun.com/xml/ns/j2ee;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
 version="2.4">
Dobermon


DB Connection
jdbc/DobermonDatabase
javax.sql.DataSource
Container



My code is:
 protected Connection getConnection() throws SQLException, NamingException {
InitialContext ic = new InitialContext();
DataSource ds = (DataSource)
ic.lookup("java:comp/env/jdbc/DobermonDatabase");
return ds.getConnection();
}


I am using Tomcat 8.5.9, I get this error:
 java.lang.NullPointerException
at
org.apache.naming.factory.DataSourceLinkFactory.getObjectInstance(DataSourceLinkFactory.java:64)
at
javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:321)
at org.apache.naming.NamingContext.lookup(NamingContext.java:839)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:159)
at org.apache.naming.NamingContext.lookup(NamingContext.java:827)
at org.apache.naming.NamingContext.lookup(NamingContext.java:173)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:163)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at dobermon.QueryResource.getConnection(QueryResource.java:36)


If I declare the datasource inside context.xml no error is thrown and I get
access the database

I want to use GlobalNamingResources without hardcoding username/password in
context.xml, that is committed to my shared source repository.

Any ideas ?
Is there any trivial error ?


Thank you
-- Enrico