FAQ
If you're going to use Context in net/http, why not skip the proxy
type and bring the package in as net/context?
On Thu, Oct 15, 2015 at 2:17 PM, Brad Fitzpatrick wrote:
Repeating from the code review, I think we'd be better off adding a field to
http.Request:

package http

// Context is expected to be a golang.org/x/net.Context value.
// If non-nil, it is expected to have compatible methods.
type Context interface{}

type Request {
...
// Context is the optional golang.org/x/net.Context for this request.
Context Context
}

Then we can interface-sniff it to see if it has the Done method:

Done() <-chan struct{}

And use that struct value for the http.Client's cancel channel if the
Request.Cancel field is nil.

But *http.Request is not just for Clients, but also for Servers (as your
proposal is about). A good proposal would involve both.

If some "middleware" is responsible for populate Request.Context on incoming
server requests, then the http Server itself couldn't take advantage of it
being set already and use the context.Done, or cancel the whole request when
the underlying connection goes away or the HTTP/2 stream gets a RST_STREAM.

So we probably want the server to populate the Request.Cancel. But there's
no standard for these things, so it probably needs to be a new hook on
http.Server, like:

package http

type Server struct {
...
// PopulateRequestContext returns a Context for the given Request.
// At this stage, the Request.Body is nil.
// RequestContext may be nil or return nil.
// Server will always set a Context, but if RequestContext returns a
non-nil
// value, that Context becomes its parent context.
RequestContext func(*http.Request) Context



A proposal also needs some sort of vendoring, partial re-implementation, or
registration story for the x/net/context package, for how net/http makes
them to give out.


On Thu, Oct 15, 2015 at 11:32 AM, wrote:

Just wondering about the interest level and any suggested approaches for
adding context.Context-based http handler support?

I submitted a patch that adds a context.Context handler interface to the
existing net/context/ctxhttp
(https://github.com/golang/net/tree/master/context/ctxhttp) package and
looking for some feedback.

The approach:
* First steps in a context.Context http handler world - added to a core
“support” subpackage like ctxhttp
* Control a request - timeout, cancel, store values
* Standardized middleware that require a request context - versus the
constant invention of inoperable handlers. See the different signatures of
the popular mux libraries: goji, martini, gin, httprouter, gorilla, negroni,
and it goes on.
* Optional and compatible - not to compete or break the standard library

Patch: https://go-review.googlesource.com/#/c/15620/
Code diff:
*
https://go-review.googlesource.com/#/c/15620/3/context/ctxhttp/ctxhttp.go
*
https://go-review.googlesource.com/#/c/15620/3/context/ctxhttp/ctxhttp_test.go

--
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase