Why is the value for ther "--header" option limited in length?

[Nico Flohr (bara-nflohr)]

Passing any value larger than 1024 characters to the "--header" option results in the command failing.
I'm asking this because I'm currently working on a concept that works with content of about 3000 characters. And I'm asking myself if there is any reason for this being limited and if it could be changed/increased.

[leenlbma]

The 1024-character cap is intentional and enforced in the client.

In src/AppInstallerRepositoryCore/Rest/RestClient.cpp:

constexpr size_t WindowsPackageManagerHeaderMaxLength = 1024;
...
THROW_HR_IF(APPINSTALLER_CLI_ERROR_CUSTOMHEADER_EXCEEDS_MAXLENGTH,
    customHeader.value().size() > WindowsPackageManagerHeaderMaxLength);

The same limit is written into the original design spec (#893 – Support for arbitrary HTTP header for Rest sources): “The header can have a maximum length of 1024 characters.”

--header is not a general HTTP header injector. Whatever you pass is sent as the value of a single header named Windows-Package-Manager to a REST source. The cap keeps that value bounded for logging, caching, and server handling.

So for a ~3000-character payload you cannot raise the limit from the CLI today — it is a compile-time constant. Options:

• Keep the large content on the server (or in a package manifest) and pass a short id/token in --header.
• Use a different channel than winget’s REST custom header for that concept.
• Open a feature request / PR to raise WindowsPackageManagerHeaderMaxLength if you have a concrete REST-source scenario that needs it.

[Nico Flohr (bara-nflohr)]

Thanks for the swift answer. I guess this leaves me with opening a feature request or PR to increase the constant.
Everything else I looked at and you mentioned isn't really suitable for passing a kind of payload to authenticate the REST requests on the backend side.