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.
A security bulletin from a few years ago clarifies that, specifically, the Authorization header is no longer forwarded to different hosts, and experiment confirms that current curl does still behave this way.
To be clear, the current behaviour is good! :)
I suggest that the documentation for CURLOPT_UNRESTRICTED_AUTH be clarified to indicate precisely which kinds of authentication it controls. It's not only "user+password" (such as could be set by CURLOPT_USERPWD, which is linked-to from this doc page), but also any application-provided Authentication header, and I think also any headers set internally by various other curl-supported authentication mechanisms.
I'm not sure of the total list of what this controls, so I haven't drafted a doc patch myself. It would be helpful to me as an API user if I could look at the CURLOPT_UNRESTRICTED_AUTH docs and know immediately:
that my custom-set Authentication headers are not forwarded to other hosts when this is 0, and
which curl-generated headers or authentication information is not forwarded to other hosts when this is 0,
and also that such headers are forwarded when this is 1.
The text was updated successfully, but these errors were encountered: