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: Benjamin Herrenschmidt via curl-library <>
Date: Wed, 17 May 2023 19:17:26 +1000

On Wed, 2023-05-17 at 09:24 +0200, Daniel Stenberg wrote:

Thanks for your reply...

> 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.

> ... 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
> anyway?
> This said, bumping curl's limit should still be harmless even if not quite
> interoperable.

In the general case, yes. That said, it could very well be that curl
(or libcurl) is used in specific cases (private API gateways etc...)
where the interoperability isn't a factor.

At this point I don't have enough data about the specific customer use
case. But I can imagine some that don't necessarily involve general
purpose components (web browser etc...).

I will try to get some data, at the very least so that I can ....

> > 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.

 ... propose a reasonable value that works for them.

I agree, simpler is better and bumping the value wouldn't affect the
"spirit" of the original change which is to avoid unbounded growth.

Received on 2023-05-17