net/http: add CloseNotifier

[gopherbot]

by blake.mizerany:

Per email from Brad:

It looks like what you don't actually care about owning the TCP connection and ideally
just want something like:

 var clientClosed chan bool
 cn, ok := w.(http.CloseNotifier)
 if ok {
     clientClosed = cn.CloseChannel() // returns a chan bool, written to when/if this http request is closed
 }

 select {
  case <-clientClosed:
     // cancel expensive stuff
  case ....
  }

https://groups.google.com/d/topic/golang-nuts/PcEvewBB-AQ/discussion

[bradfitz]

Comment 1:

Russ, any objections?  I've now seen this request several times in different forms,
including from Blake again just now.
It'd be an optional interface, like Hijacker.

Owner changed to @bradfitz.

Status changed to Accepted.

[rsc]

Comment 2:

doesn't seem like we want to encourage people to depend on it,
but i guess it's fine.

[bradfitz]

Comment 3:

So, I implemented this, but now I'm not sure how I feel about it.  I thought it'd be
prettier.
http://golang.org/cl/5453063
I think this could all be implemented outside of the http package (by providing an
http.Server with a wrapper Listener which returns wrapped Conns which do this magic).  I
think.
But then we could keep the ugliness and complexity out the core.

Status changed to Thinking.

[gopherbot]

Comment 4 by blake.mizerany:

I'm trying to wrap my head around wrapper that returns wrappers.

[bradfitz]

Comment 5:

Think of it as a net.Listener than returns net.Conns then, deferring to a tcp listener
and tcp conn for most the work, except for bookkeeping which connections are being
handled by which handlers.
Then you'd need a new Handler wrapper that works with your wrapped connections.  As
inspiration, see http://golang.org/pkg/http/#TimeoutHandler

[rsc]

Comment 6:

this is straying pretty far from http.
why not just hijack the connection?

[rsc]

Comment 7:

Or just Hijack the connection.

[gopherbot]

Comment 8 by blake.mizerany:

I'm not against that, at all. The problem, well, inconvenience, comes
when I can no longer take advantage of all the work the underlying
object of http.ResponseWriter was doing because it no longer allows
writes after a hijacking.  I find myself copy and pasting <ducks> code
from Go's src (i.e. WriteHeader).
One way around this is to factor out the convenience methods into a public API.

[rsc]

Comment 9:

But a public API for what?  You're really not speaking HTTP anymore,
and it is unclear that these kinds of helpers for this non-HTTP protocol
belong in the HTTP library.  As soon as there is a proxy in the middle
the semantics of your server break badly.
Since the client has to know about this magic anyway, it seems
cleaner to hijack the connection and switch to a simpler custom
protocol.
Russ

[gopherbot]

Comment 10 by blake.mizerany:

I'm still speaking HTTP. It's knowing when the connection drops that
is important when doing expensive things. I need to cancel those
expensive things if the connection drops.
That doesn't mean I'm no longer speaking HTTP. It's that in a lot of
cases, I don't know what the proper status code is until the expensive
work has completed in some way.
For example:
     go func() {
        errCh <- somethingLongRunning(closedCh)
     }()
     select {
     case err := <-errCh:
       if err != nil {
         http.Error(w, err.String(), 500);
       }
     }
If I have to Hijack, I can no longer use anything convenient in the
http package, even though I'm still speaking HTTP, because they all
take the http.ResponseWriter, or are on it; and that is now rejecting
all calls to any method.
-b

[gopherbot]

Comment 11 by blake.mizerany:

Just realized I don't need that select, like I did when I first wrote
the example; but you get the picture.

[rsc]

Comment 12:

Labels changed: added priority-later.

[bradfitz]

Comment 13:

I forgot to mention it earlier, but while implementing this, I realized it's very much
related to implementing HTTP/1.1 pipelining.   In both cases we need to listen for
writes from the client while the ServeHTTP function is running.  Currently we run
ServeHTTP in the same goroutine, which has this comment before it:
                // HTTP cannot have multiple simultaneous active requests.[*]
                // Until the server replies to this request, it can't read another,
                // so we might as well run the handler in this goroutine.
                // [*] Not strictly true: HTTP pipelining.  We could let them all process
                // in parallel even if their responses need to be serialized.
                handler.ServeHTTP(w, w.req)
I'd like to also support pipelining at some point (though SPDY is better).
I do agree with Blake, though, that he's not requesting something crazy or non-HTTP-ish.
 We do tell people often that the reason you can't kill goroutines is because you're
supposed to send an exit message on a channel to a goroutine instead, telling it to
stop.  That's what this bug is about:  letting the HTTP server tell a ServeHTTP
goroutine that if it's doing something expensive that it can stop.  It's not about
whether it's streaming it or what output format it's sending, or whether the request
will ever end.

[rsc]

Comment 14:

I am still skeptical.  If you depend on knowing when the
connection drops, then a proxy in the middle will change
the behavior, since it presumably won't drop the connection.
Russ

[bradfitz]

Comment 15:

It's not for correctness.  It's an optimization to stop doing something expensive if
possible.