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 <dan...@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.html
