[regression] Sending large header over http2 fails with a send error #11138
Comments
|
Downgrading curl to: Fixes my issue. Since I'll close the git-cinnabar issue, I'll post the whole request body here: The cURL stack is: |
|
We should be able to increase that (double?) at fairly low risk I think... |
|
Seems like a candidate for the 8.1.1 release! |
|
(Just curious, why does there need to be a limit to begin with?) |
This works around curl#11138, by doubling the limit, and should be a relatively safe fix. Ideally the buffer would grow as needed and there would be no need for a limit? But that might be follow-up material. Ref: curl#11138
|
I sent #11139, doubling the buffer size as suggested, though I think ideally there should be no limit? I don't have much context on that code tho. |
|
Thanks for making that PR. I agree that 8K is the better limit. not sure what I was thinking at the time. Most servers have such limits as well, for example Apache has 8K by default (https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestfieldsize) When processing HTTP/1.1, having maximum field/line length is sensible since otherwise someone injecting requests can cause unlimited memory growth. This is one way to DoS http processing. |
|
@bagder: is there any length enforcement on headers? Thinking about cookies especially. Maybe 8K is even not enough? What do we want to process? Hmm, reading the cookie discussion on the mailing list, 8K for one line, e.g. one header field, seems to be a good limit. |
|
Yeah, I think we use 1MB total max for a h1 request ( |
|
FWIW, git-cinnabar decides the max length of the headers it sends based on what the mercurial server reports as its httpheader value. https://hg.mozilla.org/mozilla-central?cmd=capabilities says httpheader=6144. So yeah, 4k is definitely smaller than that. Mercurial's default for that value is 1024, so 6144 is definitely something that was set specifically on the Mozilla server... (digging...) it was set here: https://hg.mozilla.org/hgcustom/version-control-tools/rev/d34c25360eb14189a599540f7f36c1ae2159ad5f , based on the HTTP server having a 8k limit. |
This works around curl#11138, by doubling the limit, and should be a relatively safe fix. Ideally the buffer would grow as needed and there would be no need for a limit? But that might be follow-up material. Fixes curl#11138 Closes curl#11139
I did this
fc2f1e5 introduced a hardcoded limit in max_line_length for http2 of 4kb, which is hit for requests with long headers.
Sending a request as the one in glandium/git-cinnabar#314 fails now where it didn't fail before updating curl.
I expected the following
The request is sent successfully.
curl/libcurl version
operating system
The text was updated successfully, but these errors were encountered: