Given the following contrived example request:
/example%FB%DC&arg%DE1=examplevalue%AA
slcl must decode each token separately, so that percent-encoded
characters '&', '=' or '?' do not get accidently intepreted.
Otherwise, write_body_mem and write_body_mem would silently fail,
causing undefined behaviour.
Notes:
The return value for write_ctx_free is currently assigned to that of
fclose(3), which can be either 0 on success or EOF on failure.
However, it makes sense for write_body_mem and write_body_mem to simply
check against non-zero.
Also, it would not be sensible to return EOF to caller functions, which
expect either 0 (success), -1 (fatal error) or 1 (input error).
Considering http.h defined HTTP/1.1-only responses such as "303 See
Other", as well as incoming HTTP/1.1-only features (e.g.: byte serving),
it did not make much sense to keep a somewhat broken compatibility
against HTTP/1.0.
Unfortunately, this breaks support with some existing clients such
as lynx(1), even if HTTP/1.0 was already deprecated many years ago.
However, even lynx(1) can be configured to support HTTP/1.1.
Now, http_payload includes a list of human-readable parameters that can
be read (but not modified) by users. Given the following example link:
/test?key1=value1&key2=value2
This will generate two parameters, with the following values:
{
.args =
{
[0] = {.key = "key1", .value = "value1"},
[1] = {.key = "key2", .value = "value2"}
},
.n_args = 2
}
As expected, if any URL parameters are given, struct http_payload member
"resource" is accordingly trimmed so as not to include any parameters.
Therefore, considering the example above:
{.args = {...}, .resource = "/test"}
Limitations:
- Since the definition of struct http_arg is both shared by http.h
(as a read-only pointer within struct http_payload) and http.c
(as a read/write pointer within struct ctx), its members (namely key
and value) must remain as read/write pointers, even if they must not
be modified by users of http.h.
So far, slcl would just close the connection with a client when the
Content-Length of an incoming request exceeded the user quota, without
any meaningful information given back to the user.
Now, slcl responds with a HTML file with meaningful information about
the error.
Limitations:
- While this commits has been successfully tested on ungoogled-chromium,
LibreWolf (and I assume Firefox and any other derivates too) does not
seem to receive the response from the server.
- However, this issue only occurred during local testing, but not
on remote instances.
Until now, f->tmpname was removed by move_file when the move
operation succeeded. However, since a HTTP operation can fail before
move_file is called, the temporary file must also be removed.
This feature allows admins to set a specific quota for each user, in
MiB. This feature is particularly useful for shared instances, where
unlimited user storage might be unfeasible or even dangerous for the
server.
Also, a nice HTML5 <progress> element has been added to the site that
shows how much of the quota has been consumed.
If no quota is set, slcl falls back to the default behaviour i.e.,
assume unlimited storage.
Limitations:
- While HTTP does specify a Content-Length, which determines the length
of the whole request, it does not specify how many files are involved
or their individual sizes.
- Because of this, if multiple files are uploaded simultaneously, the
whole request would be dropped if user quota is exceeded, even if not
all files exceeded it.
- Also, Content-Length adds the length of some HTTP boilerplate
(e.g.: boundaries), but slcl must rely on this before accepting the
whole request. In other words, this means some requests might be
rejected by slcl because of the extra bytes caused by such boilerplate.
- When the quota is exceeded, slcl must close the connection so that
the rest of the transfer is cancelled. Unfortunately, this means no
HTML can be sent back to the customer to inform about the situation.
Cookies without "Expires" are considered non-persistent and thus can be
removed by the web browser. Instead, slcl now sets persistent cookies
that last for 1 year.
According to C99 §7.20.3.4:
If memory for the new object cannot be allocated, the old object is not
deallocated and its value is unchanged.
Therefore, a temporary pointer must be used to ensure the original
object can still be deallocated should realloc(3) return a null pointer.
