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: Issue with MAX_COOKIE_HEADER_LEN
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 19 May 2023 16:30:41 +0200 (CEST)
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...
Date: Fri, 19 May 2023 16:30:41 +0200 (CEST)
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.htmlReceived on 2023-05-19