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 <ma...@apache.org> 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 <ma...@apache.org> 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 <ma...@apache.org> 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
---------------------------------------------------------------------
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
