xavi/slcl/http.c, branch searchSmall and lightweight cloud storage written in C99 and POSIX.1-2008.
https://gitea.privatedns.org/xavi/slcl/atom?h=search2023-05-01T02:13:25+00:00Avoid 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.
Define _POSIX_C_SOURCE2023-03-24T01:49:11+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-03-24T01:47:11+00:00urn:sha1:b3ef22ac2ae126951c5b74003c7b17189c0ecbbb
This allows using the default compiler defined by make(1) (i.e.,
c99(1)), thus improving POSIX compatibility.
http.c: Add missing #include2023-03-24T01:46:55+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-03-24T01:46:55+00:00urn:sha1:4501c66ebde5c4fc86eda193fe204d5b35e85652
As required by strncasecmp(3).
Send response on quota exceeded2023-03-20T09:57:20+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-03-20T02:32:00+00:00urn:sha1:d9bb874591c63f2efbfc1c4c953934251c700e9f
So far, slcl would just close the connection with a client when the
Content-Length of an incoming request exceeded the user quota, without
any meaningful information given back to the user.
Now, slcl responds with a HTML file with meaningful information about
the error.
Limitations:
- While this commits has been successfully tested on ungoogled-chromium,
LibreWolf (and I assume Firefox and any other derivates too) does not
seem to receive the response from the server.
- However, this issue only occurred during local testing, but not
on remote instances.
http.c: Minor formatting change2023-03-08T17:52:36+00:00Xavier Del Campo Romeroxavi.dcr@tutanota.com2023-03-08T17:52:36+00:00urn:sha1:e0fc222f1d3dc1a6672bdbbd7009b08cfd49d776