Repository navigation
fix: split SQL over 128 KiB across several multipart query fields - #506
Draft
ch-language-clients-rust wants to merge 1 commit into
Draft
ch-language-clients-rust wants to merge 1 commit into
ch-language-clients-rust wants to merge 1 commit into
Conversation
Since ClickHouse#455, a query with parameters sends its SQL as the `query` field of a `multipart/form-data` body. ClickHouse rejects any form field longer than `http_max_field_value_size` (128 KiB by default) with "HTML Form Exception: Field value too long", so a parameterized query with more SQL text than that failed. The server joins the values of all `query` fields in order, without a separator (`DynamicQueryHandler::getQuery`). Send the SQL as fields of at most 128 KiB each, split on character boundaries. A query that fits still produces one field. `Query::param` now documents that each parameter value is still limited to `http_max_field_value_size`. Fixes ClickHouse#501 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #501.
Since #455, a query with at least one
Query::param()sends its SQL as thequeryfield of amultipart/form-databody. ClickHouse rejects any form field longer thanhttp_max_field_value_size(128 KiB by default) withHTML Form Exception: Field value too long, so a parameterized query with more than 128 KiB of SQL failed. In 0.15.2 the SQL was the raw request body and had no such limit.For a multipart body, the server joins the values of all
queryfields in order, without a separator (DynamicQueryHandler::getQuery). The client now sends the SQL asqueryfields of at most 128 KiB each, split on character boundaries. A query of up to 128 KiB still produces exactly one field, so its request does not change. ClickHouse/clickhouse-cs#701 takes the same approach.The server has joined
queryfields this way since at least 19.14, and the loop is in every LTS release since. I checked it against 23.8, 26.7, 26.10 and head (26.11). The new integration test runs againstheadin CI, so a change on the server side would show up there.Not changed: a single parameter value over 128 KiB still fails. That is not a regression, because the server applies the same limit to URL query-string values, so 0.15.2 failed on it too. A value can't be split across repeated
param_<name>fields either. TheQuery::paramdocs now state the limit, and that only the server's default settings profile can raise it. A per-query or per-userhttp_max_field_value_sizehas no effect, because the server parses the form with its global settings.Checklist
Candidate CHANGELOG entry
🤖 Generated with Claude Code