On 06 Oct 2015, at 3:36 PM, Stefan Eissing <[email protected]> wrote:
> FYI: /trunk no longer works with mod_http2. 2.4.x does. I see missing > response data, it seems, so the most likely cause are the changes in filter > handling. Did not find the time to investigate further. > > Please be aware the mod_h2 uses pool/brigade hierarchies in new and > unexpected ways. The request has been processed and EOR bucket has been > handled in another thread, however data/file handles might have been > transferred to the main thread and are being cleaned up when the main > connection thinks a stream is done. If those data gets set aside, the memory > might get freed/reused too early. Maybe mod_http2 needs to come up with its > own EOR buckets on the main connection to allow for cleanup synchronization. > Not sure… I pulled my hair out looking for the exact same problem. It turned out to be a bug in the core where the EOR bucket was being injected directly into the connection filters and thus bypassing request filters containing setaside data. When the EOR bucket “overtakes” other buckets, the data vanishes. The solution is to make sure that the EOR bucket genuinely does get injected at the very end of the request. To do this I found the last internal redirected request (iterate through r->next until r->next is NULL) and injected the EOR bucket into that filter. (I have found a problem where we’re injecting an EOR bucket made out of the last request instead of the main request, will fix that) A quick scan of the modules/http2 directory shows no calls to ap_bucket_eor_create(), I suspect you might be relying on http1.1 functionality to do this in modules/http/http_request.c. Ideally mod_http2 should be choosing the right time to end the request based on the http2 protocol. Regards, Graham —
