net/http: add http1 and http2 Server IdleTimeout

[bradfitz]

Add http.Server.IdleTimeout to limit the keep-alive idle time for http1 and http2 servers.

[gopherbot]

CL https://golang.org/cl/19159 mentions this issue.

[odeke-em]

If I may ask, this is going to entail us adding MaxIdleTimeout and MaxActiveTimeout to Server, right? And also we'll add defaults as you in have in CL 19159, true?
Or should we just expose a new function IdleTimeoutHook so that it takes these durations which if <= 0 means we should use the default durations?

[gopherbot]

CL https://golang.org/cl/21491 mentions this issue.

[bradfitz]

@odeke-em, the naming here is much easier if we don't consider HTTP/2 and PING frames as activity. Then we'd just call it IdleTimeout and be done with it.

But with HTTP/2, do we care about clients sending a PING or other useless frame every N seconds vs. actually sending real requests every N seconds? If so, we need names for both types of idle (network idle vs no-HTTP-requests idle). Or we define IdleTimeout to mean one thing, and give ReadTimeout the other meaning (see #16958 (comment))?

Opinions welcome. Ideally with sample documentation you'd tell users.

I got as far as:

        // ReadTimeout optionally specifies a maximum duration before                                                                                        
        // timing out reads of request headers. It does not include                                                                                          
        // request bodies. For requests after the first on a                                                                                                 
        // connection, this is timer starts upon receiving the first                                                                                         
        // byte. For keep-alive duration, see IdleTimeout.                                                                                                   
        ReadTimeout  time.Duration

        // IdleTime, is, uh....                                                                                                                              
        IdleTimeout time.Duration

/cc @rhysh @broady @adg @bmizerany

[bradfitz]

/cc @prabrisat1 too.

[freeformz]

// IdleTimeout is the maximum time between requests that a connection 
can stay idle. The timeout starts as soon as a connection is started and 
after each request is finished. It is canceled when a request starts.

[bradfitz]

So PING frames don't count, then? That's a valid answer.

Now that I think about, we should disable the Transport's TCP keep-alive when HTTP/2 is negotiated, since PING frames and TCP keep-alive packets serve the same purpose of keeping the connection alive from NAT timeouts and whatnot.

[freeformz]

WRT request bodies vs request headers ... That does mean a malicious client could send headers fully and then bodies as slowly as possible. I guess though you would use a context with a timeout or the like to protect against that in the handler?

[freeformz]

That probably complicates code though? Should ReadTimeout be canceled after the request's Body is closed, not when the headers are finished being read?

[bradfitz]

WRT request bodies vs request headers ... That does mean a malicious client could send headers fully and then bodies as slowly as possible. I guess though you would use a context with a timeout or the like to protect against that in the handler?

Yes, that's the job of the handler or caller of http.Transport.RoundTrip to guard against. We only give a timeout for headers, since the user isn't in control there.

Should ReadTimeout be canceled after the request's Body is closed, not when the headers are finished being read?

SetReadDeadline is currently only called before a TLS handshake, and before reading request headers, and is never disabled.

So yes, to work similarly to Go 1.0-1.7, we should probably not reset it after the headers and have it apply to the whole request, even if that's slightly odd.

[freeformz]

Can the deadlines (since this is what is currently used) even be reset in the middle of a Read?

[bradfitz]

Why would we be in the middle of a read?

[freeformz]

@bradfitz Actually you wouldn't be AFAICT. Not sure why I thought that earlier (in an internal convo about this issue).

[gopherbot]

CL https://golang.org/cl/31727 mentions this issue.

[gopherbot]

CL https://golang.org/cl/32024 mentions this issue.

[gopherbot]

CL https://golang.org/cl/32230 mentions this issue.

[gopherbot]

CL https://golang.org/cl/32322 mentions this issue.

[gopherbot]

CL https://golang.org/cl/32323 mentions this issue.