-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http client interface needs rewrite #155
Labels
Comments
I agree. There are other issues too, like authentication, cookies, and HTTP/1.1 persistent connections, that should be considered too. We will probably not be able to do this until the launch buzz dies down for a while. Owner changed to r...@golang.org. Status changed to LongTerm. |
This has just bitten me too, so I've had to copy send() and associated code into my package :( Given that some of these issues are likely to be only resolved in the long-term, is a shorter-term change of making Send() public feasible, or is it best to just wait? Obviously I'm not in a hurry because I have a workaround, I was just wondering. |
Issue #252 has been merged into this issue. |
Issue #355 has been merged into this issue. |
Russ, please reconsider your decision to not expose send. By keeping it private you are forcing multiple developers to work around the same problem. And you are making it more difficult for developers to share code with each other. (I want to publish my UPnP implementation, but I'm blocked in doing so by the 3 bugs in the net and HTTP code.) Your stated reason for keeping Send private is to make it easier for you to change the http API compatibly. But given that Response is already public, I can't imagine any significant change to the http API that wouldn't break existing clients. And given that Go changes incompatibly every month anyway, I see little benefit to keeping the http code especially stable. I expect that you will give in to temptation and change http incompatibly before go becomes API stable, so all you're doing now is making the http library less useful. The alternative is for developers to start maintaining an "extended" version of the net and http libraries, that has these additional features. Is that what you recommend? |
I made a small proposal that would solve most of these issues: http://groups.google.com/group/golang-nuts/browse_thread/thread/c381b81c291bb527 |
The bulk of the work has been done on this now. (there's now a configurable Client struct and a Transport interface) I can keep this bug open until some more optional interfaces on http.Client land. Owner changed to bradf...@golang.org. |
Things requested in this thread and their status: Client.Do(): now available. auth: not yet automatic or made easy, but now possible with Client.Do. Helper interface could hang off Client in the future. HTTP/1.1 persistent connections: done possible to not send chunked encoding: done (set a ContentLength) Also: Client/Transport/RoundTripper: new since this bug Client.CheckRedirect: the old "10 max redirects" policy is now configurable. ... I'm going to close this bug as fixed. Additional feature requests can be tracked separately in new issues. Feel free to put "pkg-http" in the Labels and/or assign to me. Status changed to Fixed. |
This was referenced Dec 8, 2014
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: