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: Wed, 17 May 2023 19:17:26 +1000
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.
Date: Wed, 17 May 2023 19:17:26 +1000
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.htmlReceived on 2023-05-17