Skip to content
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

Closed
hoisie opened this issue Nov 13, 2009 · 16 comments
Closed

http client interface needs rewrite #155

hoisie opened this issue Nov 13, 2009 · 16 comments

Comments

@hoisie
Copy link
Contributor

hoisie commented Nov 13, 2009

Right now the http package has public methods that do POST and GET 
requests. These use the more generic send method, but that isn't publicly 
available. 

Unless you copy the send() code to your local code, you can't send any 
other HTTP requests. 

What is the expected output? What do you see instead?
Expect to use http client to send HEAD and DELETE requests

What is your $GOOS?  $GOARCH?
linux,386

Which revision are you sync'ed to?  (hg log -l 1)
[Mike@KennaFC11 go]$ hg log -l 1
changeset:   4030:52ad1606d994
tag:         tip
user:        Rob Pike <r@golang.org>
date:        Fri Nov 13 13:15:18 2009 -0800
summary:     Explain why


Please provide any additional information below.
@rsc
Copy link
Contributor

rsc commented Nov 14, 2009

Comment 1:

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.

@gopherbot
Copy link
Contributor

Comment 2 by rossdjones:

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.

@rsc
Copy link
Contributor

rsc commented Nov 17, 2009

Comment 3:

Even though I know it's a little bit of a pain,
I'd rather not expose Send, because then we'll
break the people depending on it later.
At least now you know that you made a
local change and don't have an expectation
of it continuing to work in the future.

@rsc
Copy link
Contributor

rsc commented Nov 18, 2009

Comment 4:

Issue #252 has been merged into this issue.

@gopherbot
Copy link
Contributor

Comment 5 by montsamu:

Comment to add that supporting Get of an "https" URL is also requested in the http 
client library instead of result: unsupported protocol scheme "https"

@rsc
Copy link
Contributor

rsc commented Nov 29, 2009

Comment 6:

Issue #355 has been merged into this issue.

@rsc
Copy link
Contributor

rsc commented Dec 2, 2009

Comment 7:

Labels changed: added packagechange.

@hoisie
Copy link
Contributor Author

hoisie commented Jan 6, 2010

Comment 8:

One more issue:
Right now all requests are sent with chunked encoding. However, if the Content-Length 
header is present, it's pointless to use chunked encoding.

@rsc
Copy link
Contributor

rsc commented Jan 6, 2010

Comment 9:

pointless but easy

@jackpal
Copy link
Contributor

jackpal commented Jan 11, 2010

Comment 10:

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?

@hoisie
Copy link
Contributor Author

hoisie commented Jan 11, 2010

Comment 11:

I made a small proposal that would solve most of these issues:
http://groups.google.com/group/golang-nuts/browse_thread/thread/c381b81c291bb527

@gopherbot
Copy link
Contributor

Comment 12 by peterbourgon:

I'm running into http.Request-related problems in yet another application I'm writing.
Can we prioritize this 
issue?

@bradfitz
Copy link
Contributor

bradfitz commented Mar 4, 2011

Comment 13:

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.

@bradfitz
Copy link
Contributor

Comment 14:

Status changed to Started.

@bradfitz
Copy link
Contributor

Comment 15:

Labels changed: added pkg-http.

@bradfitz
Copy link
Contributor

Comment 16:

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 issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants