net/http: unexpected behavour of client.Do() with cookie jar #36535
Comments
Change https://golang.org/cl/214557 mentions this issue: |
If you initialize an http.Request without NewRequest, you must create the map yourself. This is Working As Intended. |
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 |
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. |
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. |
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. |
What version of Go are you using (
go version
)?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{}
insteadhttp.NewRequest()
is more convenient, causehttp.NewRequest()
does too many things. Declaration of request object looks more readable and simple.What did you see instead?
They are panicing!😮
The text was updated successfully, but these errors were encountered: