On Wed, 2023-05-17 at 09:24 +0200, Daniel Stenberg wrote: Thanks for your reply...
> On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote: > > > And more specifically by the 8KB limit applied to the cookier headers. > > > > Now I understand the value in preventing runaway header attacks and it does > > make a lot of sense to use a limit, but is there a reason not to make this > > limit configurable for use cases where 8KB is simply not sufficient ? > > Yes, because they are (probably) no longer interoperable then. .../... > > ... meaning that if you go beyond these limits, there seem to be a big chance > that they won't interoperate with other major cookie users, like browsers. > Which probably brings the question back to your users: do they *REALLY* want > larger cookies that then risk not being possible to use with other consumers > anyway? > > This said, bumping curl's limit should still be harmless even if not quite > interoperable. In the general case, yes. That said, it could very well be that curl (or libcurl) is used in specific cases (private API gateways etc...) where the interoperability isn't a factor. At this point I don't have enough data about the specific customer use case. But I can imagine some that don't necessarily involve general purpose components (web browser etc...). I will try to get some data, at the very least so that I can .... > > I'm generally weary of libcurl API/ABI changes, so the least disruptive > > approach I can think of would be to have an env. variable that can > > optionally raise the limit. > > I think I would rather prefer simply bumping the limit unconditionally for > everyone. For simplicity. Both in code and for users. ... propose a reasonable value that works for them. I agree, simpler is better and bumping the value wouldn't affect the "spirit" of the original change which is to avoid unbounded growth. Cheers, Ben. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
