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