mirror of
https://github.com/yhirose/cpp-httplib.git
synced 2026-09-06 08:33:48 +00:00
19352ae929
parse_multipart_boundary only rejected an empty boundary, so a request could declare one as long as a header line is allowed to be. A stock server accepts up to 8146 bytes there, which is what CPPHTTPLIB_HEADER_MAX_LENGTH leaves after "Content-Type: multipart/form-data; boundary=". FormDataParser searches the body for "--" + boundary + CRLF with a plain substring scan. buf_find scans for that delimiter's first byte, always '-', and at every position that matches calls start_with, which compares until the first mismatch. A body of '-' makes every position a candidate, and a boundary of '-' makes each candidate compare the whole delimiter before failing at the CRLF. The worst case is the product of the body length and the boundary length, and only the first factor was bounded. Measured by driving the parser directly in 16 KB reads, Apple clang 17 at -O2 -DNDEBUG, best of three runs on an otherwise idle machine. 100 MB of '-', the default payload limit, costs 2.59 s of CPU with a 70 byte boundary and 281.83 s with an 8147 byte one, a factor of 109. The same shape shows at 8 MB: 0.211 s, 3.081 s, 11.359 s and 22.091 s for boundaries of 70, 1024, 4096 and 8147 bytes. RFC 2046 5.1.1 caps a boundary at 70 characters, so honoring that limit bounds the multiplier too. The limit applies to the value after unquoting, so a quoted 70 character boundary stays valid. Only the server receive path parses a boundary out of a Content-Type, so what clients may send is unaffected, and the boundaries the library generates itself are 45 characters.
