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.
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.
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"