Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
RE: Issues with new cookie length limits
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 7 Jun 2023 11:47:25 +0200 (CEST)
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 ?
Date: Wed, 7 Jun 2023 11:47:25 +0200 (CEST)
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.htmlReceived on 2023-06-07