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?
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
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?
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
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.
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.
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 . 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.
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.
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?
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...
We got new information on this problem.
- It only occurs if HTTPS-protocol is used. With HTTP everything remains fine.
- 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.
- 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"
- 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?
1 of 1 people found this helpful
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.
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.