Support setting an "Authorization" and a "Proxy-Authorization" HTTP request headers. - #5038
Support setting an "Authorization" and a "Proxy-Authorization" HTTP request headers.#5038amejia1 wants to merge 1 commit into
Conversation
|
I am not excited about these changes. I think they add a lot of complexity solely for the benefit of testing pretty niche behavior. There's also no clean commit history. |
I can start just using a single clean commit for these changes going forward which is what I was originally doing. I did need some way to manually run the rustup-init program and rustup-init.sh script with these authorization http headers locally and verify they work as expected. With my old PR at #4672 I was proposing the use of certain tools inside of containers to serve a mock server and proxy and run some tests against those. In the end I thought those were even more complicated and opted to come up with some simple mock server and proxy that can be implemented and maintained along with rustup. Also, I believe the rust dist server started rejecting any requests with authorization or proxy-authorization headers in the requests sometime while I was developing this feature several months ago. I think that I may have caused the need for that change with the dist server since early on, I would just run my modified build of rustup-init which would send these new headers. Since then, I thought it best to use a local mock server and proxy for offline testing. |
86dbe3f to
7058df5
Compare
…equest headers. The "RUSTUP_AUTHORIZATION_HEADER" and "RUSTUP_PROXY_AUTHORIZATION_HEADER" environment variables make the "rustup" and "rustup-init" programs and the "rustup-init.sh" script send the given "Authorization" and "Proxy-Authorization" HTTP request headers to the distribution server and the forward proxy. This lets them download a toolchain from a distribution server that requires credentials and through a proxy that demands its own credentials. The header values are not printed and are not persisted in the settings file. The "rustup-init.sh" script accepts the headers on the command line as well, through the "--authorization-header" and "--proxy-authorization-header" options. It downloads http:// URLs pointing at the local machine (localhost, 127.0.0.0/8, and ::1) over plain HTTP so that a local mirror or proxy forwarding to a corporate server that authenticates with cookies or mTLS can be reached; every other URL is downloaded over https. The download-level behavior is covered by in-process tests that check the headers are sent to the server and that the download succeeds when the server requires them.
|
@djc I moved out all that code for the implementation of the mock server and mock proxy. What is left is the support for the new headers and updates to rustup-init.sh so it can use servers and proxies running on the local host. I still need some way to test these new changes without using the official rust distribution server so I have the mock server and proxy implemented here. |
2 participants
The "Authorization" request header is used to authenticate to rustup distribution mirrors that require authentication. The "Proxy-Authorization" request header is used to authenticate to proxies.
This change introduces the new "rustup-mock-server" and "rustup-mock-proxy" test binaries, which are used to test the proper functioning of the new support for the "Authorization" and "Proxy-Authorization" HTTP request headers. A "test-rustup-init.sh" script has also been added to test the proper functioning of the "rustup-init.sh" script with the newly supported request headers.
As part of this change, "rustup-init.sh" was also modified to support distribution servers and proxies running on the localhost using HTTP. This not only provides the benefit of being able to use the "rustup-mock-server" and "rustup-mock-proxy" to run tests, it also provides additional support for custom servers and proxies which run on the localhost and forward requests to corporate servers that may require more elaborate forms of authentication, such as the usage of cookies or the usage of mTLS.
It doesn't seem like putting a disclaimer that AI agents were used is necessary. In any case, at least for the benefit of those that may have been using AI agents for much longer than I have, these code changes were made with the assistance of AI agents. I used a local LLM running this Qwen3.8-27B model.
This addresses #1343 .
I had a previous PR to offer similar functionality (see #4672 ). I decided to redo the code changes entirely, using a locally built mock server and proxy for the tests instead of relying on containers. I also decided to redo the changes with the aid of an AI agent.