- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 27 Apr 2015 16:14:22 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
Dear working group, I would like to get some feedback on understanding of/expectations re timeouts in HTTP/2. The standard is silent on the matter and probably righty so. For my implementation however, choices need to be made and common understanding among server/client implementors might be helpful. My understanding/assumptions: - connection timeouts: should be at least as long as for current HTTP/1 connections. The limit is server resources, otherwise we’d leave it open eternally. * are PING frames expected to prolong the timeouts? has anyone different plans? - stream timeouts: probably necessary to protect server resources. Can occur in two places: * upstream when the END_FLAG is not set (faulty client/proxy) or DATA is streamed to the server and there is virtually no end, just pauses between frames. In the latter case, only the pauses should count? * downstream when the client does not send window updates. The server is buffering memory and maybe has database connections open and waiting for the write. Some timeout needs to be there. For example a browser should not try to pause a download by just not sending window updates any more. - stream timeouts should be in magnitude of current HTTP/1 request timeouts. - stream timeouts should RST the stream with which error code? SETTINGS_TIMEOUT seems to specific. ENHANCE maybe? - connection timeouts should involve a polite GOAWAY - How are these affected by PRIORITY? If a high PRIO stream takes away processing time/bandwidth is there a recommendation how the server should react regarding timeouts on lower prio streams? Has anyone of the many people smarter than me already given this some thought? Any advice appreciated… Cheers, Stefan <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Monday, 27 April 2015 14:15:06 UTC