Hi Willy,
2017-11-24 10:43 GMT+01:00 Willy Tarreau <[email protected]>: > So in the end here's what I've done : > > - implemented a new "reject" HTTP action. I initially started with > "close" and while documenting it I noticed it does exactly the same > as the tcp-request "reject" action, and we already have a different > http-response "close" action which enforces a close without killing > the request so I preferred to stay consistent and switch to "reject". > > - remove the special case on the "connection: close" header in the H2 > mux. Now I can authenticate using 401 over the same connection. > > - figured I didn't need to remove "connection: close" from our default > responses anymore so I left them intact (we can't serve them using > keep-alive on H1 anyway) > > - made use of "timeout client-fin" for H2 connections on which we've > already sent a GOAWAY frame, as it's very similar to the closing > shutdown(SHUT_WR) on H1. > > So with all this I think we're good. Great work, 401 is now fine. As for closing the connection, this is what I am seeing with the current code: - "timeout http-keep-alive" is not used - when "timeout client" < "timeout server" and it strikes, we send GOAWAY with last-stream-id set to the real last used stream id. Chrome sends FIN right away and the connection is closed (this behavior seems fine to me) - when "timeout server" < "timeout client" and it strikes, we send FIN and the connection closes (no GOAWAY ever crosses the wire) Either way we don't ever try to shutdown TLS cleanly (send a TLS close notify aka calling ssl_sock_shutw), maybe we should do that instead of send FIN in the "timeout server" case? Which timeout do you have in mind to close an idle HTTP2 connection? Should http-keep-alive be limited to HTTP1? Current behavior does not seem to be perfectly consistent yet between client and server timeout. Also I'm not sure whether a clean TLS shutdown is required. cheers, lukas
