1 2 Previous Next 16 Replies Latest reply on May 18, 2018 9:30 AM by icemaker

    wildfly 10 does not get along with firefox


      Hi, my colleagues and I got a problem with wildfly 10. We developed several web-applications that run without any problems on wildfly 9. But since we patched our servers to version 10.1.0 (happens also with 10.0.0) firefox has problems with loading resources from wildfly. no problems in chrome or internet explorer. But this problem does only occur with wildfly 10. Not with tomcat, not with glassfish and not with wildfly 8 or 9.

      In some cases the css-files won't be loaded and in other cases some image-files. And the problem does always occur with different files. it also occurs pretty randomly so you cannot predict when it happens. But up to now I never had to reload the page more than 6 times to run into the problem. This problem is more or less resolved if we disable the cache in firefox.

      I made 2 screens with at least a little information.


      does anybody know what the problem might be?



      There is also a problem with loading pdf-files in firefox when it comes from wildfly 10. In some cases bold-text parts become blank in the pdf file. Does not occur in chrome and not with wildfly 9. So if I publish my application on wildfly 9 firefox has really no problems at all... we also tested different versions of firefox the current version I am using is 50.1.0 .

        • 1. Re: wildfly 10 does not get along with firefox

          Looking at those images, it looks like your request URLs for those images are essentially a .xhtml. Is there any JSF/servlet involved on the server side for rendering these images? What does that code look like and are you sure you aren't setting any response headers (especially things like Content-Length) while serving these from your application?

          • 2. Re: wildfly 10 does not get along with firefox

            yep, it is jsf with primefaces. But I am using the standard servlet configured with web.xml and I do not change any headers at all. And it is not just the images. In some cases even jsf itself does not get loaded. In these cases the whole site is a blank white sheet. And in other cases only my own css files will not be loaded and the components have no styling anymore. It is totally random. I just picked an example where the problem can obviously be observed with the missing images.


            Here my servlet set in web.xml



                    <servlet-name>Faces Servlet</servlet-name>




            • 3. Re: wildfly 10 does not get along with firefox

              Looking at that attachments again - it looks to me that the server is responding back with 304 response code which essentially translates to "the content represented by this URL hasn't changed and me (as a server) will not send back any content and the client is responsible for rendering with whatever content it has for this resource". Can you add some details about what the request headers look like for some of these resources? Is this WildFly server fronted by some other server like Apache HTTPD? What does its configs look like?

              • 4. Re: wildfly 10 does not get along with firefox

                sorry for the late response...

                I am also aware that this problem should normally be with firefox... but it is still odd that this problem happens only with wildfly 10. I have this error up to now at least after every 3rd reload of the page. And it never happens if I use wildfly 9 or 8.

                Here a Screen from Firefox from the primefaces css-template that was not loaded



                In some cases even the jsf-template itself is not loaded and then I get only a blank white page

                • 5. Re: wildfly 10 does not get along with firefox

                  Looking at that screenshot, I see that the request contains the (standard) "If-Modified-Since" header which tells the server to respond with a "not modified since" response so that the client can serve a cached content. The time being sent in this header value is what will be used by the server to decide how to respond. In this case, it's being sent as 9th Feb 2017, 07:48:29 GMT. What you have to verify is, whether the system time on the server side is correct and whether the client where this browser is running has the right system time. If both of this seems to be fine, then we need to see if there indeed is some bug in handling this header in Undertow.


                  Report back with the details once you verify these setups.

                  • 6. Re: wildfly 10 does not get along with firefox

                    Also, to me it's a bit odd that a request with URI *.xhtml path is being considered for caching in first place. I would have expected it to have a "no-cache" Cache-Control policy applied by the server when it first responded to that request path, assuming that xhtml path is mapped to a (server side) JSF servlet.

                    • 7. Re: wildfly 10 does not get along with firefox

                      This error also happens if I start wildfly 10 on localhost. So unfortuantely it is not the system-time. Here is another example in which the modified-since header is still in 2013 and the server is not sending a response. (my system time is correct.) :-)resourceNotLoaded.PNG

                      • 8. Re: wildfly 10 does not get along with firefox

                        I read up on those request header semantics a bit more and apparently the "If-None-Match" header takes precedence over the "If-Modified-Since" header [1]. Looking at the Undertow code, it does indeed appear to be the case.


                        The "If-None-Match" header value sent in by your browser states that it has cached the content locally (identified by a resource tag) for that resource represented by that URL. The server then compares that tag value with the resource at the URL and since they match, it says, serve your local content (via the 304 header). Which is all expected and good.


                        The mysterious bit is - why has Firefox stored a 0 byte content against that specific resource URL (and some others)? So essentially we need to figure out why was 0 byte content delivered (as a 2xx response) the first time this resource URL was accessed. If you are able to somehow get hold of that details, then we will be closer to solving this.


                        In the meantime, I have to refresh my knowledge and understand what the expectations are, from the spec perspective, when it comes to forcing a no-cache header for JSF backed server side resources.


                        [1] If-Modified-Since - HTTP | MDN

                        • 9. Re: wildfly 10 does not get along with firefox

                          I think there is still a little misunderstanding. What I think is that you think taht these files are always missing in the browser if it happens the first time. but this is not the case a simple reload-action "F5" is in most cases enough to get the resources into the browser again. But if I then press "F5" a few more times another resources are not getting displayed by firefox. E.g. the image in the upper most left. If I deploy the application and load the page the resource is correctly loaded in most cases. If I then click  some links in the application at some point the image is gone as it is displayed in the screenshot of my last post.

                          • 10. Re: wildfly 10 does not get along with firefox

                            So it looks like this is related to Firefox. Did you try if the problem persists when pressing ctrl+F5 (Reload with cache override) instead?

                            • 11. Re: wildfly 10 does not get along with firefox

                              disabling the cache is fixing the issue. But you surely agree that this is a bad fix :-) but seems that this problem should be on the firefox side, correct? But it is still odd that this problem does not occur with wildfly 9...

                              • 12. Re: wildfly 10 does not get along with firefox

                                We got new information on this problem.


                                1. It only occurs if HTTPS-protocol is used. With HTTP everything remains fine.
                                2. if I set "fiddler"-proxy between and let fiddler decrypt the https traffic the problem is also gone. If I disable proxy or proxy-description the problem is back.
                                3. The problem is not directly a cache problem. In some cases firefox just does not seem to get a response at all. the response-param is displayed empty and content length from server response is also said to be "0"
                                4. but the fact that this problem is resolved when using fiddlers decryption option leads me to the concolusion that this problem is definitely with firefox.


                                But the big question now is why is this happening only with wildfly 10 and not with wildfly 9...


                                did you do anything different there?

                                • 13. Re: wildfly 10 does not get along with firefox

                                  If this problem is related with this another thread Problem with  java.nio.channels.ClosedChannelException, increase CPU usage and server goes down, this is a big problem clearly.


                                  I'm currently testing Firefox with HTTP 2 disabled in WildFly 10.1.0 and seems to be fine, maybe HTTP 2 + TLS + wrong handling by Firefox is firing this problem.

                                  1 of 1 people found this helpful
                                  • 14. Re: wildfly 10 does not get along with firefox

                                    Very similar problem happening over here. Wildfly 10 running an application with JSF 2.1.29-01. Works fine on Chrome and keeps hanging on Firefox due to very similar reasons (broken responses regarding javascript and css files and sometimes even java.nio.channels.ClosedChannelException).


                                    However, following santos.zatarain.vera's advice, seems to solve the problem. I turned off HTTP2 and now Firefox seems to be handling my application just right, even with SSL.


                                    Probably, I will also follow what santos.zatarain.vera suggested on another related post (Re: Problem with java.nio.channels.ClosedChannelException, increase CPU usage and server goes down ) and upgrade the libraries regarding undertow in order to maintain a reasonable CPU activity. Thanks for that.

                                    1 2 Previous Next