curl / Mailing Lists / curl-library / Single Mail
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.


From: Daniel Stenberg via curl-library <>
Date: Wed, 17 May 2023 09:24:54 +0200 (CEST)

On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote:

> And more specifically by the 8KB limit applied to the cookier headers.
> Now I understand the value in preventing runaway header attacks and it does
> make a lot of sense to use a limit, but is there a reason not to make this
> limit configurable for use cases where 8KB is simply not sufficient ?

Yes, because they are (probably) no longer interoperable then.

RFC 6265 section 6.1 which dictates the "limits" says that "general-use user
agents SHOULD provide each of the following minimum capabilities":

  o At least 4096 bytes per cookie (as measured by the sum of the
     length of the cookie's name, value, and attributes).

But in the update work, RFC6265bis section 5.4, which is not final yet the
draft-10 instead says:

   If the sum of the lengths of the name string and the value string is more
   than 4096 octets, abort these steps and ignore the set-cookie-string

... meaning that if you go beyond these limits, there seem to be a big chance
that they won't interoperate with other major cookie users, like browsers.
Which probably brings the question back to your users: do they *REALLY* want
larger cookies that then risk not being possible to use with other consumers

This said, bumping curl's limit should still be harmless even if not quite

> I'm generally weary of libcurl API/ABI changes, so the least disruptive
> approach I can think of would be to have an env. variable that can
> optionally raise the limit.

I think I would rather prefer simply bumping the limit unconditionally for
everyone. For simplicity. Both in code and for users.

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
Received on 2023-05-17