https://bz.apache.org/bugzilla/show_bug.cgi?id=62177
--- Comment #4 from Holger Sunke <holger.su...@posteo.de> --- I think itmight be connector independent. Somwhere it must be decided if a new HTTP2-Stream is created with incremented ID. When looking at the net-events.html output from Chrome, it seems like this decision goes wrong (sometimes?) for a nested resource where the referrer is a pushed resource itself. a) showcase.css PUSH PROMISE received in stream ID 1, promised for future stream 2. referrer: selector.xhtml b) perfect-scrollbar.css PUSH PROMISE received in stream ID 1, promised for future stream 4. referrer: selector.xhtml c) lato-black-webfont.eot font file PUSH PROMISE received in stream ID 2, promised for future stream 6. referrer: (!)showcase.css(!) It seemes very important that PUSH PROMISEs are sent in odd IDed stream in response to browser request stream with even ID. In (c) Chrome detects that a PUSH PROMISE is incoming on Stream ID 2 which is an even ID while an odd one is expected. Chrome than runs around screaming "FIRE! FIRE!" and closes the window (aka connection) which triggers subsequent write attempts on closed streams server side with plenty exceptions logged (one exception per ressource pushing Thread). So it also seemes that PUSH PROMISEs with subsequent Ressource push transmission are treated as "fake" inbound HTTP request in a separate http connector Thread. Let this be the algorithm: I) Incoming (fake or real) HTTP/2 request with stream ID x II) Open new Stream on current SSL connection with ID=x+1 to transmit PUSH PROMISEs. This is also what happens when showcase.css promised in (a) starts to get transmitted: The Thread recognizes there are additional resources referenced in showcase.css to be pushed, and does (II) while current Stream ID is still x=1 (if the thread is fast enough and no other thread does incremets before it). So the ID gets incremeted to 2 and subsequent PUSH PROMISEs get transmitted in illegal even stream id 2. BTW: Firefox seems to be mor tolerant against this and does request retries so that the Page displays correctly at some point in time, still leaving several Exceptions in server log. Chrome instantly enters panic mode and disconnects. This is all guesses only without viewing the source code. I'm not sure what the correct fix is here. Maybe we have to give step (II) awareness about if this is currently a "fake" request and/or that PUSH PROMISES must be sent in stream 1 or without ID incremet. Are new Streams created in Connector classes or is it Servlet 4 specific code? And a bit off topic: Does ServerPush also work with AJP when frontend HTTP server uses SSL over HTTP2? Kind regards. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
