Small and lightweight web framework written in C99 and POSIX.1-2008. https://gitea.privatedns.org/xavi/libweb/atom?h=v0.2.0 2023-11-20T15:34:24+00:00 2023-11-20T15:34:24+00:00 Xavier Del Campo xavier.delcampo@midokura.com 2023-11-17T11:53:59+00:00 urn:sha1:1755ee663cd67cd8d9adf9f06dd82b0477adab76 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. 2023-11-20T15:06:19+00:00 Xavier Del Campo xavier.delcampo@midokura.com 2023-11-16T11:23:08+00:00 urn:sha1:98f5f52461b0c1ab1ee3331722bd32e2db9e1d41 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. 2023-11-18T00:03:12+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-11-17T23:56:04+00:00 urn:sha1:65031ca3502e0c27780be847fd97c112546741a9 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. 2023-11-12T00:29:54+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-11-11T23:14:05+00:00 urn:sha1:9ac68fd76c43523ea3aa3bcc4f9fef0ac2cee830 So far, it was not possible callers to distinguish between decoding errors, as caused by ill-formed input, from fatal errors. 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-27T19:55:58+00:00 Xavier Del Campo Romero xavi.dcr@tutanota.com 2023-09-26T23:07:54+00:00 urn:sha1:0d54bbf08674174c1e7b91ce39984c29b78cf0ba This shall be replaced with more meaningful man pages for all functions in slweb. 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.