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: Chamberlin, David via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 8 Jun 2023 13:09:37 +0000
We'll hold off on the cookie length limit for now, then and wait to see what happens.
We are planning to submit a pull request with a test and the fix for the length calculation issue.
The impact is that the real limit for cookie size may actually end up being somewhat less than 8K.
For the test we are looking to adding another test case in tests/data - does that seem right? I don't see anything that explicitly tests the 8K limit - or might that be somewhere else?
Do we need to do anything to have the test picked up or just commit the next numbered test case?
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: 07 June 2023 10:47
To: Chamberlin, David via curl-library <curl-library_at_lists.haxx.se>
Cc: Aleksandar Lazic <al-curllibrary_at_none.at>; Chamberlin, David [Engineering] <David.Chamberlin_at_ln.email.gs.com>
Subject: RE: Issues with new cookie length limits
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://urldefense.com/v3/__https://github.com/curl/curl/issues__;!!O2kDR7mm-zSJ!sOkUrP-MgxcqmpRP5bQ1r2Q1vmXF9eDTzmJdmyHp3cJm0E_4s0eMcSI1_d4cpIRJxLvEabFWK1s8BFL9mg$ ?
Date: Thu, 8 Jun 2023 13:09:37 +0000
We'll hold off on the cookie length limit for now, then and wait to see what happens.
We are planning to submit a pull request with a test and the fix for the length calculation issue.
The impact is that the real limit for cookie size may actually end up being somewhat less than 8K.
For the test we are looking to adding another test case in tests/data - does that seem right? I don't see anything that explicitly tests the 8K limit - or might that be somewhere else?
Do we need to do anything to have the test picked up or just commit the next numbered test case?
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: 07 June 2023 10:47
To: Chamberlin, David via curl-library <curl-library_at_lists.haxx.se>
Cc: Aleksandar Lazic <al-curllibrary_at_none.at>; Chamberlin, David [Engineering] <David.Chamberlin_at_ln.email.gs.com>
Subject: RE: Issues with new cookie length limits
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://urldefense.com/v3/__https://github.com/curl/curl/issues__;!!O2kDR7mm-zSJ!sOkUrP-MgxcqmpRP5bQ1r2Q1vmXF9eDTzmJdmyHp3cJm0E_4s0eMcSI1_d4cpIRJxLvEabFWK1s8BFL9mg$ ?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://urldefense.com/v3/__https://curl.se/support.html__;!!O2kDR7mm-zSJ!sOkUrP-MgxcqmpRP5bQ1r2Q1vmXF9eDTzmJdmyHp3cJm0E_4s0eMcSI1_d4cpIRJxLvEabFWK1u0d2IElg$ ________________________________ Your Personal Data: We may collect and process information about you that may be subject to data protection laws. For more information about how we use and disclose your personal data, how we protect your information, our legal basis to use your information, your rights and who you can contact, please refer to: www.gs.com/privacy-notices<http://www.gs.com/privacy-notices> -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-06-08