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
Cc: Henrik Holst ; libcurl development
Subject: [EXTERNAL] Re: Issue with MAX_COOKIE_HEADER_LEN
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
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
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
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
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
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
On Wed, 2023-05-17 at 16:44 +0200, Daniel Stenberg wrote:
> On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote:
>
> > And more specifically by the 8KB limit applied to the cookier headers.
>
> Back again, having done some more thinking.
>
> The main problem with upping this
> On 17 May 2023, at 16:44, Daniel Stenberg via curl-library
> wrote:
> So: not an easy limit to toy around with.
I don't think we should raise this, there is no benefit to the vast majority of
users. Anyone who has an environment where they need this have the code
available to build a custom
On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote:
And more specifically by the 8KB limit applied to the cookier headers.
Back again, having done some more thinking.
The main problem with upping this limit is that a typical user don't know what
the maximum allowed line
On Wed, 17 May 2023, Daniel Stenberg via curl-library wrote:
This however goes directly against RFC 6265 section 5.4 which says:
I submitted this issue to the http wg:
https://github.com/httpwg/http-extensions/issues/2541
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is
On Wed, 17 May 2023, Daniel Stenberg via curl-library wrote:
Beyond 8K something HTTP servers are going to cause problems with their
maximum header line lengths and then it becomes even harder to interop.
Something else struck me and here's a suitable RFC reference:
On Wed, 17 May 2023, Benjamin Herrenschmidt wrote:
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
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
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
Hi !
This is my first involvement with Curl development, so please bear with
me if I'm missing some established practices here :-) I usually dabble
in kernel land.
We (Amazon Linux distribution) have had customers complaining of their
use cases being broken by commit:
16 matches
Mail list logo
