> -----Original Message-----
> From: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Sent: zaterdag 28 november 2015 13:01
> To: dev@httpd.apache.org
> Subject: Re: No H2 Window updates!
>
> I am not really here, but...
>
> the window updates are sent out via update_window(), line 1001,
> h2_session.c. If you do not see any window updates with a client, it may
> be that the server app you called does not read its input. I have
> several test cases with uploads and they work with nghttp and curl.
>
> Basics of mod_http2 flow control:
> - the auto udates of nghttp2 are disabled because nghttp2 would
> continously update the window for the client, letting the client sent
> more and more - until we run out of memory.
> - instead, input reads from workers against the h2_mplx io are recorded
> and lead to regular window update being sent out. So clients can only
> send more when the data is actually consumed by someone.
>From h2_session.c around line 1640.
=======================
switch (status) {
case APR_SUCCESS: /* successful read, reset our idle
timers */
have_read = 1;
wait_micros = 0;
break;
case APR_EAGAIN: /* non-blocking read, nothing
there */
break;
default:
if (APR_STATUS_IS_ETIMEDOUT(status)
|| APR_STATUS_IS_ECONNABORTED(status)
|| APR_STATUS_IS_ECONNRESET(status)
|| APR_STATUS_IS_EOF(status)
|| APR_STATUS_IS_EBADF(status)) {
/* common status for a client that has left */
ap_log_cerror( APLOG_MARK, APLOG_DEBUG, status,
session->c,
"h2_session(%ld): terminating",
session->id);
/* Stolen from mod_reqtimeout to speed up lingering
when
* a read timeout happened.
*/
apr_table_setn(session->c->notes,
"short-lingering-close", "1");
}
else {
/* uncommon status, log on INFO so that we see this
*/
ap_log_cerror( APLOG_MARK, APLOG_INFO, status,
session->c,
APLOGNO(02950)
"h2_session(%ld): error reading,
terminating",
session->id);
}
h2_session_abort(session, status, 0);
goto end_process;
}
===========================
I'm not familiar enough with differences in bucket handling between serf and
httpd to really make the call, but as the serf buckets were designed by the
same group:
I'm guessing that there might be successful reads with different status
values than just APR_SUCCESS.
In serf I would expect to see an immediate APR_EOF when there is only a
single frame to be read (or perhaps a few intermediate APR_EAGAINS and then
a EOF), which may both imply successful reading 0 or more bytes, followed by
their status code.
Bert
