| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
A new function pointer, namely chunk, has been added to struct
http_response so that library users can generate their message bodies
dynamically.
|
| |
|
|
|
|
|
|
|
| |
libweb calls listen(2) when setting up the HTTP server, and its backlog
argument was hardcoded to 10. While probably not an issue for some
applications, it can be too limiting for some others.
Therefore, it is desirable to allow library users to set up their own
limits. Otherwise, 10 is still chosen as a sane default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct http_response did not provide users any void * that could be used
to maintain a state between calls to an asynchronous HTTP response.
On the other hand, the user pointer could not be used for this purpose,
since it is shared among all HTTP clients for a given struct handler
instance.
Moreover, the length callback was still not supporting this feature,
which in fact might be required by some users. Implementing this was
particularly challenging, as this broke the current assumption that
all bytes on a call to http_read were being processed.
Now, since a client request can only be partially processed because of
the length callback, http_read must take this into account so that the
remaining bytes are still available for future calls, before reading
again from the file descriptor.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Sometimes, library users cannot return a HTTP response as soon as the
request is received, or the operations that are required to generate it
can take a long time.
In order to solve this, libweb adds a new member to struct
http_response, namely step, which must be assigned to a function
whenever a HTTP response should be generated in a non-blocking manner.
Leaving the function pointer as null will fall back to the default
behaviour.
|
| |
|
|
|
| |
libweb is meant to be silent during normal operation, thus only printing
to stderr on errors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, libweb installed a signal handler so as to handle SIGTERM,
SIGPIPE and SIGINT signals so that processes would not have to care
about such details.
However, it is not advisable for libraries to install signal handlers,
as signals are handled on a per-process basis. The previous approach
would be incompatible if several instances of the library were allocated
by the same process.
Unfortunately, this has the undesired side effect of adding the
boilerplate code into the process.
|
| |
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| | |
from midokura-xavi/libweb:fix-double-free into master
Reviewed-on: https://gitea.privatedns.org/xavi/libweb/pulls/2
|
| | |
| |
| |
| |
| | |
Even if server_client_close fails, it is needed for client_free to
remove the dangling reference from h->clients.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some applications might set up a struct handler object to listen on any
port i.e., 0, but still need a way to determine which port number was
eventually selected by the implementation.
Therefore, handler_listen has been reduced to the server initialization
bit, whereas the main loop has been split into its own function, namely
handler_loop.
Because of these changes, it no longer made sense for libweb to write
the selected port to standard output, as this is something now
applications can do on their own.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It was found out there was another project of the same name around
(https://git.sr.ht/~strahinja/slweb/), also related to website
generation.
In order to avoid confusion, a new name has been chosen for this
project. Surprisingly, libweb was not in use by any distributions
(according to https://repology.org and AUR index), and it should
reflect well the intention behind this project i.e., being a library
to build web-related stuff.
|
| |
|
|
|
| |
Port numbers are unsigned by definition. Fortunately, this was a minor
issues since server_init was doing an implicit cast to unsigned short.
|
| |
|
|
|
|
|
|
|
|
|
| |
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"
|
| |
|
|
| |
The new search feature will require them.
|
| |
|
|
| |
Future commits will make use of this function outside handler.c.
|
| |
|
|
|
|
| |
select(2) has a number of well-known issues (e.g.: FD_SETSIZE limiting
the maximum amount of file descriptors to watch) that are mostly solved
by poll(2) and thus can be used as a drop-in replacement.
|
| |
|
|
|
| |
This allows using the default compiler defined by make(1) (i.e.,
c99(1)), thus improving POSIX compatibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This feature allows admins to set a specific quota for each user, in
MiB. This feature is particularly useful for shared instances, where
unlimited user storage might be unfeasible or even dangerous for the
server.
Also, a nice HTML5 <progress> element has been added to the site that
shows how much of the quota has been consumed.
If no quota is set, slcl falls back to the default behaviour i.e.,
assume unlimited storage.
Limitations:
- While HTTP does specify a Content-Length, which determines the length
of the whole request, it does not specify how many files are involved
or their individual sizes.
- Because of this, if multiple files are uploaded simultaneously, the
whole request would be dropped if user quota is exceeded, even if not
all files exceeded it.
- Also, Content-Length adds the length of some HTTP boilerplate
(e.g.: boundaries), but slcl must rely on this before accepting the
whole request. In other words, this means some requests might be
rejected by slcl because of the extra bytes caused by such boilerplate.
- When the quota is exceeded, slcl must close the connection so that
the rest of the transfer is cancelled. Unfortunately, this means no
HTML can be sent back to the customer to inform about the situation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
According to C99 §7.20.3.4:
If memory for the new object cannot be allocated, the old object is not
deallocated and its value is unchanged.
Therefore, a temporary pointer must be used to ensure the original
object can still be deallocated should realloc(3) return a null pointer.
|
| |
|
