Hi Antoine, For the header, I have an example in mind: if the client is Flight JDBC, by default, all options from the JDBC URL are passed as Flight header (for instance jdbc:arrow-flight-sql://localhost:12345/?one=foo&two=bar&third=third will be one, two, third headers). So, if the user is passing a lot of arguments on the URL (for any reason), we can have a bunch of headers.
But I'm also concerned by the server accepting any header size. I think it would make sense to have a lower default limit. Regards JB On Tue, Sep 10, 2024 at 10:20 AM Antoine Pitrou <anto...@python.org> wrote: > > > Le 10/09/2024 à 09:23, Jean-Baptiste Onofré a écrit : > > Hi folks, > > > > I came to this PR: https://github.com/apache/arrow/pull/43697 > > > > For the background, before this PR, the client can send any header > > size whereas the server only accepted 2Kb. > > With the PR, now the server (by default) accepts any header size as > > well (e.g. 2GB). > > What is the use case for huge header sizes? I haven't found a rationale > in the linked PR (or issue). > > Making limits in the client and server consistent is not a goal in > itself, especially as there are third-party client and server > implementations around. It's reasonable for the server to put stricter > limits in place than the client, since servers are usually trusted while > clients are not. > > I would recommend lowering the limit to a reasonable value on the server > side. Huge headers can sometimes be a vector for denial of service > attacks, depending on how parsing is implemented. > > Regards > > Antoine. > > > > > > > > I wonder if it's a good approach because: > > 1. header size can have a significant impact on performance > > 2. if an user puts a proxy between client and server (nginx, NLB, > > ...), most of the time, proxies have limits on frame size and header > > size > > > > Instead of unlimited header size by default on the server side, I > > wonder if it would not make sense: > > 1. To define a limit (frame and header) on gRPC layer on both side > > (client and server) > > 2. To auto-negotiate header size: the client could send the header > > size he plans to send and the server auto-tune if possible (or > > eventually reject the request) > > > > Thoughts ? > > > > Regards > > JB
