Skip to content

Conversation

bmarini
Copy link
Contributor

@bmarini bmarini commented Apr 2, 2018

This is a step towards deprecating the context argument in favor of using request.Context() directly.

@bmarini bmarini requested a review from danilotsr April 3, 2018 16:51
value := e(r)

ctx = httpx.WithHeader(ctx, h.key, value)
r = r.WithContext(ctx)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this is overriding r.Context with the argument ctx, so would it be possible to loss data configured in the previous r.Context instance? What if the server made r.Context cancelable for instance?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, that's a good point. The assumption is that at all times the ctx passed into ServeHTTPContext will be the same object as r.Context(). They start off as the same object in the background middleware, and with this change, they would stay the same object.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this change, we could support using our httpx middleware with a regular http.Handler such as mux.Router like this #100

And eventually deprecate the ServeHTTPContext interface. I'm just playing with some ideas here though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the direction here, however I'm concerned this may mask non-intended behavior where there might be two different Context objects here. If httpx handlers can rely on the request's context, then they could simply ignore the ctx arg here during this transition period, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think either way is a risk. An app can have custom middleware that relies on modifying the context passed in or the request context. In our case it is almost certainly relying on the context passed in.

Copy link
Contributor

@danilotsr danilotsr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, let's get this going so that we can move away from passing in a context.Context argument sooner rather than later.

@bmarini bmarini merged commit e2ec3e8 into master Apr 4, 2018
@bmarini bmarini deleted the http-handler-compat branch April 4, 2018 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants