httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <>
Subject RE: No H2 Window updates!
Date Sat, 28 Nov 2015 12:33:56 GMT

> -----Original Message-----
> From: Stefan Eissing []
> Sent: zaterdag 28 november 2015 13:01
> To:
> 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;
                case APR_EAGAIN:              /* non-blocking read, nothing
there */
                    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,
                                      "h2_session(%ld): terminating",
                        /* Stolen from mod_reqtimeout to speed up lingering
                         * a read timeout happened.
"short-lingering-close", "1");
                    else {
                        /* uncommon status, log on INFO so that we see this
                        ap_log_cerror( APLOG_MARK, APLOG_INFO, status,
                                      "h2_session(%ld): error reading,
                    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.


View raw message