xavi/libweb/http.c, branch v0.3.0Small and lightweight web framework written in C99 and POSIX.1-2008.
https://gitea.privatedns.org/xavi/libweb/atom?h=v0.3.02024-02-19T22:00:56+00:00Limit maximum multipart/form-data pairs and files2024-02-19T22:00:56+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-02-19T22:00:56+00:00urn:sha1:afe0681c0b26bb64bad55d7e86770f346cfa043e
A malicious user could inject an infinite number of empty files or
key/value pairs into a request in order to exhaust the device's
resources.
http.c: Solve performance issues on POST uploads2024-01-20T00:19:57+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2024-01-20T00:05:05+00:00urn:sha1:43be8d95f681c8240847b4f69a524a0ab20d5c83
Profiling showed that reading multipart/form POST uploads byte-by-byte
was too slow and typically led to maximum CPU usage. Therefore, the
older approach (as done up to commit 7efc2b3a) was more efficient, even
if the resulting code was a bit uglier.
http.c: Unify read operations2023-11-24T00:36:38+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-23T23:52:50+00:00urn:sha1:b0accd099fa8c5110d4c3c68830ad6fd810ca3ec
So far, libweb would perform different read operations depending on its
state:
- For HTTP headers or request bodies, one byte at a time was read.
- For multipart/form-data, up to BUFSIZ bytes at a time were read.
However, this caused a significant extra number of syscalls for no
reason and would increase code complexity, specially when parsing
multiform/form-data boundaries.
Now, http_read always reads up to BUFSIZ bytes at a time and process
them on a loop. Apart from reducing code complexity, this should
increase performance due to the (much) lower number of syscalls
required.
http.c. Limit multipart/form-data to POST2023-11-20T15:34:24+00:00Xavier Del Campoxavier.delcampo@midokura.com2023-11-17T13:56:07+00:00urn:sha1:1750bbd7ec7277375c0ccd815cd2aed541e7e862http: Add support for PUT2023-11-20T15:34:24+00:00Xavier Del Campoxavier.delcampo@midokura.com2023-11-17T11:53:59+00:00urn:sha1:1755ee663cd67cd8d9adf9f06dd82b0477adab76
Notes:
- Since curl would use the "Expect: 100-continue" header field for PUT
operations, this was a good operation to fix the existing issues in its
implementation.
Breaking changes:
- expect_continue is no longer exclusive to struct http_post. Now, it
has been moved into struct http_payload and it is up to users to check
it.
Send HTTP headers to payload callback2023-11-18T00:03:12+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-17T23:56:04+00:00urn:sha1:65031ca3502e0c27780be847fd97c112546741a9
Even if libweb already parses some common headers, such as
Content-Length, some users might find it interesting to inspect which
headers were received from a request.
Since HTTP/1.1 does not define a limit on the number of maximum headers
a client can send, for security reasons a maximum value must be provided
by the user. Any extra headers shall be then discarded by libweb.
An example application showing this new feature is also provided.
http.c: Fix more issues with partial boundaries2023-11-12T22:31:57+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-12T22:31:57+00:00urn:sha1:b71a6174e12b4709acaf8bc151938ba12d2a54f6
- http_memmem must not check strlen(a) > n because, in case of a partial
boundary, it would wrongfully return NULL.
- If one or more characters from a partial boundary are found at the end
of a buffer, but the next buffer does not start with the rest of the
boundary, the accumulated boundary must be reset, and then look for a
new boundary.
http.c: Fix several issues with partial boundaries2023-11-12T05:52:48+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-12T05:16:26+00:00urn:sha1:7d02b225fe11fb0c7233cd2ea576485ee920f203
- Writing to m->boundary[len] did not make any sense, as len is not
meant to change between calls to read_mf_boundary_byte.
- For the same reason, memset(3)ing "len + 1" did not make any sense.
- When a partial boundary is found, http_memmem must still return st.
- Calling reset_boundary with prev == 0 did not make sense, since that
case typically means a partial boundary was found on a previous
iteration, so m->blen must not be reset.
http: Make http_decode_url return int2023-11-12T00:29:54+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-11T23:14:05+00:00urn:sha1:9ac68fd76c43523ea3aa3bcc4f9fef0ac2cee830
So far, it was not possible callers to distinguish between decoding
errors, as caused by ill-formed input, from fatal errors.
http.c: Avoid use of dynstr_append_or_ret_nonzero2023-11-12T00:29:54+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-11-11T23:50:06+00:00urn:sha1:957ac188e57cbb16db183fbd0fc87b09fea8e20c
This macro would return a positive integer on failure. However,
functions called by http_update should only return a positive integer
for user input-related errors, not fatal errors such as those related to
failed memory allocations.