proposal: net/http: thoughts for Go 2.0 #5465
Comments
In http.Client, there should be a uniform way of specifying request headers on the initial request and subsequent requests when following a redirect. Current the Request.Header field is useless if the request might get redirected. See issue #5782. Maybe something like a func(*Request) field in the request, that gets called on this request and each redirected one before it gets sent? |
Related to comment #1, net/http/cookiejar.PublicSuffixList's PublicSuffix method should perhaps return (string, error) instead of (string), in case the PSL implementation is passed non-canonicalized input such as upper-cased "EXAMPLE.COM.AU". Returning an explicit error is probably safer than silently returning a "" that would mean a liberal cookie policy. |
It would be nice to have a handle on when all the goroutines that handle requests have terminated after closing the listener (thereby breaking out of the accept loop) for cases where they are using a shared resource that needs to be cleaned up (e.g. an in-process database that needs to be closed). And maybe a way to force-close all their connections. Especially useful for tests and SIGTERM situations. |
You can do that by counting open connections returned by Listener's Accept: http://play.golang.org/p/sPmvXaR-2M (Disclaimer: I didn't test that code.) Robert |
Summarizing a discussion with fullung@: That version didn't handle multiple calls to Close and had a (likely irrelevant) ReadWrite/Close race condition. The corrected version is here: http://play.golang.org/p/WTKa021ipJ |
Summarizing a discussion with fullung@: That version didn't handle multiple calls to Close and had a (likely irrelevant) ReadWrite/Close race condition. The corrected version is here: http://play.golang.org/p/WTKa021ipJ |
We have http.StripPrefix which modifies Request.URL.Path and passes the modified request to a handler. We also have http.Redirect, which assumes that Request.URL.Path is absolute. Thus, if one tries to use http.Redirect within a handler that is wrapped in http.StripPrefix the redirect will point to a wrong URL. In fact, we don't use http.Redirect in http.FileServer for this very reason: https://code.google.com/p/go/source/browse/src/pkg/net/http/fs.go#339 We could abandon StripPrefix and have another way of passing the prefix to handlers. We could also keep the original path and the possibly-shortened path in request, so that redirect could use the original path. |
Comment 14 by nigel.tao.gnome: Make http.Server recovering from panics opt-in instead of opt-out. https://groups.google.com/forum/#!msg/golang-dev/rXs4TG1gdXw/7BQ29S4NPrgJ |
I wish there was a way to delegate URL path subtrees to another handler in a way where recipient doesn't have to specifically understand the whole path, but can still easily do redirects and such. A convention for "this is the unprocessed part of the path". For example, try using the same handler for Right now, mutating |
Only partially related (it belongs more in the scheduler/netpoller) but since net/http has ListenAndServe* I'll add it here: integrate support for REUSEPORT in the netpoller (i.e. open multiple listening sockets on the same port -one for proc?- and accept() on multiple procs) |
@nhooyr, it would break code like this: https://play.golang.org/p/Z3HSnulUDJR (not uncommon in tests) |
The compiler auto converting/wrapping return types to the proper accepted
interface would fix this problem, and make code a lot cleaner.
…On Mon, May 7, 2018 at 12:24 PM Brad Fitzpatrick ***@***.***> wrote:
@nhooyr <https://github.com/nhooyr>, it would break code like this:
https://play.golang.org/p/Z3HSnulUDJR
(not uncommon in tests)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5465 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABLfW9ZIUSf6ahvGNY85d4EVlj5PEq9Kks5twIM6gaJpZM4F0slU>
.
|
@docmerlin, the compiler implements the language spec, so you're proposing a language change, which is way out of scope for this particular bug. |
Right, but if we are talking about 2.0, I thought language changes would be
in scope?
…On Mon, May 7, 2018 at 12:30 PM Brad Fitzpatrick ***@***.***> wrote:
@docmerlin <https://github.com/docmerlin>, the compiler implements the
language spec, so you're proposing a language change, which is way out of
scope for this particular bug.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#5465 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABLfW8hPopQlDMgUp3Vk_RxuyIemeG8Pks5twISngaJpZM4F0slU>
.
|
@docmerlin, perhaps, but language changes have a high bar. They need their own bug and a large write-up and discussion, not just a casual aside on some library issue. Any language changes that do happen in Go 2 will of course affect the standard library. |
@bradfitz Alright, thats fair. I'll make an issue for it (the language change). I think that this sort of change to the language would allow these sorts of fixes to be compatible with existing code and make code that relies a lot on closures a lot cleaner. |
It'd be neat if we could just use |
Awesome! I figured we'd need an API change to do this correctly as we have to hijack the client connection. Curious to see how you managed to do it. |
Nvm, I see now. We just don't use the transport. |
The If you want to log server errors in a custom way you have to create a custom It would be much more flexible to have
|
@AgentZombie, there's another bug open about rethinking log/log interfaces. Whatever we did across std would also be done in net/http. |
How about explicit context support? ServeHTTP(context.Context, ResponseWriter, *Request) and then get rid of (*Request).Context(). That way, middleware can also more easily augment the context without suffering #28737. |
Would be nice to rename |
Hi @nhooyr, but |
It’s not the worst thing but most usages of maps and array are plural in the stdlib. |
The auto recovering of http.Server didn't generate core dump even if GOTRACEBACK=crash, which make it hard to debug. All the information I get is the call stack which is not enough as I need to examine the value of various variable. |
The text was updated successfully, but these errors were encountered: