dynstr got its v0.1.0-rc1 release, and this commit introduces a fix:
commit 0e779caae658f118d535e9f0a74f0012eefca9a0
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Mon Oct 2 14:38:53 2023 +0200
CMakeLists.txt: add cmake_minimum_required
This command is mandatory for all CMake projects. 3.0 was chosen since
dynstr does not require any newer CMake features.
application/x-www-form-urlencoded-data is (or should be) always text, so
it is preferrable to define struct http_post member "data" as a null-
terminated string.
For applications already making this assumption, this change should now
remove the need for string duplication.
Now, slweb accepts requests such as:
--boundary
Content-Disposition: form-data; name="field1"
value1
--boundary
Content-Disposition: form-data; name="field2"
value2
--boundary
Content-Disposition: form-data; name="field3"; filename="example.txt"
The following breaking changes have been introduced:
Member "dir" from struct http_post was a leftover from the days where
slcl and slweb were one project. It did not make sense for slweb, since
it should not decide which Content-Disposition names are allowed. In
other words, "dir" was only relevant in the scope of slcl.
Member "n" from struct http_post used to have two meanings:
- The length of a URL-encoded request.
- The number of files on a multipart/form-data request.
Since "npairs" had to be introduced to struct http_post, it did not make
sense to keep this dual meaning any more. Therefore, "n" has been
restricted to the former, whereas a new member, called "nfiles", has
been introduced for the latter.
According to C99 7.19.1p3:
BUFSIZ is a macro that expands to an integer constant expression that is
the size of the buffer used by the setbuf function.
In other words, this means BUFSIZ is the most optimal length for a
buffer that reads a file into memory in chunks using fread(3).
Note: the number of bytes sent to the client might be less than BUFSIZ,
so this would act as a bottleneck, no matter how large the buffer passed
to fread(3) is.
Despite designed around portability and minimalism, I feel slweb no
longer aligns with the philosophical views from the suckless project.
Therefore, I think it was appropriate to unlink its branding from it.
Since slweb is meant as a library, it is advisable to keep public header
files under their own directory in order to avoid name clashing i.e.,
#include "something.h"
Now becomes:
#include "slweb/something.h"
slcl used to provide a hardcoded stylesheet. However, it would be
desirable for some admins to provide a custom stylesheet without having
to rebuild the application.
Now, slcl creates a default stylesheet, namely style.css, into the
target directory, that can be later modified by admins.
While this might contradict the suckless philosophy a bit, hopefully
some admins might find this new feature useful.
When the distance between '*' on a wildcard expression was larger than
the string to compare with, this would cause an out-of-bounds read
because `n` was not being limited to the strlen(3) from the input
string.
Example:
- s="c", p="*cc*", casecmp=false
Here, the distance between the first and second '*' is 2 bytes, which is
longer than the input string itself (1 byte, not counting the
terminating null byte '\0').
- '.' or '..' must not be used for filenames.
- Filenames must not contain forward slashes ('/').
- Filenames must not contain asterisks ('*') to avoid confusion with
wildcard expressions.
server.c kept an array of all of its active clients, calling realloc(3)
everytime its size had to be modified. However, reallocating this array
had the undesired consequence of moving other active clients to other
memory locations.
Potentially, this would result in dangling pointers from other
components that also kept pointers to struct server_client instances
e.g.: handler.c.
For this reason, the array-based approach has been completely dropped,
in favour of a doubly-linked list.
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.
