EOF as error value in http.client Do function

[venezue...@gmail.com]

Hi guys!

Just wanted to share that this issue is happening to me. I started receiving as error value "EOF".

```bash
go version go1.4.2 darwin/amd64
```

I copied this Google go-github [Do function](https://github.com/google/go-github/blob/master/github/github.go#L296-L323) and made little modifications to it like: 

```go
func (c *Client) Do(req *http.Request, v interface{}) (*http.Response, error) {
  tr := &http.Transport{
   TLSClientConfig:    &tls.Config{InsecureSkipVerify: true},
   DisableCompression: true,
  }
  client := &http.Client{Transport: tr}
  resp, err := client.Do(req)
  ...
```

I have even followed the go-github implementation creating a `http.Client` and assigning it to a property in the `Client` struct to see if initializing client just once would make any change. But no matter what I do, I keep receiving that value specifically [while checking err returned by Do](https://github.com/google/go-github/blob/master/github/github.go#L297-L300).

The thing is that this code worked, I am working with an API and I test using curl and it works and somehow I just continued adding more code that worked with that `Do` method and it just started to return `EOF` (yeah, I now how stupid that sounds). I am new coding in Go and I don't know how to debug or find what is causing this issue. What's weird for me is this:

```go
  resp, err := c.client.Do(req)
  fmt.Println(resp) // has the response: &{201 Created 201 HTTP/1.0 1 0....
  if err != nil {
    fmt.Println("failed do...")
    return nil, err
  }
```

The response is actually there, so can you please point me out where could be a good place to start researching about this?

Thanks and sorry for this newbie question, but I am blank right now.

[Dave Cheney]

Can you post a complete working code sample?

From the example you have provided here, you are getting back a 201 created respond, 201 does not have a body, so it makes sense that any read of the body would return a io.EOF. You should check resp.StatusCode to detect if the response may contain a body.

[Rafa Perez]

Hi there!

Here is a pastebin[1] of what's happening. Your answer helped me to understand. The reason this happened to me is that I started using another endpoint for bulk assets creation, so when I use the endpoint to create 1 asset it returns 200, but when creating several it returns 201 with a JSON (as shown in the pastebin) detailing what happened with the assets creation.

Thank you very much for your response and yes, I need to work better with the status code and checking responses. The weird thing as far as I understand is the 201 returning a JSON body. Gonna figure that out.

Thank you very much for your answer!

[1] http://pastebin.com/zwcBY3Kv

[Konstantin Khomoutov]

On Tue, 9 Jun 2015 11:00:29 -0400
Rafa Perez <venezue...@gmail.com> wrote:

[...]

> Here is a pastebin[1] of what's happening. Your answer helped me to
> understand. The reason this happened to me is that I started using
> another endpoint for bulk assets creation, so when I use the endpoint
> to create 1 asset it returns 200, but when creating several it
> returns 201 with a JSON (as shown in the pastebin) detailing what
> happened with the assets creation.
>
> Thank you very much for your response and yes, I need to work better
> with the status code and checking responses. The weird thing as far
> as I understand is the 201 returning a JSON body.

Nothing weird here: [2] states that the response's body "SHOULD"
include the description of what has been created, and the format of
this payload should be communicated via the Content-Type header field.

Not sure about your Go program but your curl call sent "Accept: */*"
in the request, and hence the server was free to send you whatever
content type it saw fit.

[...]

2. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.2

[Rafa Perez]

Yes... thank you very much. Read just the definition from wikipedia instead of reading the detailed specification, new thing learned today :)

What I'm questioning myself at this point is best way to handle this:

...
err := errors.New("EOF")
if err != nil {
...

Since there will be valid responses that will have err != nil... I can't think about an idiomatic way to do this at this point.

Thanks for your response! 

[Konstantin Khomoutov]

On Tue, 9 Jun 2015 11:50:44 -0400

Rafa Perez <venezue...@gmail.com> wrote:

[...]

> What I'm questioning myself at this point is best way to handle this:
>
> > ...
> > err := errors.New("EOF")
> > if err != nil {
> > ...
>
>

> Since there will be valid responses that will have *err != nil*... I

> can't think about an idiomatic way to do this at this point.

I don't understand this bit.
All the code in the standard library (and the code in sensible
3rd-party packages) uses *the value* io.EOF exported by the standard
package "io" [1] to signal EOF condition, so basically your check should
be the plain comparison of the error value returned by the Read() call
on the response's body with the value io.EOF.

Note that godoc does only document exported stuff, and everything in Go
which starts with a capital letter is exported.

In other words, that io.EOF thing is "stable" in that you can just
compare the errors you get with it.

1. http://golang.org/pkg/io/#pkg-variables

[Rafa Perez]

Sorry for not explaining myself better I misunderstood the value in the err value and I was thinking about doing a string(err) or something like that for doing the comparison, glad that I mentioned. You're totally right, I did what you mentioned and everything is working as expected. 

Thank you very much for the guidance in such newbie questions.