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