User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
Hi Greg,
At this moment we are receiving multiple error reports from users
who suffer from malfunctioning user interfaces. We already had
received some of those before the weekend but I did not link this to
our move to 9.4.24. Now a pattern is emerging.
They are mostly from Firefox users but some come from Safari users.
The symptoms are consistently similar: missing images, unstyled
content, parts of content missing etc.
We will probably have to revert to the previous Jetty version we
where running (9.4.20) to make sure we do not pick one that behaves
the same. In the meantime I would be happy to do any testing if you
would require so.
Kind regards,
Silvio
On 12/2/19 2:42 PM, Greg Wilkins wrote:
Silvio,
This is the second time I've heard about a
problem fetching browser resources like CSS or js. Can you
attach the stacks you are seeing?
The last few days exceptions have started to come up in the
logging. We can quite easily reproduce them by testing
common parts of our web applications using Firefox. Using
Chrome the same actions do not produce exceptions (or
warnings).
Strangely enough this seems to intermittently fail mostly
(but not exclusively) on plain GET requests for CSS
resources that are requested by the browser as a result of
an @import from another CSS resource.
We serve the files ourselves from a servlet. Perhaps we are
doing something that triggers this? GET requests for which
we serve the response content dynamically seem to work fine.
The same goes for POSTs. Since it only happens via one of
our code paths I suspect we are causing this in some way,
although the code is extremely simple.
Kind regards,
Silvio
On 11/29/19 12:27 AM, Greg Wilkins wrote:
Silvio,
I believe it is ignorable and you can turn the
HttpChannelState logger level down to suppress them.
However, if there a stack trace associated with
that warning then it is not what I think it is and you
need to provide more information.
What I believe is happening is that while a request
is being processed, the associated HTTP/2 stream is
being reset (probably by the client?)
This asynchronous error is detected but because the
request is not async, it cannot be delivered to the
request and instead we warn. This is probably over
verbose as clients can do silly things like close mid
request handling.
Can anyone tell me what this means? I take it the
situation is not
critical because the application has worked flawlessly
for years with
earlier Jetty versions without these messages. Can I
turn this off?
