Personally I'm a fan of standards, and I note that RFC 9110 recommends a minimum of a mere 8000 bytes. Real-life use cases aside, I don't think it would be incorrect of curl to place its limit somewhere around there.
does memory and cpu usage grow faster than O(n) with respect to the length of the URL? If so, it should be made smaller, I think. Otherwise perhaps not?
the report claims it does, but I cannot reproduce that so I think no. Still, if we don't need this large URLs we could also just cut down to decrease the risk of another future issue in the similar spirit.
many servers will reject by default urls above 8k. But there are probably special setups out there.
Other things start to break when urls go beyond 64k. h2 may have a problem with its header handling (although headers are outside the stream's window size).
h3 will have problems with initial congestion windows where headers count for the window.
I think 64k would therefore be a limit that should not by itself pose problems.
since I assume curl doesn't need to deal with hash manipulation in JS and data URLs, a limit of Kb might be OK. In Firefox we got bugs when we tried to limit it, because the hash would contain encoded data, or data URLs would encode images or video.
EricJ
in reply to daniel:// stenberg:// • • •Elias Mårtenson
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Elias Mårtenson • • •Stefan Eissing
in reply to daniel:// stenberg:// • • •many servers will reject by default urls above 8k. But there are probably special setups out there.
Other things start to break when urls go beyond 64k. h2 may have a problem with its header handling (although headers are outside the stream's window size).
h3 will have problems with initial congestion windows where headers count for the window.
I think 64k would therefore be a limit that should not by itself pose problems.
Valentin Gosu
in reply to daniel:// stenberg:// • • •In Firefox we got bugs when we tried to limit it, because the hash would contain encoded data, or data URLs would encode images or video.
daniel:// stenberg://
in reply to Valentin Gosu • • •Basti
in reply to daniel:// stenberg:// • • •