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