net/http: unexpected behavour of client.Do() with cookie jar

[quenbyako]

What version of Go are you using (go version)?

$ go version go1.12.7 linux/amd64

Does this issue reproduce with the latest release?

Yes, stable 1.13.6 version has same problem too.

What operating system and processor architecture are you using (go env)?

Any platform with any enviroment

What did you do?

code is here: https://play.golang.org/p/M7q1GhoW1wV

So, for my opinion, the problem is in r.AddCookie() function, which don't check request header is nil and forcely call Headers methods. 🤔

What did you expect to see?

My projects must not panicing for situations like this 👍

i think, that request initializing with &http.Request{} instead http.NewRequest() is more convenient, cause http.NewRequest() does too many things. Declaration of request object looks more readable and simple.

What did you see instead?

They are panicing! 😮

[gopherbot]

Change https://golang.org/cl/214557 mentions this issue: fix of #36535 issue

[smasher164]

If you initialize an http.Request without NewRequest, you must create the map yourself. This is Working As Intended.

[quenbyako]

i understand that now i need to call NewRequest(), but as i said, it is not obvious, and code becomes bloated. I wrote in detail why this is inconvenient and illogical, so I do not think that the problem is resolved by NewRequest().

you know, add 3 lines of checking code is not so bad proposal fmyo

[smasher164]

The issue is not with adding three lines of checking code to client.Do. The issue is that it sets a precedent for net/http to do nil-checking any functions that interact with a request. In general for Go, if a struct has members that need to be initialized, the responsibility is either for the package to provide a factory function like NewRequest or for the user of the package to initialize its members themselves.

[quenbyako]

I agree with you, didn't think about it at this first, this situation is really not a concern of stdlib. well, what if we can add some function similar to newrequest which will not require me parse the same uri twice time?

i mean, this is really important for me, cause i think, that same code must be simple and concise, adding line with call request initializer and handling error feels a bit overheaded.

[smasher164]

An alternative in your case could be to wrap the http.Client type, and override the Do method to initialize the request before actually doing the request.