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: Mon, 29 May 2023 15:15:50 +1000

On Fri, 2023-05-19 at 16:55 +0200, Henrik Holst wrote:
> Yeah it is ofc a complex situation, the web servers themselves does
> not help much either since basically none of them responds with a
> proper 413 and instead send a generic 400.
> When it comes to your #1 to #3 I think that all we can do there is
> make sure that the documentation for the setting is very clear on
> that this must match the setting at the server side. However since
> this is configurable on the server side there can very well be
> servers out there with a size < 8kb which means that curl could
> currently fail in the exact same way with no indication on why. AFAIK
> e.g nginx uses the page size by default so on many systems it
> currently have a default size of 4k.

This is indeed a mess, so our arbitrary limit of 8k today is just
that... arbitrary.

I would like to find a solution that our customers can use in the
specific case of Kerberos auth with ADSF at least. I think it's ok we
we require user to specific an extra argument on curl's command line to
bump the limit.

What approach should we take ? I'm happy to give a try at writing &
submitting the patch myself.


> /HH
> Den fre 19 maj 2023 kl 16:30 skrev Daniel Stenberg <>:
> > 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...
> >

Received on 2023-05-29