On Fri, 19 May 2023, Henrik Holst wrote:
I did some more digging around on what the various http servers uses and
while it is 8k on most servers (apache, nginx) it is 16k on IIS but it is
also configurable on all http servers. So it can be set to be higher on
apache, nginx, IIS and most other http servers out there. So having it be
configurable in libcurl as well does IMHO not sound that outlandish.
No, it is perfectly logical. It's just that this is one of those tough ones.
1. basically no user will understand when to change such an option
2. setting it to a "too high" value and using that size, risks making your
curl transfers to fail with rather inexplainable failure modes
3. A user might change the value and find it works fine *for years* (perhaps
because they never reach the limit) and then they try another server or
even worse: the primary server updates and then suddenly without anything
in curl or the application having changed, the transfers fail.
But yes: by *not* offering such an option we also have users that cannot make
their application perform correctly because libcurl blocks it from doing what
it needs to do simply because there are *other* servers out there that will
not appreciate a request like that.
Maybe a small thing to help would be to make curl use a verbose output when it
sends a cookie header that is longer than the current limit? That at least
could be a clue for users who get a 400 back without understanding why...
--
/ 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
