| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
https://gitea.privatedns.org is a small Gitea instance running on a home
server, which might be problematic for large deployments.
|
| | |
|
| |\
| |
| |
| |
| |
| | |
midokura-xavi/libweb:put into master
Reviewed-on: https://gitea.privatedns.org/xavi/libweb/pulls/3
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notes:
- Since curl would use the "Expect: 100-continue" header field for PUT
operations, this was a good operation to fix the existing issues in its
implementation.
Breaking changes:
- expect_continue is no longer exclusive to struct http_post. Now, it
has been moved into struct http_payload and it is up to users to check
it.
|
| |\
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/|
| |
| |
| | |
from midokura-xavi/libweb:listen-port into master
Reviewed-on: https://gitea.privatedns.org/xavi/libweb/pulls/1
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
| |
Similarly to other projects within the free software community, a
generic term is used so as to avoid listing every single contributor to
the project.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
- http_memmem must not check strlen(a) > n because, in case of a partial
boundary, it would wrongfully return NULL.
- If one or more characters from a partial boundary are found at the end
of a buffer, but the next buffer does not start with the rest of the
boundary, the accumulated boundary must be reset, and then look for a
new boundary.
|
| |
|
|
|
|
|
|
|
|
| |
- Writing to m->boundary[len] did not make any sense, as len is not
meant to change between calls to read_mf_boundary_byte.
- For the same reason, memset(3)ing "len + 1" did not make any sense.
- When a partial boundary is found, http_memmem must still return st.
- Calling reset_boundary with prev == 0 did not make sense, since that
case typically means a partial boundary was found on a previous
iteration, so m->blen must not be reset.
|
| |
|
|
|
|
|
| |
Suprisingly, this man page was missing on the 0.1.0 release.
The recent signature changes on http_decode_url have already been
reflected.
|
| |
|
|
|
| |
So far, it was not possible callers to distinguish between decoding
errors, as caused by ill-formed input, from fatal errors.
|
| |
|
|
|
|
|
| |
This macro would return a positive integer on failure. However,
functions called by http_update should only return a positive integer
for user input-related errors, not fatal errors such as those related to
failed memory allocations.
|
| |
|
|
| |
As opposed to GET or POST requests, HEAD must not write any body bytes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The commit below is relevant to fix CMake builds:
Author: Xavier Del Campo Romero <xavi.dcr@tutanota.com>
Date: Fri Nov 10 14:43:39 2023 +0100
CMakeLists.txt: Fix missing parameter names
VERSION must be indicated when passing a version string to project().
Also, LANGUAGES must be also be passed when the language name is not the
only argument to project() (apart from the project name itself).
|
| |
|
|
|
| |
When the language name is not the only argument for project() (other
than the project name itself), LANGUAGES must be indicated.
|
| |
|
|
|
| |
Only the latter is defined by POSIX.1-2008. Even if there are still some
non-portable flags defined by CFLAGS, it is a good idea to reduce them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
| |
This shall be replaced with more meaningful man pages for all functions
in slweb.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Default value for a CMake option() must always be passed as the third
parameter.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
Whereas slcl, the project where slweb started, ignored this field, some
applications might require it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|