xavi/slcl/http.c, branch test-multiformSmall and lightweight cloud storage written in C99 and POSIX.1-2008.
https://gitea.privatedns.org/xavi/slcl/atom?h=test-multiform2023-07-20T23:40:55+00:00Remove files now provided by slweb2023-07-20T23:40:55+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-20T23:07:57+00:00urn:sha1:7fe639b3ba7a253627d2cd34f3b97bd95b0a90b3http.c: Disallow forbidden filenames during upload2023-07-09T03:41:43+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-09T02:16:31+00:00urn:sha1:fbd730754b83dd9ae95d9b308e29ba7e85001528
- '.' or '..' must not be used for filenames.
- Filenames must not contain forward slashes ('/').
- Filenames must not contain asterisks ('*') to avoid confusion with
wildcard expressions.
http.c: Use case-insensitive compare for Content-Disposition2023-07-09T02:14:14+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-09T02:14:14+00:00urn:sha1:fa8217c511a0ff732be1c02921e105597ced7850
HTTP headers are case-insensitive, so the implementation must accept
Content-Diposition, content-disposition or any other variation.
http.c: Accept resources with '&' or '?'2023-07-05T22:19:05+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-07-05T21:34:36+00:00urn:sha1:7bd56e69dccec2794a7b568eb254a40f96b900c5
Otherwise, client requests to resources such as '/me & you', '/?' or
'/??preview=1' would fail.
Avoid crashing on SIGPIPE2023-05-01T02:13:25+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-05-01T01:06:34+00:00urn:sha1:9c7a2e91285ca91d500cc828ad041a264128db4d
Under some circumstances, clients could cause SIGPIPE to slcl. Since
this signal was not handled by server.c (i.e., via sigaction(3)), slcl
would crash without any error messages printed to stderr.
In such situation, SIGPIPE should not be usually considered a fatal
error, so it is preferrable to close the connection and keep working.
http.c: Decode URL resource and parameters separately2023-05-01T02:13:25+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-04-30T21:43:10+00:00urn:sha1:7d1e41f9c51bc1525e5b0c86b9832562d65675c1
Given the following contrived example request:
/example%FB%DC&arg%DE1=examplevalue%AA
slcl must decode each token separately, so that percent-encoded
characters '&', '=' or '?' do not get accidently intepreted.
Fix missing error checks for strtoul(3)2023-05-01T02:13:25+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-04-30T20:12:57+00:00urn:sha1:401c5dcf444b50d4fffa66f790aa0ee6a919a967Return error if write_ctx_free fails2023-05-01T02:13:25+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-04-28T22:31:12+00:00urn:sha1:cfd0a6f7743494f63c6ac5af15bbd3e762591961
Otherwise, write_body_mem and write_body_mem would silently fail,
causing undefined behaviour.
Notes:
The return value for write_ctx_free is currently assigned to that of
fclose(3), which can be either 0 on success or EOF on failure.
However, it makes sense for write_body_mem and write_body_mem to simply
check against non-zero.
Also, it would not be sensible to return EOF to caller functions, which
expect either 0 (success), -1 (fatal error) or 1 (input error).
Remove HTTP/1.0 support2023-05-01T02:13:24+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-04-27T22:30:44+00:00urn:sha1:30a101717c8ac825f6ce676c6d717964f19307a8
Considering http.h defined HTTP/1.1-only responses such as "303 See
Other", as well as incoming HTTP/1.1-only features (e.g.: byte serving),
it did not make much sense to keep a somewhat broken compatibility
against HTTP/1.0.
Unfortunately, this breaks support with some existing clients such
as lynx(1), even if HTTP/1.0 was already deprecated many years ago.
However, even lynx(1) can be configured to support HTTP/1.1.
Support URL parameters2023-04-23T03:09:53+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-04-23T03:09:53+00:00urn:sha1:011807e1d69d196cd0b9fd39a9899eb335c81abf
Now, http_payload includes a list of human-readable parameters that can
be read (but not modified) by users. Given the following example link:
/test?key1=value1&key2=value2
This will generate two parameters, with the following values:
{
.args =
{
[0] = {.key = "key1", .value = "value1"},
[1] = {.key = "key2", .value = "value2"}
},
.n_args = 2
}
As expected, if any URL parameters are given, struct http_payload member
"resource" is accordingly trimmed so as not to include any parameters.
Therefore, considering the example above:
{.args = {...}, .resource = "/test"}
Limitations:
- Since the definition of struct http_arg is both shared by http.h
(as a read-only pointer within struct http_payload) and http.c
(as a read/write pointer within struct ctx), its members (namely key
and value) must remain as read/write pointers, even if they must not
be modified by users of http.h.