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: Benjamin Herrenschmidt via curl-library <curl-library_at_lists.haxx.se>
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.
Cheers,
Ben.
> /HH
>
> Den fre 19 maj 2023 kl 16:30 skrev Daniel Stenberg <daniel_at_haxx.se>:
> > 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: 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.
Cheers,
Ben.
> /HH
>
> Den fre 19 maj 2023 kl 16:30 skrev Daniel Stenberg <daniel_at_haxx.se>:
> > 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...
> >
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-05-29