On Thu, 2023-05-18 at 12:23 +0200, Daniel Stenberg wrote: > On Thu, 18 May 2023, Benjamin Herrenschmidt wrote: > > > the default header size for IIS is 16KB. > > ... > > > I agree that the failure mode you describe is ... sub-optimal. It was my > > understanding the limit was introduced to fix a CVE caused by unbounded > > growth but I might be mistaken. > > No, that is correct. Previously there was no limit at all so it could end up > ridiculously large. But the limit we ended up with was taken from Apache's > implmentation, so for once it was not just arbitrarily set =) > > > Any better idea to solve the issue ? We (Amazon) could carry a downstream > > only patch for our curl but I don't like that option much... The above > > seems > > to be a legitimate use case. > > It is simply not interoperable. Sending 10K cookie headers will be rejected > by > some servers and users will not now ahead of time when or if it will work > against a particular host. I can't think of a really good way to solve this.
This brings me back then to my original suggestion which is to have a way for the user to explicitly change the default in situations such as the one described where both client and servers are known to support and (in this case due to the large kerberos token) require it. Would this be an acceptable compromise ? If yes, in what form do you prefer it ? I was originally trying to limit the disruption by adding support for an env. variable that can be checked lazily (ie, if the check against MAX_COOKIE_HEADER_LEN fails, then go check it) in order to avoid the getenv() overhead in the normal case. But it might be preferable to just add an option to the API and update the curl program to get a new argument to specify it. What do you think ? Or we simply give up ? This seems to be a real field issue if those ADFS servers with Kerberos auth do indeed require larger cookies. Cheers, Ben. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
