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 <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 > >