You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to the documentation for http.Client:
// CheckRedirect specifies the policy for handling redirects.
// If CheckRedirect is not nil, the client calls it before
// following an HTTP redirect. The arguments req and via
// are the upcoming request and the requests made already,
// oldest first. If CheckRedirect returns an error, the client
// returns that error instead of issue the Request req.
The code does not actually do what this comment says.
The doFollowingRedirects method, and thus the Do method, do not actually return _that
error_ (i.e. the error object returned by CheckRedirect). It returns a new url.Error
whose Err field is the error returned by CheckRedirect.
I'm not sure what is the desirable behavior in light of the rest of the code base ...
but it seems to me that what is described in the comment is worthwhile, so that client
code can set a specific error object (or type) in CheckRedirect and check for it as the
error return. Client code could then just do an == comparison for the error set by
CheckRedirect, and wouldn't need to import "net/url" in order to check the
type of the url.Error.
The text was updated successfully, but these errors were encountered:
by krueger@google.com:
The text was updated successfully, but these errors were encountered: