| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Suprisingly, this man page was missing on the 0.1.0 release.
The recent signature changes on http_decode_url have already been
reflected.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
