Small and lightweight web framework written in C99 and POSIX.1-2008. https://gitea.privatedns.org/xavi/libweb/atom?h=v0.1.0-rc5 2023-10-10T22:07:13+00:00 2023-10-10T22:07:13+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-10-10T21:21:35+00:00 urn:sha1:0222b75e8554796548e079aa3393c512ae30ac24 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. 2023-10-10T21:15:26+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-10-02T21:37:44+00:00 urn:sha1:07e0063870725506447a0ad29a6b92bb8c8c4e0b 2023-09-09T00:32:34+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-09T00:22:00+00:00 urn:sha1:5be3ffdd3bfd96b314509f6f03e211e309d0fef3 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. 2023-09-08T22:39:43+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-08T22:36:26+00:00 urn:sha1:34d716082a0136056373f3d0c6ed7abce45484b3 Whereas slcl, the project where slweb started, ignored this field, some applications might require it. 2023-09-08T22:21:42+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-08T22:19:39+00:00 urn:sha1:09909c0a3b326efd6a2b87df95d0e73c1e394c29 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. 2023-09-07T14:01:37+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-07T14:01:37+00:00 urn:sha1:6c7faa7f9063aca15345c9aeb95d651a5fe983f9 According to C99 7.19.1p3: BUFSIZ is a macro that expands to an integer constant expression that is the size of the buffer used by the setbuf function. In other words, this means BUFSIZ is the most optimal length for a buffer that reads a file into memory in chunks using fread(3). Note: the number of bytes sent to the client might be less than BUFSIZ, so this would act as a bottleneck, no matter how large the buffer passed to fread(3) is. 2023-09-07T11:45:10+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-07T11:40:11+00:00 urn:sha1:083dedbb9d068caed31b8c92ba69fc88ab80d009 Otherwise, fatal errors coming from the h->cfg.length would be unnoticed, causing slweb to attempt to send a response. 2023-08-12T23:23:48+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-08-12T23:23:48+00:00 urn:sha1:f6562ddab30feb4bb63d9cda9801dbf607c33d07 Both functions were in fact identical, so there was no reason to keep two definitions rather than one. 2023-08-01T00:24:28+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-08-01T00:24:28+00:00 urn:sha1:3a3fdbe8a5bfe24c63b6f31071de5739ab49ed49 2023-07-20T23:28:38+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-07-20T21:47:33+00:00 urn:sha1:8c3ba33ced08b211db0cd5f81675bdf62f55acc7 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"