On Wed, 7 Jun 2023, Chamberlin, David via curl-library wrote:
I suspect that adding a new command line parameter as Ben suggests to an already crowded set will get some pushback - a CMakeLists/configure option might be more acceptable?
I think we have not landed exactly on what the preferred way to solve this would be. Few users build their own library so having it a build-time option will make it difficult or downright impossible for some.
The challenge is that we seem to be forced to allow > 8K cookie headers because some systems need them while at the same time some systems will return 400 on such headers.
Questions that remain: 1. When a user gets a 400 back, how is they supposed to figure out that this could be because they send a too long Cookie: header? 2. What should the new maximum limit be ? 3. Should we do some info-logging for outgoing headers longer than the current max limit?
Also, the length calculation issue we picked up was not discussed.
That sounds like a bug so maybe just post all the details over at https://github.com/curl/curl/issues ?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
