slweb now assumes application/x-www-form-urlencoded-data as text, so it
now returns a null-terminated string on struct http_post member "data".
This removes the need for slcl to call strdup(3) in order to obtain a
null-terminated string.
For historical reasons, slweb used to check for a name called "dir" on
multipart/form-data POST requests. However, stricly speaking this is
application logic, so it has been now moved from slweb to slcl.
This has resulted in a couple of breaking changes in slweb that had to
be updated on slcl.
d55b84f68b90fe5c2521724d0c22ebf22e62b0b4 introduces a bugfix:
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Tue Aug 8 00:32:21 2023 +0200
html.c: Fix wrong encoding for '>' and '<'
Despite designed around portability and minimalism, I feel slcl no
longer aligns with the philosophical views from the suckless project.
Therefore, I think it was appropriate to unlink its branding from it.
slweb contains the HTTP/1.1 server implementation and surrounding
utilities that are used by slcl. The motivation behind this was to allow
these components to be used by other projects, as well as effectively
making slcl smaller and more modular.
When a user enters a search term that is too generic, slcl would
generate a long list of search results, where this generation could have
a big impact on the server performance and its available resources.
Therefore, it is reasonable to limit the number of search results to an
arbitrary limit, so that users are forced to enter a more specific
search term in order to achieve more relevant results.
So far, cftw would search through all directories and files recursively,
until all objects are processed. However, it is interesting for the user
callback to be able to stop this process under specific circumstances.
Now, cftw will pass a pointer to a bool, initialised to false by
default, that can be optionally assigned to true by the user
callback.
Future commits will make use of this feature. For example, this will be
used to limit the number of search results when a user enters a search
term that is too generic and would otherwise generate a large amount of
search results.
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.
- The back button would not return to the previous directory, but to the
user root directory.
- While this could have been solved easily (e.g.: by inserting the
referrer directory into the form), it would have implied extra and
unneeded complexity.
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').
- Relative paths must not be used for filenames or directory names,
such as "..", "." or "dir/..".
- Paths with asterisks ('*') must not be allowed, to avoid confusion
with wildcard expressions.
- '.' or '..' must not be used for filenames.
- Filenames must not contain forward slashes ('/').
- Filenames must not contain asterisks ('*') to avoid confusion with
wildcard expressions.
The following workflow has been implemented:
- A new checkbox for each object inside a directory is shown.
- When one or more objects are selected, the user submits a request
through a HTML5 form.
- Then, slcl will ask the user for confirmation, listing the selected
objects, while reminding the user about the effects.
- The user confirms the selection.
- slcl removes the selected objects. All objects from non-empty
directories are removed, too.
- Finally, slcl redirects the user to the directory the request was
made from.
This provides a few benefits:
- This will allow searching for directories by name.
- Future commits will allow to remove files and directories, so this
change was also required for cftw.
When search_fn fails, it must free `r` before `results`, as the former
is assigned based on the latter - otherwise, it would lead to undefined
behaviour.
So far, only memory allocation errors would make search_fn to fail.
According to POSIX.1-2017, applications are advised to assign errno(3)
to 0 before a call to readdir(3), and compare errno(3) after the call to
check for errors.
C99 §5.1.2.2.1 only defines the following declarations for main:
- int main(void)
- int main(int argc, char *argv[])
While the use of equivalent types (e.g.: char **argv) is allowed, const
char ** would not be considered equivalent, and thus an invalid
declaration depending on the implementation.
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.
This new feature adds a HTML form on each directory listing that allows
to search files recursively, starting from the current user directory.
Wildcard patterns are also allowed.
Otherwise, this would generate strings such as "directory//resource" if
dirpath contained a trailing slash, which could be problematic for users
relying on ctfw.
