https://bz.apache.org/bugzilla/show_bug.cgi?id=65402

--- Comment #8 from Florian Meister <f...@sfs.com> ---
Thanks for the new log. What I see on both SSE points is:

> 1. The client aborts the requests (RST_STREAM) after commonly 1-2 seconds, > 
> there are 2 requests that last 5 seconds and one with 18 seconds.

Yes. That's me clicking around in the app. After every route change the 2
Eventsources are destroyed and connected again. (I know that's not how it
should be - we are working on it to persist the event-sources during
route-changes in the app)

> 2. All requests produce the response headers and one chunks of body data (525 
> bytes on one endpoint, 447 on the other). Those are sent to the client.

> 3. The HTTP/2 layer does not see a second chunk from the SSE endpoints, until 
> the 30s read timeout happens, then one more chunk is seen.
> 3 indicates that someone is buffering data on the proxy connection, but after 
> 30 seconds, the buffer only contain one more chunk of data (e.g. 447 or 525 
> bytes, not many).
> The SSE sources do not seem to provide data often (is that the intention?). 
> An initial chunk and then silence more or less. However the browser closes 
> the open requests quite aggressively (at least it looks like this, cannot see 
> page reloads).

That's true. When connecting to the SSE endpoint there is some initial payload
- but then we are sending updates only every 30? seconds or when some change is
happening. The closed connections is me navigating through the page (as
described above)

> There is nothing blocking in the HTTP/2 layer per se that I can see. It looks 
> as if the browser detects frequent data to come and is unhappy and the 
> proxied endpoint does not deliver.

Can you clarify that for me - I don't understand the part with "the browser
detects frequent data ..."

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org

Reply via email to