from:"Bhavesh Mistry"

Re: OCSP Stapling Configuration and Tomcat 9

2024-01-05 Thread Bhavesh Mistry

Hi Chris,

Thanks for the update and confirming that we don't need a native connector
for OCSP stamping to work.   I have not followed any of the instructions
below. I am at the beginning of the journey trying to explore what changes
are needed to support OCSP stamping.  Again, thanks for your support and
reference. I will test it out based on the reference you provided. If I
need any help, I will kindly reach out again.



*Did you follow the instructions from the progress.com
<http://progress.com/> page concerningthe importing of your server's key
and certificate and the CA'sintermediate and root certs?*

Thanks,

Bhavesh

On Fri, Jan 5, 2024 at 11:07 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Bhavesh,
>
> On 1/5/24 12:57, Bhavesh Mistry wrote:
> > Hi All,
> >
> > According to Tomcat 9 Official documentation, only Tomcat NATIVE
> Connector
> > supports it.
> >
> https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates
> >
> > But this site claims
> >
> https://community.progress.com/s/article/PASOE-OCSP-Stapling-does-not-work
> > that it works with non-native connectors.   Please let me know if a
> > non-native connector works or not for OCSP Stamping.
> >
> > Here is the reference configuration:
> >
> >
> > - Update the *protocol *property and add the *sslImplementationName
> > *property
> > as follows:
> >
> >   > port="${psc.as.https.port}"
> > protocol="org.apache.coyote.http11.*Http11NioProtocol*"
> >
>  sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation"
> >
> >
> > - Add the *-Djdk.tls.server.enableStatusRequestExtension=true* JVM
> > system property in the *\conf\jvm.properties* file to
> > enable OCSP Stapling support for the JVM.
> > - It is also recommended to add the
> -Djdk.tls.ephemeralDHKeySize=2048 JVM
> > parameter to the *\conf\jvm.properties* file to
> prevent
> > the use of weak Diffie-Hellman (DH) keys. For more information,
> please
> > refer to the following Oracle
>
> According to https://bz.apache.org/bugzilla/show_bug.cgi?id=56148 this
> is not complete for the APR connector. I do recall lots of conversation
> about this, and I thought it was working, but Mark is very diligent
> about updating bugs when they are complete, so it's unlikely he
> completed the work and then didn't close the bug.
>
> According to the conversation in that bug, NIO and NIO2 should work if
> you have a recent Java (9 or later ought to work) if you set that system
> property you have listed above.
>
> I have no idea what \conf\jvm.properties is for, but you
> should make absolutely sure that the system property is actually being
> set at JVM launch. You can write a simple servlet or JSP to inspect that
> to verify, or use something like jinfo to inspect a running process's
> system properties.
>
> Did you follow the instructions from the progress.com page concerning
> the importing of your server's key and certificate and the CA's
> intermediate and root certs?
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

OCSP Stapling Configuration and Tomcat 9

2024-01-05 Thread Bhavesh Mistry

Hi All,

According to Tomcat 9 Official documentation, only Tomcat NATIVE Connector
supports it.
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html#Using_OCSP_Certificates

But this site claims
https://community.progress.com/s/article/PASOE-OCSP-Stapling-does-not-work
that it works with non-native connectors.   Please let me know if a
non-native connector works or not for OCSP Stamping.

Here is the reference configuration:


   - Update the *protocol *property and add the *sslImplementationName
*property
   as follows:

\conf\jvm.properties* file to
   enable OCSP Stapling support for the JVM.
   - It is also recommended to add the -Djdk.tls.ephemeralDHKeySize=2048 JVM
   parameter to the *\conf\jvm.properties* file to prevent
   the use of weak Diffie-Hellman (DH) keys. For more information, please
   refer to the following Oracle

Thanks,

Bhavesh

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

2023-09-01 Thread Bhavesh Mistry

Hi Mark,

Thanks for your help. We will go with validation against a known trusted
list host as you suggested.  Also, I have updated
https://bz.apache.org/bugzilla/show_bug.cgi?id=64353 with reference to the
discussion.

As always, thanks for your wonderful support!

Thanks,

Bhavesh

On Tue, Aug 29, 2023 at 2:07 PM Mark Thomas  wrote:

> On 29/08/2023 21:51, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> >> curl - -k "https://www.mydomain.com/login; -H  'Host:
> >> attackerHostHeaderInjection.com'
> >
> > *Why? What problem are you trying to solve?*
> >
> > Host Header injection is a vulnerability that needs to be addressed., I
> am
> > trying to solve if the host is a mismatch between the HOST ( or
> Authority)
> > header because links are generated based on the host headers.
> >
> > For now only way to prevent it is to have a set of allowed hosts and
> check
> > against this list.
>
> I'd argue that links shouldn't be being generated based on the Host
> header. You should be able to use relative links. That said...
>
> Given the wide variety of deployment architectures (CDN, reverse procy
> etc) if you do need to use the Host header, validation against a known
> trusted list is probably the most robust option. TLS information may not
> always be available.
>
> > Should I update the bug to provide SNI information for the request or
> > should I file another request ?
> > See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353
>
> I'd say add it to that issue as the two are closely related.
>
> > 3) I tried following but again curl - shows it never sent
> > www.mydomain.com <https://www.mydomain.com/login> since it only used to
> > reach the IP. (This is what Thomas Hoffmann mentioned).
> >
> https://serverfault.com/questions/850955/tomcat-virtual-host-to-prevent-improper-input-handling-attack
> >
> > Thanks for your help so far.
>
> There is another option.
>
> The Host header is used for virtual host selection. If you create a
> valid virtual host for each valid host name (you can have aliases so
> they could all go to the same host) then the default virtual host could
> just have a ROOT webapp that returned you 4xx response of choice.
>
> It is just a different way of implementing an allow list for the Host
> header. The advantage is that it is transparent to the application(s).
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

2023-08-29 Thread Bhavesh Mistry

Hi Mark,

> curl - -k "https://www.mydomain.com/login; -H  'Host:
> attackerHostHeaderInjection.com'

*Why? What problem are you trying to solve?*

Host Header injection is a vulnerability that needs to be addressed., I am
trying to solve if the host is a mismatch between the HOST ( or Authority)
header because links are generated based on the host headers.

For now only way to prevent it is to have a set of allowed hosts and check
against this list.

Should I update the bug to provide SNI information for the request or
should I file another request ?
See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353

3) I tried following but again curl - shows it never sent
www.mydomain.com <https://www.mydomain.com/login> since it only used to
reach the IP. (This is what Thomas Hoffmann mentioned).
https://serverfault.com/questions/850955/tomcat-virtual-host-to-prevent-improper-input-handling-attack

Thanks for your help so far.

Thanks,

Bhavesh

On Tue, Aug 29, 2023 at 1:16 PM Mark Thomas  wrote:

> On 29/08/2023 08:00, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > I am sorry for delayed response.
> >
> > Basically, when request url does not match host header then I would
> reject
> > it.  For example,
> >
> > curl - -k "https://www.mydomain.com/login; -H  'Host:
> > attackerHostHeaderInjection.com'
>
> Why? What problem are you trying to solve?
>
>
> > Based curl -vvv output,  tomcat server does not know host name used
> > www.mydomain.com but Host header is attackerHostHeaderInjection.com.
> >
> > In this case I would like to reject request send 403 or 404.  As you
> > explained that request Line does not have Full URL,
> allowHostHeaderMismatch
> > will not reject.
> >
> > So my idea is using SNI I could get hostname and compare with HOST header
> > or :authority and reject it.
> >
> > Is it possible to request new feature on Tomcat to get or expose SNI name
> > used by client?
>
> That is certainly possible. How likely it is to get implemented depends
> on the justification.
>
> See also https://bz.apache.org/bugzilla/show_bug.cgi?id=64353
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

2023-08-29 Thread Bhavesh Mistry

Hi Mark,

I am sorry for delayed response.

Basically, when request url does not match host header then I would reject
it.  For example,

curl - -k "https://www.mydomain.com/login; -H  'Host:
attackerHostHeaderInjection.com'


Based curl -vvv output,  tomcat server does not know host name used
www.mydomain.com but Host header is attackerHostHeaderInjection.com.

In this case I would like to reject request send 403 or 404.  As you
explained that request Line does not have Full URL, allowHostHeaderMismatch
will not reject.

So my idea is using SNI I could get hostname and compare with HOST header
or :authority and reject it.

Is it possible to request new feature on Tomcat to get or expose SNI name
used by client?

Thanks,

Bhavesh


On Tue, Aug 22, 2023, 3:03 PM Mark Thomas  wrote:

> Tomcat doesn't expose the SNI information.
>
> What problem are you trying to solve here?
>
> Tomcat rejects requests with mis-matched host headers by default and can
> be configured to allow them in 8.5.x, 9.0.x and 10.1.x. You shouldn't
> need to write any extra code for this.
>
> Mark
>
>
> On 21/08/2023 12:59, Bhavesh Mistry wrote:
> >>
> >>
> >> Hi Mark and Thomas,
> >>
> >>
> >>
> >> I understood now that Tomcat does not have information other than HOST
> >> (HTTP 1.1) and :authority: (HTTP2).  So there is no way to check what
> URL
> >> used to connect and headers.
> >>
> >>
> >>
> >> I was wondering if TLS Handshake can provide *SNI can be used for this
> >> purpose**. *
> >>
> >> *Server Name Indication (SNI) is an extension of the TLS protocol. The
> >> client specifies which hostname they want to connect to using the SNI
> >> extension in the TLS handshake. *
> >>
> >>
> >>
> >> *SNI will be the hostname that the browser used to negotiate TLS.  so my
> >> idea is to check SNI vs (host or  *:authority: ) header and if there is
> a
> >> mismatch between host/authority vs. SNI.  I can reject requests and
> throw
> >> 404 status.
> >>
> >>
> >>
> >> Do you know how I can *obtain SNI* from the tomcat HttpRequest object?
> >> What hostname was negotiated with TLS?  Do you think the idea of
> checking
> >> against SNI and *host or  *:authority:  headers?
> >>
> >>
> >>
> >> As always, your opinion and suggestion are always appreciated.
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >>
> >> Bhavesh
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

2023-08-21 Thread Bhavesh Mistry

>
>
> Hi Mark and Thomas,
>
>
>
> I understood now that Tomcat does not have information other than HOST
> (HTTP 1.1) and :authority: (HTTP2).  So there is no way to check what URL
> used to connect and headers.
>
>
>
> I was wondering if TLS Handshake can provide *SNI can be used for this
> purpose**. *
>
> *Server Name Indication (SNI) is an extension of the TLS protocol. The
> client specifies which hostname they want to connect to using the SNI
> extension in the TLS handshake. *
>
>
>
> *SNI will be the hostname that the browser used to negotiate TLS.  so my
> idea is to check SNI vs (host or  *:authority: ) header and if there is a
> mismatch between host/authority vs. SNI.  I can reject requests and throw
> 404 status.
>
>
>
> Do you know how I can *obtain SNI* from the tomcat HttpRequest object?
> What hostname was negotiated with TLS?  Do you think the idea of checking
> against SNI and *host or  *:authority:  headers?
>
>
>
> As always, your opinion and suggestion are always appreciated.
>
>
>
> Thanks,
>
>
>
> Bhavesh
>

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

2023-08-19 Thread Bhavesh Mistry

Hi Mark,

Thanks for your quick reply.   According to the spec, the Request line
three line: http method path and version.  Basically, what I wanted to do
to is if the HOST header does not match the requested server name in the
URL then return 404 04 403.

Can you please help me how I can do this?  From raw request, there is NO
way to know what the user requested URL is and the HOST name as tomcat
reconstructed that from the HOST header.

When using the following:

curl - -k "https://10.40.43.26/login?sessionExpire=true; -H   'Host:
attacker.com'

request.getServerName() = attacker.com

request.getHeader("Host") = attacker.com

request.getURL() :  https://attacker.com/login?sessionExpire=true

There is no way for the server to know that the HOST header does not match
the URL hostname name.  So the only way to stop this is to have a
pre-determined list of hostnames and check against it.  Do you have any
recommendations how to detect host header mismatch from application logic ?

Only thing I found is this to have list trusted host and compare host
header against it:
https://github.com/spring-projects/spring-security/blob/main/web/src/main/java/org/springframework/security/web/firewall/StrictHttpFirewall.java#L549







On Sat, Aug 19, 2023 at 2:10 PM Mark Thomas  wrote:

>
> 19 Aug 2023 19:46:56 Bhavesh Mistry :
>
> > Hi, Tomcat Dev team and Users,
> >
> >
> > I am trying to block the request and give 404 bad requests or 403 when
> > the
> > HOST header does not match the requested server name.  My goal is to
> > block
> > whenever there is a mismatch in the host header and URL server name.
> >
> > I would appreciate your help.
>
> Look at the request. Despite the curl command using an IP address, the
> actual request does not contain a host in the request line hence there is
> no mismatch.
>
> Mark
>
>
> >
> > curl - -k "https://*10.40.43.26*/login?sessionExpire=true; -H
> > '*Host:
> > text.com <http://text.com>*'
> > * Using Stream ID: 1 (easy handle 0x7f8316012800)
> >> GET /login?sessionExpire=true HTTP/2
> > *> Host: text.com <http://text.com>*
> >> User-Agent: curl/8.1.2
> >> Accept: */*
> >
> > Response:
> >
> > * HTTP/2 200 *
> > < cache-control: no-cache, no-store, must-revalidate
> > < expect-ct: enforce, max-age=30, report-uri='
> > https://report-uri.com/account/'
> > < pragma: no-cache
> > < expires: Thu, 01 Jan 1970 00:00:00 GMT
> > < set-cookie:
> >
> >
> JSESSIONID=4D75D564BC3CF7E406A599962DE5C092;Version=1;Path=/versa;Secure;HttpOnly;
> > SameSite=strict
> > < strict-transport-security: max-age=31536000 ; includeSubDomains ;
> > preload
> > < x-xss-protection: 1; mode=block
> > < x-frame-options: DENY
> > < x-content-type-options: nosniff
> > < referrer-policy: strict-origin-when-cross-origin
> > < content-type: text/html;charset=UTF-8
> > < content-length: 4084
> > < date: Sat, 19 Aug 2023 19:02:11 GMT
> >
> > Here is my connector config:
> >
> >  >connectionTimeout="2"
> >redirectPort="443" scheme="https" secure="true"
> > server="Versa Director"
> >address="${tomcat.address}"  maxPostSize="-1"
> > *allowHostHeaderMismatch="false"* />
> >
> >
> >  > protocol="org.apache.coyote.http11.Http11NioProtocol"
> >relaxedPathChars="[\\]^`{|}"
> > relaxedQueryChars="[\\]^`{|}" *allowHostHeaderMismatch="false"
> > *
> >address="${tomcat.address}" minSpareThreads="100"
> > maxThreads="200" SSLEnabled="true"
> >scheme="https" secure="true" maxSwallowSize="-1"
> > maxPostSize="-1">
> >
> > Thanks,
> >
> > Bhavesh
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

2023-08-19 Thread Bhavesh Mistry

Hi, Tomcat Dev team and Users,


I am trying to block the request and give 404 bad requests or 403 when the
HOST header does not match the requested server name.  My goal is to block
whenever there is a mismatch in the host header and URL server name.

I would appreciate your help.

curl - -k "https://*10.40.43.26*/login?sessionExpire=true; -H '*Host:
text.com *'
* Using Stream ID: 1 (easy handle 0x7f8316012800)
> GET /login?sessionExpire=true HTTP/2
*> Host: text.com *
> User-Agent: curl/8.1.2
> Accept: */*

Response:

* HTTP/2 200 *
< cache-control: no-cache, no-store, must-revalidate
< expect-ct: enforce, max-age=30, report-uri='
https://report-uri.com/account/'
< pragma: no-cache
< expires: Thu, 01 Jan 1970 00:00:00 GMT
< set-cookie:
JSESSIONID=4D75D564BC3CF7E406A599962DE5C092;Version=1;Path=/versa;Secure;HttpOnly;
SameSite=strict
< strict-transport-security: max-age=31536000 ; includeSubDomains ; preload
< x-xss-protection: 1; mode=block
< x-frame-options: DENY
< x-content-type-options: nosniff
< referrer-policy: strict-origin-when-cross-origin
< content-type: text/html;charset=UTF-8
< content-length: 4084
< date: Sat, 19 Aug 2023 19:02:11 GMT

Here is my connector config:






Thanks,

Bhavesh

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-20 Thread Bhavesh Mistry

Hi, Mark and Tomcat team,

Thank you for your support so far and I will take it up with Firefox.  I
will look into CSP as well. Thanks for checking this.


Thanks,

Bhavesh

On Sat, Mar 18, 2023 at 4:56 AM Mark Thomas  wrote:

> That looks like a browser bug then. You'll need to raise that with Firefox.
>
> Also, the CSP doesn't look quite right.
>
> "...form-action 'self'; https:;..."
>
> should probably be:
>
> "...form-action 'self' https:;..."
>
> Mark
>
>
> On 17/03/2023 23:34, Bhavesh Mistry wrote:
> > Hi Tomcat Team and Mark,
> >
> > I am able to reproduce the problem with your sample app. *CSP large
> > header is causing this problem we attached it to ALL responses.  This
> > custom header.  I am not sure if this is a tomcat issue or Firefox. *We
> > get *NS_ERROR_ABORT*.   Sorry, it took a while but the issue is
> > reproducible with CSP or Large header.
> >
> > Sample:
> >
> https://github.com/bmistry13/tomat-204-issue/blob/main/no-content-test.war
> <
> https://github.com/bmistry13/tomat-204-issue/blob/main/no-content-test.war
> >
> >
> > web.xml
> >  >  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
> > <http://www.w3.org/2001/XMLSchema-instance>"
> >  xmlns="http://java.sun.com/xml/ns/javaee
> > <http://java.sun.com/xml/ns/javaee>"
> >  xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd
> > <http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd>"
> >  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> > <http://java.sun.com/xml/ns/javaee>
> > https://java.sun.com/xml/ns/javaee/web-app_4_0.xsd
> > <https://java.sun.com/xml/ns/javaee/web-app_4_0.xsd>"
> >  id="Versa"
> >  version="4.0">
> >
> >  testa
> >
> > *
> >  TESTServlet
> >  AjaxTestServlet
> >  AjaxServletTest
> >  
> >
> >  
> >  AjaxTestServlet
> >  /test
> >  *
> >  
> >  60
> >  COOKIE
> >  
> > true
> > true
> >  
> >  
> >  
> >  
> >  HTTPSOnly
> >  /*
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  js
> >  application/javascript
> >  
> > 
> > ~
> >
> > --- JSP change
> >
> > 
> >
> >
> >  > src="<a  rel="nofollow" href="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js">http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js</a>
> > <<a  rel="nofollow" href="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js">http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js</a>
> >">
> > 
> >  function test() {
> >
> >   for (let i = 5; i < 10; i++) {
> >  $.ajax({
> >  async: true,
> >  type: "GET",
> >  url: "/no-content-test/test?q=test1",
> >  contentType: "application/json; charset=utf-8",
> >  dataType: "json",
> >  success: function (response) {
> >  alert(response.status);
> >  }
> >  });
> >  }
> >  for (let i = 5; i < 10; i++) {
> >  $.ajax({
> >  async: true,
> >  type: "GET",
> >  url: "/no-content-test/test?q=test2",
> >  contentType: "application/json; charset=utf-8",
> >  dataType: "json",
> >  success: function (response) {
> >  alert(response.d);
> >  }
> >  });
> >  }
> >  }
> > 
> >  Clinking on button to ajax test  > onclick='test();' value='Click Me and See Dev Tool Netowrk Tab'/>
> >
> > 
> > --
> >
> > import javax.servlet.ServletException;
> > import javax.servlet.http.HttpServlet;
> > import javax.servlet.http.HttpServletRequest;
> > import javax.servlet.http.HttpServletResponse;
> > import java.io.IOException;
> >
> > public class AjaxServletTest extends HttpServlet {
> >
> >

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-17 Thread Bhavesh Mistry

Hi Tomcat Team and Mark,

I am able to reproduce the problem with your sample app. *CSP large header
is causing this problem we attached it to ALL responses.  This custom
header.  I am not sure if this is a tomcat issue or Firefox.  *We get
*NS_ERROR_ABORT*.   Sorry, it took a while but the issue is reproducible
with CSP or Large header.

Sample:
https://github.com/bmistry13/tomat-204-issue/blob/main/no-content-test.war

web.xml
http://www.w3.org/2001/XMLSchema-instance;
xmlns="http://java.sun.com/xml/ns/javaee;
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd;
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
https://java.sun.com/xml/ns/javaee/web-app_4_0.xsd;
id="Versa"
version="4.0">

testa










*TESTServlet
AjaxTestServlet
AjaxServletTest
AjaxTestServlet
  /test*

60
COOKIE

   true
   true




HTTPSOnly
/*








js
application/javascript


~

--- JSP change



  
http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js&quot</a>;>

function test() {

 for (let i = 5; i < 10; i++) {
$.ajax({
async: true,
type: "GET",
url: "/no-content-test/test?q=test1",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (response) {
alert(response.status);
}
});
}
for (let i = 5; i < 10; i++) {
$.ajax({
async: true,
type: "GET",
url: "/no-content-test/test?q=test2",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (response) {
alert(response.d);
}
});
}
}

Clinking on button to ajax test 
  

--

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

public class AjaxServletTest extends HttpServlet {

private static final String CSP_HEADER = "Content-Security-Policy";

private static final String CSP_HEADER_POLICY = "default-src
'self' https:;font-src 'self' data: https://fonts.googleapis.com/
https://fonts.gstatic.com; script-src 'self' " +
"'sha256-BdZ62JYXk9kaPAizrIertjvay2mtb//aXKRFuOz6RLI='
'sha256-Rv1DFftLIYbmrwNcvKH3vd+fs4aXTb6/RNjTs7CLJOg=' " +
"'sha256-BDvo3wEMDWiXAoVw9mYgGW9GCvsvo3ECBHjc4FzPky8='
'unsafe-eval' https://maps.googleapis.com/maps/api/geocode/json
https://maps.googleapis.com/ " +
"https://*.tile.openstreetmap.org
https://export.highcharts.com/ https://code.highcharts.com/; img-src
'self' blob: " +
"data: https://maps.googleapis.com/maps/api/geocode/json
https://maps.gstatic.com/ https://maps.googleapis.com/
https://*.tile.openstreetmap.org " +
"https://chart.apis.google.com/
https://export.highcharts.com/; style-src 'self' 'unsafe-inline' data:
" +
"https://maps.googleapis.com/maps/api/geocode/json
https://*.tile.openstreetmap.org " +
"https://fonts.googleapis.com/ https://export.highcharts.com/ " +
"https://code.highcharts.com/;form-action 'self'; https:;
block-all-mixed-content; connect-src 'self' wss://self:6080 data:
https://maps.googleapis.com https://*.tile.openstreetmap.org/
https://ipapi.co https://oauth2.googleapis.com/token
https://dialogflow.googleapis.com;;

public void doGet(HttpServletRequest req, HttpServletResponse
resp) throws ServletException, IOException {
resp.setStatus(204);
resp.setHeader(CSP_HEADER, CSP_HEADER_POLICY);
}
}


On Wed, Mar 15, 2023 at 11:30 AM Bhavesh Mistry 
wrote:

> Hi Mark and Tomcat Team,
>
> We have been using tomcat 9 from version 0 to 70 and no issues so far with
> our application and firefox.  We also tried to upgrade to 9.0.73, and show
> the same issue:
>
> As you can see from Devtools it is missing Protocol HTTP2 and is hung
> there.
> [image: image.png]
>
> [04/Mar/2023:00:40:47 +] 10.40.207.127 -
> https-jsse-nio-127.0.0.1-8443-exec-54 Administrator "GET
> /versa/ncs-services/vnms/analyticgroup/all *HTTP/2.0*" 204 - 148ms 148ms
>
>
> Any clue you have in the filter or why it might be 204 response caused
> firefox to be hung?  we have added a custom header to the response that is
> all.   I remove them still same issue.  Any theory or clue you have further
> to debug this no

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-15 Thread Bhavesh Mistry

Hi Mark and Tomcat Team,

We have been using tomcat 9 from version 0 to 70 and no issues so far with
our application and firefox.  We also tried to upgrade to 9.0.73, and show
the same issue:

As you can see from Devtools it is missing Protocol HTTP2 and is hung there.
[image: image.png]

[04/Mar/2023:00:40:47 +] 10.40.207.127 -
https-jsse-nio-127.0.0.1-8443-exec-54 Administrator "GET
/versa/ncs-services/vnms/analyticgroup/all *HTTP/2.0*" 204 - 148ms 148ms


Any clue you have in the filter or why it might be 204 response caused
firefox to be hung?  we have added a custom header to the response that is
all.   I remove them still same issue.  Any theory or clue you have further
to debug this notorious issue?

Thanks,


Bhavesh


On Thu, Mar 9, 2023 at 11:54 AM Mark Thomas  wrote:

> On 09/03/2023 18:19, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > Your sample application worked 204 Firefox and our application does not
> > work.  That leads me to believe *Application Filter *is an issue. But
> > should tomcat throw an exception if the response is already committed?
>
> A call to setStatus() after the response has been committed will be a
> NO-OP.
>
> >  I
> > will try to see if I can reproduce it using a filter with the sample app
> > you gave me.Only one line change  (streamOutputBuffer.closed = true)
> > would make our application work.  So it seems to me that the application
> > filter is writing something after the stream is closed and this may lead
> to
> > this behavior.  I will try to reproduce using this app.   Do still
> consider
> > this application bug or a tomcat platform bug?
>
> Definitely an application bug.
>
> Mark
>
> >
> > Thank you so far for your excellent support and quick responses.
> >
> > Thanks,
> >
> > Bhavesh
> >
> >
> >
> > On Thu, Mar 9, 2023 at 1:14 AM Mark Thomas  wrote:
> >
> >> On 08/03/2023 21:32, Bhavesh Mistry wrote:
> >>> Hi  Mark,
> >>>
> >>> We have a NAT rule that forwards 443 to 8443.
> >>
> >> OK. That explains the change in port.
> >>
> >>> Trust me on that, we have a
> >>> direct connection. To rule out any networking layer issues, I did
> >>> direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a
> >> tunnel
> >>> (https://localhost:8443/)  to bypass port 443. Yet, the issue is still
> >>> reproducible. So there is *NOTHING* in the middle that could cause this
> >>> issue.
> >>
> >> There must be. Could be a FireFox plugin, a Filter used by the web
> >> application, a Valve for a third-party authentication module, etc.
> >>
> >> Try deploying this war:
> >> https://people.apache.org/~markt/dev/no-content-test.war
> >>
> >> It contains 2 JSPs.
> >> index.jsp has a link to no-content.jsp
> >> no-content.jsp just returns a 204
> >>
> >> This works as expected, with no errors with the latest 9.0.x code,
> >> 9.0.72, Chrome and FireFox.
> >>
> >> If it works when deployed to your server, that points to something in
> >> the web application. If it doesn't work, that points to something in the
> >> network and/or browser.
> >>
> >> Mark
> >>
> >> * Is publicly exposing tomcat enough for debugging *or do you still
> >>> need an independent application?  I can have SSH open but you will have
> >> to
> >>> give me your private email to email credentials and public IP.
> >>>
> >>> sudo iptables -t nat -L
> >>> Chain PREROUTING (policy ACCEPT)
> >>> target prot opt source   destination
> >>> VNMS   all  --  anywhere anywhere
> >>>
> >>> Chain INPUT (policy ACCEPT)
> >>> target prot opt source   destination
> >>>
> >>> Chain OUTPUT (policy ACCEPT)
> >>> target prot opt source   destination
> >>>
> >>> Chain POSTROUTING (policy ACCEPT)
> >>> target prot opt source   destination
> >>> MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp
> >> dpt:8000
> >>>
> >>> Chain DOCKER (0 references)
> >>> target prot opt source   destination
> >>> DNAT   tcp  --  anywhere anywhere tcp
> >> dpt:8000
> >>> to:172.17.0.2:8000
> >>>
> >>> Chain VNMS (1 references)
> >>> target

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-09 Thread Bhavesh Mistry

Hi Mark,

Your sample application worked 204 Firefox and our application does not
work.  That leads me to believe *Application Filter *is an issue. But
should tomcat throw an exception if the response is already committed?  I
will try to see if I can reproduce it using a filter with the sample app
you gave me.Only one line change  (streamOutputBuffer.closed = true)
would make our application work.  So it seems to me that the application
filter is writing something after the stream is closed and this may lead to
this behavior.  I will try to reproduce using this app.   Do still consider
this application bug or a tomcat platform bug?

Thank you so far for your excellent support and quick responses.

Thanks,

Bhavesh



On Thu, Mar 9, 2023 at 1:14 AM Mark Thomas  wrote:

> On 08/03/2023 21:32, Bhavesh Mistry wrote:
> > Hi  Mark,
> >
> > We have a NAT rule that forwards 443 to 8443.
>
> OK. That explains the change in port.
>
> > Trust me on that, we have a
> > direct connection. To rule out any networking layer issues, I did
> > direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a
> tunnel
> > (https://localhost:8443/)  to bypass port 443. Yet, the issue is still
> > reproducible. So there is *NOTHING* in the middle that could cause this
> > issue.
>
> There must be. Could be a FireFox plugin, a Filter used by the web
> application, a Valve for a third-party authentication module, etc.
>
> Try deploying this war:
> https://people.apache.org/~markt/dev/no-content-test.war
>
> It contains 2 JSPs.
> index.jsp has a link to no-content.jsp
> no-content.jsp just returns a 204
>
> This works as expected, with no errors with the latest 9.0.x code,
> 9.0.72, Chrome and FireFox.
>
> If it works when deployed to your server, that points to something in
> the web application. If it doesn't work, that points to something in the
> network and/or browser.
>
> Mark
>
>* Is publicly exposing tomcat enough for debugging *or do you still
> > need an independent application?  I can have SSH open but you will have
> to
> > give me your private email to email credentials and public IP.
> >
> > sudo iptables -t nat -L
> > Chain PREROUTING (policy ACCEPT)
> > target prot opt source   destination
> > VNMS   all  --  anywhere anywhere
> >
> > Chain INPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain POSTROUTING (policy ACCEPT)
> > target prot opt source   destination
> > MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp
> dpt:8000
> >
> > Chain DOCKER (0 references)
> > target prot opt source   destination
> > DNAT   tcp  --  anywhere anywhere tcp
> dpt:8000
> > to:172.17.0.2:8000
> >
> > Chain VNMS (1 references)
> > target prot opt source   destination
> > DNAT   tcp  --  anywhere anywhere tcp
> dpt:http
> > to:127.0.0.1:8080
> > *DNAT   tcp  --  anywhere anywhere tcp
> > dpt:https to:127.0.0.1:8443 <http://127.0.0.1:8443>// this rule
> Fowards
> > it to the 8443.*
> > admin@SDWAN-VOAE1:~$
> >
> > On Wed, Mar 8, 2023 at 12:29 PM Mark Thomas  wrote:
> >
> >> On 08/03/2023 19:52, Bhavesh Mistry wrote:
> >>> Hi Mark,
> >>>
> >>> It is a *direct connection* with no proxy or no reverse proxy or no
> load
> >>> balancer in the middle.  We have a web app (UI) that make backend call
> >> and
> >>> return 204 with no content and send it to the browser.  An interesting
> >> fact
> >>> is very thing works on Chrome but not with firefox.  We have tried
> >>> everything and we looked tomcat code and we see a change log around
> this
> >>> area.
> >>
> >> That data you provided previously is not consistent with that statement.
> >>
> >> Tomcat is listening on port 8443.
> >>
> >> Firefox is connecting to port 443.
> >>
> >> I have no doubt the Tomcat change to 204 handling triggered the change
> >> in behavior you are seeing. It appears to have exposed a HTTP/2 bug
> >> somewhere in your system.
> >>
> >>> It is hard to come up with a sample, but I will try it.  I am just
> trying
> >>> to give clue which code or line causing the problem to narrow down the
> >>> issue, b

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-08 Thread Bhavesh Mistry

Hi  Mark,

We have a NAT rule that forwards 443 to 8443.  Trust me on that, we have a
direct connection. To rule out any networking layer issues, I did
direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a tunnel
(https://localhost:8443/)  to bypass port 443. Yet, the issue is still
reproducible. So there is *NOTHING* in the middle that could cause this
issue.  * Is publicly exposing tomcat enough for debugging *or do you still
need an independent application?  I can have SSH open but you will have to
give me your private email to email credentials and public IP.

sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination
VNMS   all  --  anywhere anywhere

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination
MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp dpt:8000

Chain DOCKER (0 references)
target prot opt source   destination
DNAT   tcp  --  anywhere anywhere tcp dpt:8000
to:172.17.0.2:8000

Chain VNMS (1 references)
target prot opt source   destination
DNAT   tcp  --  anywhere anywhere tcp dpt:http
to:127.0.0.1:8080
*DNAT   tcp  --  anywhere anywhere tcp
dpt:https to:127.0.0.1:8443 <http://127.0.0.1:8443>// this rule Fowards
it to the 8443.*
admin@SDWAN-VOAE1:~$

On Wed, Mar 8, 2023 at 12:29 PM Mark Thomas  wrote:

> On 08/03/2023 19:52, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > It is a *direct connection* with no proxy or no reverse proxy or no load
> > balancer in the middle.  We have a web app (UI) that make backend call
> and
> > return 204 with no content and send it to the browser.  An interesting
> fact
> > is very thing works on Chrome but not with firefox.  We have tried
> > everything and we looked tomcat code and we see a change log around this
> > area.
>
> That data you provided previously is not consistent with that statement.
>
> Tomcat is listening on port 8443.
>
> Firefox is connecting to port 443.
>
> I have no doubt the Tomcat change to 204 handling triggered the change
> in behavior you are seeing. It appears to have exposed a HTTP/2 bug
> somewhere in your system.
>
> > It is hard to come up with a sample, but I will try it.  I am just trying
> > to give clue which code or line causing the problem to narrow down the
> > issue, but it is not helping.
>
> Tomcat isn't the root cause. A simple test here with an index JSP and a
> JSP that just returns a 204 works as expected with Chrome and FireFox.
>
> All the indications are that there is an additional component in the
> system you are testing that can't handle an HTTP/2 204 response without
> a body.
>
> Mark
>
>
> >
> > Thanks,
> >
> > Bhavesh
> >
> >
> >
> > On Wed, Mar 8, 2023 at 11:43 AM Mark Thomas  wrote:
> >
> >> On 08/03/2023 19:38, Bhavesh Mistry wrote:
> >>> I will see if I can give a sample.  But after removing JUST ONE LINE  (
> >>> streamOutputBuffer.closed = true;) Everything seems to work. Somehow,
> >>> firefox does not like an active stream being closed (I am not 100% what
> >>> close does).
> >>>
> >>> I will try to work on a sample to reproduce this.  I hope the above can
> >>> give you some clue as to where the issue is.
> >>
> >> Wherever the issue is, it isn't with Tomcat and it isn't with Firefox.
> >> I've tested them locally and they work correctly.
> >>
> >> Might you have a reverse proxy between Firefox and Tomcat?
> >>
> >> 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 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-08 Thread Bhavesh Mistry

Hi Mark,

It is a *direct connection* with no proxy or no reverse proxy or no load
balancer in the middle.  We have a web app (UI) that make backend call and
return 204 with no content and send it to the browser.  An interesting fact
is very thing works on Chrome but not with firefox.  We have tried
everything and we looked tomcat code and we see a change log around this
area.

It is hard to come up with a sample, but I will try it.  I am just trying
to give clue which code or line causing the problem to narrow down the
issue, but it is not helping.

Thanks,

Bhavesh

On Wed, Mar 8, 2023 at 11:43 AM Mark Thomas  wrote:

> On 08/03/2023 19:38, Bhavesh Mistry wrote:
> > I will see if I can give a sample.  But after removing JUST ONE LINE  (
> > streamOutputBuffer.closed = true;) Everything seems to work. Somehow,
> > firefox does not like an active stream being closed (I am not 100% what
> > close does).
> >
> > I will try to work on a sample to reproduce this.  I hope the above can
> > give you some clue as to where the issue is.
>
> Wherever the issue is, it isn't with Tomcat and it isn't with Firefox.
> I've tested them locally and they work correctly.
>
> Might you have a reverse proxy between Firefox and Tomcat?
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-08 Thread Bhavesh Mistry

I will see if I can give a sample.  But after removing JUST ONE LINE  (
streamOutputBuffer.closed = true;) Everything seems to work. Somehow,
firefox does not like an active stream being closed (I am not 100% what
close does).

I will try to work on a sample to reproduce this.  I hope the above can
give you some clue as to where the issue is.

Thanks,

Bhavesh

On Wed, Mar 8, 2023 at 11:21 AM Mark Thomas  wrote:

> On 08/03/2023 19:05, Bhavesh Mistry wrote:
>
> 
>
> > *Then, *I build 9.0.72 src code *without HTTP2 no Content commit, and
> > firefox worked ( I just replace tomcat-coyote.jar) .  What is your
> > suggestion we do next? *
>
> Again, if you can provide a simple test case (with source code - should
> be no more than two very simple servlets or JSPs) we can look at this
> further.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-08 Thread Bhavesh Mistry

Hi Mark and Chris,

Thank you for your reply.  We are using the latest version of* Firefox
110.1*.   I have installed Live HTTP Header Live add-on and I see
*NS_ERROR_ABORT
and the request is stalled in the browser (the 204 status code is never
shown in the Network tab). This applies to any GET call resulting in a
204 error.  * I will see if I can make it publicly accessible so you guys
can take a look.  I don't understand the Firefox HTTP logs, and I cannot
attach them to this email which may give a clue.


But the tomcat access log state request was completed successfully:

[08/Mar/2023:18:09:24 +] 10.42.144.222 -
https-jsse-nio-127.0.0.1-8443-exec-78 Administrator "GET
/versa/ncs-services/vnms/analyticgroup/all?timestamp=1678299946494
HTTP/2.0" *204* - 86ms 85ms

https://10.40.207.140/versa/ncs-services/vnms/analyticgroup/all?timestamp=1678299226297
Host: 10.40.207.140
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0)
Gecko/20100101 Firefox/110.0
Accept: application/json
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://10.40.207.140/versa/
Content-Type: application/json
Connection: keep-alive
Cookie: VD-CSRF-TOKEN=08d3954c-65a5-4b09-91fe-8b62840ed735;
JSESSIONID=D3A79AFA242D423F44A8B0A87EC8CE3C;
atmosphere-%2Fversa%2Fpubsub%2Fwarning%2FAdministrator=%7B%22ts%22%3A1678299225779%7D;
atmosphere-%2Fversa%2Fpubsub%2Fnotifications%2Fcom.versa.alarm.event=%7B%22ts%22%3A1678299225779%7D;
last_visited_page=director/workflows/create-controller
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin

*NS_ERROR_ABORT*


*Then, *I build 9.0.72 src code *without HTTP2 no Content commit, and
firefox worked ( I just replace tomcat-coyote.jar) .  What is your
suggestion we do next? *

Thanks,

Bhavesh



On Wed, Mar 8, 2023 at 8:28 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Bhavesh,
>
> On 3/7/23 22:07, Bhavesh Mistry wrote:
> > Hi Mark Thomas and Tomcat Team,
> >
> > We have a strange issue with Tomcat 9.0.72.  All 204 response does not
> > complete in firefox.  It works in the Chrome browser.  If we downgrade
> > the tomcat version is less than .72. Everything works on all browsers.
> >
> >
> >
> https://github.com/apache/tomcat/commit/b7a21f2d6fa73f932e9d01874936e5b6b32503fb
> <
> https://github.com/apache/tomcat/commit/b7a21f2d6fa73f932e9d01874936e5b6b32503fb
> >
> >
> > Tomcat Change Log:
> >
> > 66442 <https://bz.apache.org/bugzilla/show_bug.cgi?id=66442>: When an
> > HTTP/2 response must not include a body, ensure that the end of stream
> > flag is set on the headers frame and that no data frame is sent. (markt)
> >
> >
> >
> > You can see the fist request does not complete at all:
> > image.png
> >
> >
> > Can you please check this in firefox 2?  We tried the older version of
> > firefox 2 same issue.
>
> Do you really mean "Firefox 2" as in "Firefox Version 2" from 2006?
>
> I wouldn't expect Firefox 2 to be able to use HTTP/2 at all.
>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

2023-03-07 Thread Bhavesh Mistry

Hi Mark Thomas and Tomcat Team,

We have a strange issue with Tomcat 9.0.72.  All 204 response does not
complete in firefox.  It works in the Chrome browser.  If we downgrade
the tomcat
version is less than .72. Everything works on all browsers.


https://github.com/apache/tomcat/commit/b7a21f2d6fa73f932e9d01874936e5b6b32503fb

Tomcat Change Log:

66442 : When an
HTTP/2 response must not include a body, ensure that the end of stream flag
is set on the headers frame and that no data frame is sent. (markt)



You can see the fist request does not complete at all:
[image: image.png]


Can you please check this in firefox 2?  We tried the older version of
firefox 2 same issue.

[image: image.png]

Thanks,

Bhavesh

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-13 Thread Bhavesh Mistry

Hi Christopher,

Thanks for the suggestion. But I don't have the luxury of using a Load
balancer or Proxy.  I kind of agree that it would be best to handle outside
tomcat.

At this point, it is working as expected after all changes mentioned in the
thread.  Again, I value your opinion and feedback.

Thanks,

Bhavesh



On Mon, Oct 10, 2022 at 7:59 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Bhavesh,
>
> On 10/10/22 22:05, Bhavesh Mistry wrote:
> > I figured out the issue by default *mapperContextRootRedirectEnabled is
> > true* hence it was redirecting it.  By setting it false, I was able to
> get
> > controller to filter.
> >
> >  >
> > Mark and everyone thanks for your help!
>
> At the risk of complicating things, if I were you I would handle this
> completely outside of Tomcat. You may not already be using a
> load-balancer, reverse-proxy, or WAF, but IMHO that's the best place to
> do this kind of thing.
>
> In order to do this in Tomcat, you have had to change a few settings and
> one of them -- the one which enforces CONFIDENTIAL transport -- may be
> more easily bypassed within your application than when allowing Tomcat
> to do it for you.
>
> BTW, OPTIONS requests are used for pre-flight AJAX requests. You may
> break your application by disabling OPTIONS. (Also note that
> lb/rev-proxy/WAF can be configured to respond to OPTIONS requests rather
> trivially, and you can still refuse them from your application servers.)
>
> Hope that helps,
> -chris
>
> > On Mon, Oct 10, 2022 at 1:56 PM Bhavesh Mistry <
> mistry.p.bhav...@gmail.com>
> > wrote:
> >
> >> Hi Mark ,
> >>
> >> Thank you for your feedback.  I have made all the changes needed and it
> is
> >> working as expected except for ONE use case where the servlet context
> path
> >> does not end with */*.  When server context path is given without /
> >> ('/versa'), tomcat seems to do 302 redirect to automatically  '/versa/'.
> >> How can I change this behavior so that the OPTIONS method returns 405
> from
> >> the filter instead of tomcat auto-redirecting to the context path?
> >>
> >> curl -i -k -X OPTIONS http://10.43.243.8*/versa*
> >> HTTP/1.1 302
> >> Location: /versa/
> >> Transfer-Encoding: chunked
> >>
> >> curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
> >> HTTP/1.1 405
> >> Cache-Control: private
> >> Content-Length: 0
> >>
> >>
> >>
> >> Here is the updated web.xml security containers:
> >>
> >>  
> >>  
> >>  HTTPSOnly
> >>  /*
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>
> >> Thanks in advance for your help.
> >>
> >> Thanks,
> >>
> >> Bhavesh
> >>
> >>
> >>
> >>
> >> On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas  wrote:
> >>
> >>> On 07/10/2022 19:47, Bhavesh Mistry wrote:
> >>>> Hi Mark,
> >>>>
> >>>> Thank you for your quick response.  Your proposed solution works by
> >>>> removing the transport-guarantee element.  Another quick question, I
> >>> have
> >>>> Connection has a property called allowTrace method. Is it possible to
> >>>> configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT
> rather
> >>>> than having custom logic at the application level?
> >>>
> >>> No.
> >>>
> >>>>   Do you think it good idea to have Connector Config which method to
> >>> allow and disallow?
> >>>
> >>> No.
> >>>
> >>> I don't think it is a good idea to have an option to disable TRACE at
> >>> the connector level. I'd be quite happy to remove that feature but I'm
> >>> fairly sure I would not be able to get consensus to do that.
> >>>
> >>> My understanding is that TRACE got its poor reputation due to a
> >>> misbehaving browser. Rather than pressure the browser vendor to fix
> >>> their broken browser, the security community decided to pressure the
> >>> server community to disable the functionality the browser didn't handle
> >>> properly. That just seems backwards to me no matter how big the
> >>> browser's market share might have been at the time and how reluctant to
> >>> change the vendor was.
> >>

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-10 Thread Bhavesh Mistry

I figured out the issue by default *mapperContextRootRedirectEnabled is
true* hence it was redirecting it.  By setting it false, I was able to get
controller to filter.


wrote:

> Hi Mark ,
>
> Thank you for your feedback.  I have made all the changes needed and it is
> working as expected except for ONE use case where the servlet context path
> does not end with */*.  When server context path is given without /
> ('/versa'), tomcat seems to do 302 redirect to automatically  '/versa/'.
> How can I change this behavior so that the OPTIONS method returns 405 from
> the filter instead of tomcat auto-redirecting to the context path?
>
> curl -i -k -X OPTIONS http://10.43.243.8*/versa*
> HTTP/1.1 302
> Location: /versa/
> Transfer-Encoding: chunked
>
> curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
> HTTP/1.1 405
> Cache-Control: private
> Content-Length: 0
>
>
>
> Here is the updated web.xml security containers:
>
> 
> 
> HTTPSOnly
> /*
> 
> 
> 
> 
> 
> 
> 
>
> Thanks in advance for your help.
>
> Thanks,
>
> Bhavesh
>
>
>
>
> On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas  wrote:
>
>> On 07/10/2022 19:47, Bhavesh Mistry wrote:
>> > Hi Mark,
>> >
>> > Thank you for your quick response.  Your proposed solution works by
>> > removing the transport-guarantee element.  Another quick question, I
>> have
>> > Connection has a property called allowTrace method. Is it possible to
>> > configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
>> > than having custom logic at the application level?
>>
>> No.
>>
>> >  Do you think it good idea to have Connector Config which method to
>> allow and disallow?
>>
>> No.
>>
>> I don't think it is a good idea to have an option to disable TRACE at
>> the connector level. I'd be quite happy to remove that feature but I'm
>> fairly sure I would not be able to get consensus to do that.
>>
>> My understanding is that TRACE got its poor reputation due to a
>> misbehaving browser. Rather than pressure the browser vendor to fix
>> their broken browser, the security community decided to pressure the
>> server community to disable the functionality the browser didn't handle
>> properly. That just seems backwards to me no matter how big the
>> browser's market share might have been at the time and how reluctant to
>> change the vendor was.
>>
>> CONNECT returns 405 by default in a Servlet container and none of TRACE,
>> OPTIONS or HEAD are inherently unsafe.
>>
>> Mark
>>
>>
>> >
>> > Thanks,
>> >
>> > Bhavesh
>> >
>> > On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas  wrote:
>> >
>> >> On 07/10/2022 18:09, Bhavesh Mistry wrote:
>> >>> Hi Tomcat Team,
>> >>>
>> >>> We have a unique situation.  We wanted to block ALL *OPTIONALS* HTTP
>> >> method
>> >>> on port 80 and 443.
>> >>>
>> >>> We have connector definitions as follows:
>> >>>
>> >>>
>> >>>   > >>>  port="8080" protocol="HTTP/1.1"
>> >>>  connectionTimeout="2"
>> >>>  redirectPort="8443" />
>> >>>   -->
>> >>>   -->
>> >>>   > >>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> >>>  relaxedPathChars="[\\]^`{|}"
>> >> relaxedQueryChars="[\\]^`{|}"
>> >>>  address="${tomcat.address}" minSpareThreads="100"
>> >>>maxThreads="200" SSLEnabled="true"
>> >>>  scheme="https" secure="true" maxSwallowSize="-1"
>> >>> maxPostSize="-1">
>> >>>   > >> className="org.apache.coyote.http2.Http2Protocol"
>> >>> readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
>> >>>   overheadContinuationThreshold="0" overheadDataThreshold="0"
>> >>> overheadWindowUpdateThreshold="0"/>
>> >>>
>> >>>   
>> >>>
>> >>> and we have an application filter to block and return 4

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-10 Thread Bhavesh Mistry

Hi Mark ,

Thank you for your feedback.  I have made all the changes needed and it is
working as expected except for ONE use case where the servlet context path
does not end with */*.  When server context path is given without /
('/versa'), tomcat seems to do 302 redirect to automatically  '/versa/'.
How can I change this behavior so that the OPTIONS method returns 405 from
the filter instead of tomcat auto-redirecting to the context path?

curl -i -k -X OPTIONS http://10.43.243.8*/versa*
HTTP/1.1 302
Location: /versa/
Transfer-Encoding: chunked

curl -i -k -X OPTIONS http://10.43.243.8*/versa/*
HTTP/1.1 405
Cache-Control: private
Content-Length: 0



Here is the updated web.xml security containers:



HTTPSOnly
/*








Thanks in advance for your help.

Thanks,

Bhavesh




On Fri, Oct 7, 2022 at 12:06 PM Mark Thomas  wrote:

> On 07/10/2022 19:47, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > Thank you for your quick response.  Your proposed solution works by
> > removing the transport-guarantee element.  Another quick question, I have
> > Connection has a property called allowTrace method. Is it possible to
> > configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
> > than having custom logic at the application level?
>
> No.
>
> >  Do you think it good idea to have Connector Config which method to
> allow and disallow?
>
> No.
>
> I don't think it is a good idea to have an option to disable TRACE at
> the connector level. I'd be quite happy to remove that feature but I'm
> fairly sure I would not be able to get consensus to do that.
>
> My understanding is that TRACE got its poor reputation due to a
> misbehaving browser. Rather than pressure the browser vendor to fix
> their broken browser, the security community decided to pressure the
> server community to disable the functionality the browser didn't handle
> properly. That just seems backwards to me no matter how big the
> browser's market share might have been at the time and how reluctant to
> change the vendor was.
>
> CONNECT returns 405 by default in a Servlet container and none of TRACE,
> OPTIONS or HEAD are inherently unsafe.
>
> Mark
>
>
> >
> > Thanks,
> >
> > Bhavesh
> >
> > On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas  wrote:
> >
> >> On 07/10/2022 18:09, Bhavesh Mistry wrote:
> >>> Hi Tomcat Team,
> >>>
> >>> We have a unique situation.  We wanted to block ALL *OPTIONALS* HTTP
> >> method
> >>> on port 80 and 443.
> >>>
> >>> We have connector definitions as follows:
> >>>
> >>>
> >>>>>>  port="8080" protocol="HTTP/1.1"
> >>>  connectionTimeout="2"
> >>>  redirectPort="8443" />
> >>>   -->
> >>>   -->
> >>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >>>  relaxedPathChars="[\\]^`{|}"
> >> relaxedQueryChars="[\\]^`{|}"
> >>>  address="${tomcat.address}" minSpareThreads="100"
> >>>maxThreads="200" SSLEnabled="true"
> >>>  scheme="https" secure="true" maxSwallowSize="-1"
> >>> maxPostSize="-1">
> >>>>> className="org.apache.coyote.http2.Http2Protocol"
> >>> readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
> >>>   overheadContinuationThreshold="0" overheadDataThreshold="0"
> >>> overheadWindowUpdateThreshold="0"/>
> >>>
> >>>   
> >>>
> >>> and we have an application filter to block and return 405.  This works
> >> for
> >>> HTTPS port 443.  But request going to HTTP port 80 always get
> redirected
> >>> regardless of the method.
> >>>
> >>> curl -i -k -X OPTIONS http://10.43.243.8/versa/
> >>> *HTTP/1.1 302*
> >>> Cache-Control: private
> >>> Location: https://10.43.243.8/versa/
> >>> Content-Length: 0
> >>> Date: Fri, 07 Oct 2022 16:58:27 GMT
> >>> Server: Versa Director
> >>>
> >>> curl -i -k -X OPTIONS https://10.43.243.8/versa/
> >>> *HTTP/2 405*
> >>> cache-control: private
> >>> content-length:

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-07 Thread Bhavesh Mistry

Hi Mark,

Thank you for your quick response.  Your proposed solution works by
removing the transport-guarantee element.  Another quick question, I have
Connection has a property called allowTrace method. Is it possible to
configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
than having custom logic at the application level?  Do you think it good
idea to have Connector Config which method to allow and disallow?

Thanks,

Bhavesh

On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas  wrote:

> On 07/10/2022 18:09, Bhavesh Mistry wrote:
> > Hi Tomcat Team,
> >
> > We have a unique situation.  We wanted to block ALL *OPTIONALS* HTTP
> method
> > on port 80 and 443.
> >
> > We have connector definitions as follows:
> >
> >
> >   > port="8080" protocol="HTTP/1.1"
> > connectionTimeout="2"
> > redirectPort="8443" />
> >  -->
> >  -->
> >   > protocol="org.apache.coyote.http11.Http11NioProtocol"
> > relaxedPathChars="[\\]^`{|}"
> relaxedQueryChars="[\\]^`{|}"
> > address="${tomcat.address}" minSpareThreads="100"
> >   maxThreads="200" SSLEnabled="true"
> > scheme="https" secure="true" maxSwallowSize="-1"
> > maxPostSize="-1">
> >   className="org.apache.coyote.http2.Http2Protocol"
> > readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
> >  overheadContinuationThreshold="0" overheadDataThreshold="0"
> > overheadWindowUpdateThreshold="0"/>
> >
> >  
> >
> > and we have an application filter to block and return 405.  This works
> for
> > HTTPS port 443.  But request going to HTTP port 80 always get redirected
> > regardless of the method.
> >
> > curl -i -k -X OPTIONS http://10.43.243.8/versa/
> > *HTTP/1.1 302*
> > Cache-Control: private
> > Location: https://10.43.243.8/versa/
> > Content-Length: 0
> > Date: Fri, 07 Oct 2022 16:58:27 GMT
> > Server: Versa Director
> >
> > curl -i -k -X OPTIONS https://10.43.243.8/versa/
> > *HTTP/2 405*
> > cache-control: private
> > content-length: 0
> > date: Fri, 07 Oct 2022 16:58:51 GMT
> >
> > We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat
> > internally  (via connector) redirects requests without application code.
> > How can I achieve blocking OPTIONS, TRACE, and CONNECT  HTTP methods on
> > port 80 while redirect is ON for the connector?
> >
> > Any pointers or help is greatly appreciated.
>
> Tomcat only redirects http to https as the result of an application
> defined transport-guarantee element in web.xml.
>
> Security constraints get processed before Filters.
>
> You can't change the either of the above.
>
> What you could do, is remove the transport-guarantee from web.xml and
> perform the http to https redirect in your Filter. Then you'd have the
> option to return 405 instead of the redirect.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-07 Thread Bhavesh Mistry

Hi Tomcat Team,

We have a unique situation.  We wanted to block ALL *OPTIONALS* HTTP method
on port 80 and 443.

We have connector definitions as follows:



-->
-->





and we have an application filter to block and return 405.  This works for
HTTPS port 443.  But request going to HTTP port 80 always get redirected
regardless of the method.

curl -i -k -X OPTIONS http://10.43.243.8/versa/
*HTTP/1.1 302*
Cache-Control: private
Location: https://10.43.243.8/versa/
Content-Length: 0
Date: Fri, 07 Oct 2022 16:58:27 GMT
Server: Versa Director

curl -i -k -X OPTIONS https://10.43.243.8/versa/
*HTTP/2 405*
cache-control: private
content-length: 0
date: Fri, 07 Oct 2022 16:58:51 GMT

We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat
internally  (via connector) redirects requests without application code.
How can I achieve blocking OPTIONS, TRACE, and CONNECT  HTTP methods on
port 80 while redirect is ON for the connector?

Any pointers or help is greatly appreciated.

Thanks,

Bhavesh

Re: Tomcat Large Payload Truncated

2020-06-29 Thread Bhavesh Mistry

Hi Mark,

Thank you for responding.  I have one more question.  This is spring-boot 2
application REST API server and it does not accept Cookie or session
(timeout is set to zero).Auth happens through Authorized header. We
have set 10mb for maxPostSize.  Does maxSavePostSize takes precedence over
maxPostSize ?  I will set maxSavePostSize to -1 to disable it.

Also, I have another question.  When Payload is as large as 10mb (json
post),  does payload body in JVM MEMORY or offloaded to FileInputStream ?


Thanks, a lot for your help!

Thanks,

Bhavesh

Tomcat Large Payload Truncated

2020-06-28 Thread Bhavesh Mistry

Hi All,


I am running embedded *tomcat*-embed-core-9.0.36.jar and large payload
*179292* and HTTPS 1.1 traffic.  When I use curl command with
transfer encoding or without, both request JSON payload is truncated, and
the application can not parse it.  The smaller payload works fine.


Both small payload and large payload I see the following exception when I
run tomcat in debug mode. Can this Exception truncate payload silently?  I
have been struggling to find you why this is behavior.  I would
appreciate any help you can provide.  Thanks, a lot in advance.



Thanks,
Bhavesh




> PUT  HTTP/1.1

> Host: 10.40.216.165:9182

> User-Agent: curl/7.64.1

> Accept: */*

> Content-Type: application/json

> Content-Length: *179292*

> Expect: 100-continue

>

< HTTP/1.1 100

* We are completely uploaded and fine

< HTTP/1.1 400

< accept: */*

< Accept-Encoding: deflate

< Allow: GET, POST, OPTIONS, HEAD

< Response-Time: Sun, 28 Jun 2020 12:6:56 PDT

< Vary: Accept-Encoding

< X-Content-Type-Options: nosniff

< X-XSS-Protection: 1; mode=block

< Cache-Control: no-cache, no-store, max-age=0, must-revalidate

< Pragma: no-cache

< Expires: 0

< Strict-Transport-Security: max-age=31536000 ; includeSubDomains

< X-Frame-Options: DENY

< Content-Type: text/json

< Transfer-Encoding: chunked

< Date: Sun, 28 Jun 2020 19:06:56 GMT

< Connection: close

<

{"errors": {"error": [{"error-message": "*end of file*", "error-urlpath":
"", "error-tag": "malformed-message"}]}}

* Closing connection 0

* TLSv1.2 (OUT), TLS alert, close notify (256):



*Exception:*


[28-Jun-2020
11:58:11.507][DEBUG][tomcat-exec-19][org.apache.tomcat.util.net.SocketWrapperBase]
Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@36f89cdc
:org.apache.tomcat.util.net.SecureNioChannel@63fc40b8:java.nio.channels.SocketChannel[connected
local=SDWAN-VOAE1/10.40.216.165:9182 remote=/10.10.10.10:62131]], Read from
buffer: [0]

[28-Jun-2020
11:58:11.539][DEBUG][tomcat-exec-19][org.apache.tomcat.util.net.NioEndpoint]
Socket: [org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@36f89cdc
:org.apache.tomcat.util.net.SecureNioChannel@63fc40b8:java.nio.channels.Soc*ketChannel[connected
local=SDWAN-VOAE1/10.40.216.165:9182 
remote=/10.10.10.10:62131]], Read direct from socket: [15489]*

*[28-Jun-2020
11:58:11.541][DEBUG][tomcat-exec-19][org.apache.tomcat.util.net.jsse.JSSESupport]
Error trying to obtain a certificate from the client*

*javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated*

* at
java.base/sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:558)*

* at
org.apache.tomcat.util.net.jsse.JSSESupport.getPeerCertificateChain(JSSESupport.java:106)*

* at
org.apache.coyote.AbstractProcessor.populateSslRequestAttributes(AbstractProcessor.java:779)*

at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:482)

at org.apache.coyote.Request.action(Request.java:432)

at org.apache.catalina.connector.Request.getAttribute(Request.java:892)

at org.apache.catalina.connector.Request.getAttributeNames(Request.java:961)

at
org.apache.catalina.connector.RequestFacade.getAttributeNames(RequestFacade.java:298)

at
javax.servlet.ServletRequestWrapper.getAttributeNames(ServletRequestWrapper.java:96)

at
javax.servlet.ServletRequestWrapper.getAttributeNames(ServletRequestWrapper.java:96)

at
javax.servlet.ServletRequestWrapper.getAttributeNames(ServletRequestWrapper.java:96)

at
javax.servlet.ServletRequestWrapper.getAttributeNames(ServletRequestWrapper.java:96)

at
javax.servlet.ServletRequestWrapper.getAttributeNames(ServletRequestWrapper.java:96)

at
org.apache.camel.http.common.DefaultHttpBinding.populateAttachments(DefaultHttpBinding.java:304)

at
org.apache.camel.http.common.DefaultHttpBinding.readBody(DefaultHttpBinding.java:217)

at
org.apache.camel.http.common.DefaultHttpBinding.readRequest(DefaultHttpBinding.java:115)

at org.apache.camel.http.common.HttpMessage.(HttpMessage.java:55)

at
org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:188)

at org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:80)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

at
org.springframework.web.multipart.support.MultipartFilter.doFilterInternal(MultipartFilter.java:125)

at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)

at
org.apache.catalina.filters.RemoteIpFilter.doFilter(RemoteIpFilter.java:904)

at
org.apache.catalina.filters.RemoteIpFilter.doFilter(RemoteIpFilter.java:961)

at

Tomcat 9.0.31 Invalid character found in the request target

2020-03-04 Thread Bhavesh Mistry

Hi Tomcat Team,

When there is invalid characters, it return error message with
stacktrace as shown below.  1) is there any way to costmize error
message ? if yes, please let me know.

2) Is there any way to spress stack-trace being shown on 400 bad request ?

3) Based on Accept header (application/json), can JSON error be
constructed instead of html since client request application/json ?

Thank you for help in advance.

Thanks,

Bhavesh

Request :
===
GET 
/API/?where=type*!*%3d1%20UNION%20SELECT%20version(),null,null,null=true=0=10
HTTP/1.1
Host: 10.192.58.135
Connection: close*Accept: application/json*
Sec-Fetch-Dest: empty
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122
Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9







Response :
=
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1988
Date: Sun, 01 Mar 2020 06:09:41 GMT
Connection: close

HTTP Status 400 – Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad RequestType
Exception ReportMessage Invalid character found in the
request target. The valid characters are defined in RFC 7230 and RFC
3986Description The server cannot or will not process
the request due to something that is perceived to be a client error
(e.g., malformed request syntax, invalid request message framing, or
deceptive request
routing).Exceptionjava.lang.IllegalArgumentException:
Invalid character found in the request target. The valid characters
are defined in RFC 7230 and RFC 3986

org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)

org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)

org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)

org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)

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

org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

java.basejava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

java.basejava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.basejava.lang.Thread.run(Thread.java:834)
Note The full stack trace of the root cause is
available in the server logs.Apache Tomcat
Version X

Re: Tomcat 9.31 PUT/POST Request receiving Partial Data

2020-02-26 Thread Bhavesh Mistry

The response get truncated after 16321 bytes.  Please let me know what is
best way to wait and in order to consume entire request payload.

Thanks,
Bhavesh

On Wed, Feb 26, 2020 at 4:34 PM Bhavesh Mistry 
wrote:

> Hi Tomcat Team,
>
> I have servlet filter for all requests to cache the entire PUT/POST
> Payload.   When content is large 4KB or more, I am getting partial content
> when I read from HttpServletRequest.getInputStream().  But I but 10 seconds
> wait before consuming the input stream, I am getting entire content.  Can
> you please let me know what is the correct way to wait for the entire
> content is ready to consume from the tomcat servlet request input stream?
>
>
> Filter Code:
> If I put Thread.sleep(10) at begin of filter, I am getting full
> content.
>
> @Override
> protected void doFilterInternal(HttpServletRequest httpServletRequest, 
> HttpServletResponse httpServletResponse, FilterChain filterChain) throws 
> ServletException, IOException {
> CachedBodyHttpServletRequest cachedBodyHttpServletRequest = new 
> CachedBodyHttpServletRequest(httpServletRequest);
> filterChain.doFilter(cachedBodyHttpServletRequest, httpServletResponse);
> }
>
> // Wrapper to cache content.
>
> public CachedBodyHttpServletRequest(HttpServletRequest request) throws 
> IOException {
> super(request);
> ServletInputStream inputStream = request.getInputStream();
> final int len = request.getContentLength();
> if (len >= 0) {
> cachedBody = new byte[len];
> ByteStreams.readFully(inputStream, cachedBody);
> } else {
> cachedBody = ByteStreams.toByteArray(inputStream);
> }
> }
>
>
> Thanks,
>
> Bhavesh
>

Tomcat 9.31 PUT/POST Request receiving Partial Data

2020-02-26 Thread Bhavesh Mistry

Hi Tomcat Team,

I have servlet filter for all requests to cache the entire PUT/POST
Payload.   When content is large 4KB or more, I am getting partial content
when I read from HttpServletRequest.getInputStream().  But I but 10 seconds
wait before consuming the input stream, I am getting entire content.  Can
you please let me know what is the correct way to wait for the entire
content is ready to consume from the tomcat servlet request input stream?


Filter Code:
If I put Thread.sleep(10) at begin of filter, I am getting full
content.

@Override
protected void doFilterInternal(HttpServletRequest httpServletRequest,
HttpServletResponse httpServletResponse, FilterChain filterChain)
throws ServletException, IOException {
CachedBodyHttpServletRequest cachedBodyHttpServletRequest = new
CachedBodyHttpServletRequest(httpServletRequest);
filterChain.doFilter(cachedBodyHttpServletRequest, httpServletResponse);
}

// Wrapper to cache content.

public CachedBodyHttpServletRequest(HttpServletRequest request) throws
IOException {
super(request);
ServletInputStream inputStream = request.getInputStream();
final int len = request.getContentLength();
if (len >= 0) {
cachedBody = new byte[len];
ByteStreams.readFully(inputStream, cachedBody);
} else {
cachedBody = ByteStreams.toByteArray(inputStream);
}
}


Thanks,

Bhavesh

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

2019-02-07 Thread Bhavesh Mistry

Hi Chuck,

Thank for your answer and details explanation.  We have requested our
customer to fix the wrong client.  Are there any logs we can see if the
content length does not match?

Once again thanks for your help!

Thanks,
Bhavesh

On Thu, Feb 7, 2019 at 4:03 PM Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com]
> > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length
> Corrupting
> > Parsing logic for Subsequent Request
>
> > I am stating following when you have request/response on the same TCP
> > connection.  for example,
>
> > My understanding (please correct me if my wrong):
>
> It's wrong.  All TCP traffic, including HTTP requests, is a stream of
> bytes.
> There are no indications where one request ends and another starts other
> than the content length in each request.  If the malformed request
> specifies
> a length smaller than the actual content size, the next request will appear
> to start somewhere in the content stream.  Similarly, if the
> request-specified content length is larger than the sent size, the
> connector
> consumes part of the next request as the content of the prior.  There is no
> way for a server to correct this client misbehavior, other than by the
> server administrator disabling keep-alive - with serious performance
> impacts
> for well-mannered clients.  Fix your broken client.
>
>   - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

2019-02-07 Thread Bhavesh Mistry

Hi Mark,

I understand what you are stating the root of issue originated with the
client (wrong client).  I am stating following when you have
request/response on the same TCP connection.  for example,

My understanding (please correct me if my wrong):

Client ---SAME TCP
SOCKET--Server
1)PUT API
Content-Lenght: 419
2)server reads header and content body

 Response 2XX

3)Client Read response.

4)Client SEND GET Request

GET API  HTTP1/1.1
   5) Server reads it (now tomcat reads request GET request
due to the

   position of previous wrong content
)  CAN reset position of reading here?


  6) The server sends 400 with a close
connection.
7) Client Read response.

So, if you look request/response model,  how can tomcat read ahead on PUT
call on a socket the data is not there?



Thanks,

Bhavesh


On Thu, Feb 7, 2019 at 1:51 PM Mark Thomas  wrote:

> On 07/02/2019 20:05, Bhavesh Mistry wrote:
> > Hi Mark,
> >
> > There is no way to validate the END of a request for PUT call and if
> > Content-Lenght does not match what client had sent payload body then
> > rejected it and reset position.
>
> You can't do that. The only way to determine how much data to expect is
> from the content-length header. The server has no way to determine (with
> any certainty) that the client has stopped sending the previous request
> body (or hasn't sent any body at all) and is starting to send a new
> request.
>
> >
> > If content length does match then reject PUT request,
>
> Not possible.
>
> > and then close the
> > connection for PUT call not for subsequent request.   How can you read
> > ahead from TCP socket that does not have data yet for the next request?
>
> The server is going to do a blocking read (this is Servlet I/O so it is
> blocking) for more data. Again, the server has no way of knowing that
> the data that arrives is for a new request rather than the request body
> it was expecting.
>
> >  It
> > request/response model so PUT request processed with wrong content length
> > should not impact the next request.
>
> HTTP doesn't work like that.
>
> >  Another server like Jetty has no issue.
>
> The only way to guarantee that is to disable HTTP keep-alive. And I
> would be amazed if the Jetty folks did that by default.
>
> I suspect what you are seeing are the effects of different read
> timeouts. If the connection times out waiting for the client to send the
> data *before* the client tries to send the next request you'll get the
> behaviour you describe.
>
> The problem is that the server can't differentiate between slow clients
> and misbehaving clients so by lowering the timeout to work-around the
> broken clients you may end up breaking slower clients unintentionally.
>
> As I said, your best solution is to fix the broken client.
>
> Mark
>
> >
> > Our use case:
> > Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring
> boot).
> >
> > The failure on the SAME TCP occurs at tomcat, not at Jetty for the same
> TCP
> > connection.
> >
> >
> > Thanks,
> > Bhavesh
> >
> >
> > On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas  wrote:
> >
> >> On 07/02/2019 18:48, Bhavesh Mistry wrote:
> >>> Hello Tomcat Developers,
> >>>
> >>> I have a unique situation about HTTP Protocol PAYLOAD parsing and
> >>> Content-Length Header.
> >>
> >> There is nothing unique here.
> >>
> >>>  When PUT/POST Content-Length is NOT correct
> >>> (client send wrong Content-Lenght), the tomcat is able to parse the
> >>> request and respond to request with 2xx but subsequent on SAME TCP
> >>> connection fails with corrupted HTTP HEADER.
> >>
> >> As expected.
> >>
> >> Tomcat can't read minds. If the content length header is not correct,
> >> Tomcat can't correctly identify the end of the request so it is going to
> >> read too much / too little and - on a keep-alive connection - the next
> >> request is going to fail.
> >>
> >> There is nothing unusual about this.
> >>
> >> There is no Tomcat bug here.
> >>
> >> You need to fix the broken client so the content-length is correctly
> set.
> >>
> >> You could disable keep-alive connections. That would limit the failures
> >> to the faulty requests but at the cost of reduced performance.
> >>
> >> 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: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

2019-02-07 Thread Bhavesh Mistry

Hi Mark,

There is no way to validate the END of a request for PUT call and if
Content-Lenght does not match what client had sent payload body then
rejected it and reset position.

If content length does match then reject PUT request, and then close the
connection for PUT call not for subsequent request.   How can you read
ahead from TCP socket that does not have data yet for the next request?  It
request/response model so PUT request processed with wrong content length
should not impact the next request.

 Another server like Jetty has no issue.

Our use case:
Client --> Jetty ---> Apache-Camel HTTP Proxy ---> tomcat (Spring boot).

The failure on the SAME TCP occurs at tomcat, not at Jetty for the same TCP
connection.

Thanks,
Bhavesh

On Thu, Feb 7, 2019 at 11:25 AM Mark Thomas  wrote:

> On 07/02/2019 18:48, Bhavesh Mistry wrote:
> > Hello Tomcat Developers,
> >
> > I have a unique situation about HTTP Protocol PAYLOAD parsing and
> > Content-Length Header.
>
> There is nothing unique here.
>
> >  When PUT/POST Content-Length is NOT correct
> > (client send wrong Content-Lenght), the tomcat is able to parse the
> > request and respond to request with 2xx but subsequent on SAME TCP
> > connection fails with corrupted HTTP HEADER.
>
> As expected.
>
> Tomcat can't read minds. If the content length header is not correct,
> Tomcat can't correctly identify the end of the request so it is going to
> read too much / too little and - on a keep-alive connection - the next
> request is going to fail.
>
> There is nothing unusual about this.
>
> There is no Tomcat bug here.
>
> You need to fix the broken client so the content-length is correctly set.
>
> You could disable keep-alive connections. That would limit the failures
> to the faulty requests but at the cost of reduced performance.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

2019-02-07 Thread Bhavesh Mistry

Hello Tomcat Developers,

I have a unique situation about HTTP Protocol PAYLOAD parsing and
Content-Length Header.  When PUT/POST Content-Length is NOT correct (client
send wrong Content-Lenght), the tomcat is able to parse the request and
respond to request with 2xx but subsequent on SAME TCP connection fails
with corrupted HTTP HEADER.

For example, I do following raw HTTP Request to tomcat server with
Content-Lenght: 419 (but Client Does not POST content followed by GET
request it get corrupted) :   If Content-Length is zero for PUT then
request works.   I am attaching sample Spring boot App to reproduce
this issue. With text file and command ( *cat file | nc localhost 8448*)
 Please get back to me ASAP.  Should I file a bug ?   Should PUT reuqest be
BAD REQUEST 400 instead of GET ?

*REQUEST:*
PUT /api/?msg=Test HTTP/1.1
User-Agent: Java/1.8.0_131
X-Real-IP: 96.118.243.182
id: 924
ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a
breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601484
Accept: application/json
CLIENT_IP: 96.119.84.25
usercontext:
eyJ1c2VyTmFtZSI6Im5jc28iLCJ1c2VyUm9sZXMiOlsiUHJvdmlkZXJEYXRhQ2VudGVyQWRtaW4iXSwidGVuYW50TmFtZSI6IiJ9
X-Forwarded-For: 96.118.243.182
X-Forwarded-Proto: https
URI: /nextgen/templates/template-metadata/PostStaging-LBNNPACB81W/override
HTTP_METHOD: PUT
rollback-label: b3f8ec56-33b1-4b27-a64e-5c3d77041332
rollback-comment: ServiceTemplate_b3f8ec56-33b1-4b27-a64e-5c3d77041332
Content-Length: 419
Content-Type: application/json
Host: localhost:8448
Conection: Keep-Alive



GET /api/ HTTP/1.1
HTTP_METHOD: GET
X-Forwarded-For: 96.118.243.182
ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a
X-Real-IP: 96.118.243.182
X-Forwarded-Proto: https
breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601497
override: override-with-referred-template
User-Agent: Java/1.8.0_131
rollback-label: adfb0689-062d-48a2-95ca-f8a9711858f7
Accept: application/json
CLIENT_IP: 96.119.84.25
usercontext:
eyJ1c2VyTmFtZSI6Im5jc28iLCJ1c2VyUm9sZXMiOlsiUHJvdmlkZXJEYXRhQ2VudGVyQWRtaW4iXSwidGVuYW50TmFtZSI6IiJ9
URI:
/nextgen/binddata/templateData/template/PostStaging-LBNNPACB81W/devicegroup/DeviceGroup-LBNNPACB81W
rollback-comment: ServiceTemplate_adfb0689-062d-48a2-95ca-f8a9711858f7
Host: localhost:8448
Connection: Keep-Alive


*RESPONSE:*BMs-MacBook-Pro:gs-spring-boot bmistry$ *cat /tmp/testbody.txt |
nc localhost 8448*
HTTP/1.1 200
Content-Type: application/json;charset=UTF-8
Content-Length: 34
Date: Fri, 01 Feb 2019 19:39:20 GMT

Greetings from Spring Boot ! Test
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 800
Date: Fri, 01 Feb 2019 19:39:20 GMT
Connection: close

HTTP Status 400 – Bad
Requesth1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
p
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}
a {color:black;} a.name {color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad RequestBMs-MacBook-Pro:gs-spring-boot
bmistry$


*ERROR LOGS:*

2019-02-01 11:39:20.387 DEBUG 14931 --- [nio-8448-exec-5]
o.a.coyote.http11.Http11InputBuffer  : Received [PUT /api/?msg=Test
HTTP/1.1

User-Agent: Java/1.8.0_131

X-Real-IP: 96.118.243.182

id: 924

ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a

breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601484

Accept: application/json

CLIENT_IP: 96.119.84.25

usercontext:
eyJ1c2VyTmFtZSI6Im5jc28iLCJ1c2VyUm9sZXMiOlsiUHJvdmlkZXJEYXRhQ2VudGVyQWRtaW4iXSwidGVuYW50TmFtZSI6IiJ9

X-Forwarded-For: 96.118.243.182

X-Forwarded-Proto: https

URI: /nextgen/templates/template-metadata/PostStaging-LBNNPACB81W/override

HTTP_METHOD: PUT

rollback-label: b3f8ec56-33b1-4b27-a64e-5c3d77041332

rollback-comment: ServiceTemplate_b3f8ec56-33b1-4b27-a64e-5c3d77041332

Content-Length: 419

Content-Type: application/json

Host: localhost:8448

Conection: Keep-Alive




GET /api/ HTTP/1.1

HTTP_METHOD: GET

X-Forwarded-For: 96.118.243.182

ACCESS_TOKEN:
30005f625a9401b4f604d95f9c4bdb4451e5f55d6477a8fd7c6524e2a955179a

X-Real-IP: 96.118.243.182

X-Forwarded-Proto: https

breadcrumbId:
ID-vd01-ch2-g-CHCIILNQL06-dse-comcast-net-43208-1546458662158-9-601497

override: override-with-referred-template

User-Agent: Java/1.8.0_131

rollback-label: adfb0689-062d-48a2-95ca-f8a9711858f7

Accept: application/json

CLIENT_IP: 96.119.84.25

usercontext:

Re: OCSP Stapling Configuration and Tomcat 9

OCSP Stapling Configuration and Tomcat 9

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

Re: Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

Tomcat 9 Connector config allowHostHeaderMismatch not working as expected

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

Re: Tomcat Large Payload Truncated

Tomcat Large Payload Truncated

Tomcat 9.0.31 Invalid character found in the request target

Re: Tomcat 9.31 PUT/POST Request receiving Partial Data

Tomcat 9.31 PUT/POST Request receiving Partial Data

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length Corrupting Parsing logic for Subsequent Request

31 matches

Site Navigation

Mail list logo

Footer information