Age | Commit message (Collapse) | Author |
|
Using GCC 12 on an aarch64 target the following compilation error is
printed.
ninja: Entering directory `/home/ansuel/openwrt/build_dir/target-aarch64_cortex-a53_musl/uhttpd-2022-02-07-2f8b1360'
[1/2] Building C object CMakeFiles/uhttpd.dir/client.c.o
FAILED: CMakeFiles/uhttpd.dir/client.c.o
/home/ansuel/openwrt/staging_dir/host/bin/ccache /home/ansuel/openwrt/staging_dir/toolchain-aarch64_cortex-a53_gcc-12.1.0_musl/bin/aarch64-openwrt-linux-musl-gcc -DHAVE_LUA -DHAVE_SHADOW -DHAVE_TLS -DHAVE_UBUS -DHAVE_UCODE -D_FILE_OFFSET_BITS=64 -Os -pipe -mcpu=cortex-a53 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -fmacro-prefix-map=/home/ansuel/openwrt/build_dir/target-aarch64_cortex-a53_musl/uhttpd-2022-02-07-2f8b1360=uhttpd-2022-02-07-2f8b1360 -Wformat -Werror=format-security -DPIC -fPIC -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -DNDEBUG -Os -Wall -Werror -Wmissing-declarations --std=gnu99 -g3 -MD -MT CMakeFiles/uhttpd.dir/client.c.o -MF CMakeFiles/uhttpd.dir/client.c.o.d -o CMakeFiles/uhttpd.dir/client.c.o -c /home/ansuel/openwrt/build_dir/target-aarch64_cortex-a53_musl/uhttpd-2022-02-07-2f8b1360/client.c
In function 'tls_redirect_check',
inlined from 'client_header_complete' at client.c:306:7,
inlined from 'client_parse_header' at client.c:338:3,
inlined from 'client_header_cb' at client.c:502:2:
client.c:269:22: error: 'strcmp' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
269 | if (!strcmp(blobmsg_name(cur), "URL"))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.
Fix this by using the strncmp variant.
Signed-off-by: Christian 'Ansuel' Marangi <ansuelsmth@gmail.com>
|
|
When we run into an error like a 404 Not Found the request body is not
read and will be parsed as part of the next request. The next Request
will then fail because there is unexpected data in it.
When we run into such a problem with a request body close return an
error and close the connection. This should be easier than trying to
recover the state.
We saw this problem when /ubus/ was not installed, but the browser tried
to access it. Then uhttpd returned a 404, but the next request done in
this connection also failed with a HTTP 400, bad request.
Fixes: FS#3378
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
|
When an uhttpd dispatch_handler provides a data_done callback which is
synchroneously finishing the request through ops->request_done(), the
calling client_poll_post_data() procedure incorrectly resets the resulting
client state from CLIENT_STATE_INIT to CLIENT_STATE_DONE which causes the
next uh_client_read_cb() invocation to bail out since no callback is
available for the CLIENT_STATE_DONE state, effectively discarding the
just received inbound request and sending the persistent connection state
into a deadlock sitation where the http client waits for a response to
its just sent request and uhttpd for further data to read.
Fix this issue by only setting CLIENT_STATE_DONE if the data_done callback
has not modified the state in the meanwhile.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
After specified time of network inactivity uhttpd is meant to close
connection. It doesn't seem to work thought. After timeout client
doesn't receive any more data but connection it still opened.
This change fixes that.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
|
Allow POST requests via persistent connections to improve performance
especially when using HTTPS on older devices.
After this change, average page load times in LuCI improve significantly
once the TLS connections are initiated.
When testing an ar71xx 19.07.2 build on an ethernet connected TL-WR1043nd
using luci-ssl-openssl and the ustream-openssl backend, the average page
load time for the main status page decreased to 1.3s compared to 4.7s
before, the interface and wireless configuration pages loaded in 1.2s
seconds each compared to the 4.2s and 4.9s respectively before.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
An invalid data access can be triggered with an HTTP POST request to a CGI
script specifying both `Transfer-Encoding: chunked` and a large negative
`Content-Length`.
The negative content length is assigned to `r->content_length` in
`client_parse_header` and passed as a negative read length to
`ustream_consume` in `client_poll_post_data` which will set the internal
ustream buffer pointer to an invalid address, causing out of bounds memory
reads later on in the code flow.
A similar implicit unsigned to signed conversion happens when parsing
chunk sizes emitted by a CGI program.
Address these issues by rejecting negative values in `r->content_length`
after assigning the `strtoul()` result.
Reported-by: Jan-Niklas Sohn <jan-niklas.sohn@gmx.de>
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
Adds ifdefs to fix building without TLS and Lua support
Signed-off-by: Paul Willoughby <paulw@spacemonkey.com>
|
|
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
When the outer SSL ustream triggers a change notification due to
encountering EOF, the inner connection ustream might still have
pending data buffered.
Previously, such a condition led to truncated files delivered by
uhttpd via HTTPS and could be triggered by requesting large resources
via slow network links.
Mitigate the problem by propagating the EOF status indicator from
the outer ustream to the inner one and by deferring the client
connection shutdown until the inner ustream output buffer has been
completely drained.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The two commits
5162e3b0ee7bd1d0fd6e75e1ca7993a1834b5291
"allow request handlers to disable chunked reponses"
and
618493e378e2239f0d30902e47adfa134e649fdc
"file: disable chunked encoding for file responses"
broke the chunked transfer encoding handling for proc responses in keep-alive
connections that followed a file response with http status 204 or 304.
The effect of this bug is that cgi responses following a 204 or 304 one where
sent neither in chunked encoding nor with a content-length header, causing
browsers to stall until the keep alive timeout was reached.
Fix the logic flaw by inverting the chunk prevention flag in the client state
and by testing the chunked encoding preconditions every time instead of
once upon client (re-)initialization.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
Use the 307 code to force agents to retain the original request method.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
Certain response types (notably 204 and 304) require a slightly different
handling like emitting the response body entirely, therfore record the last
code to act on it in the appropriate places.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
In order to support cross-domain AJAX requests to the /ubus endpoint
we need to implement the Cross-Origin Resource Sharing (CORS) spec
in the ubus plugin.
- Implement a new option "-X" to enable CORS support in ubus
- Implement rudimentary support for "OPTIONS" HTTP requests
- Implement essential CORS headers the ubus plugin
The current CORS response headers merely reflect the request headers
sent by the client, this way any requesting origin is automatically
allowed. Cross-domain cookies (Access-Control-Allow-Credentials) are
unconditionally enabled.
Restricting permitted origins and toggle the credential accepting can
be made configurable in a future commit to allow more fine grained
control over permitted AJAX clients.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
|
|
The ubus plugin calls blocking ubus functions that loop back into
uloop_run. Protect the client data structure with refcounting to ensure
that the outer uloop_run call does not clean up the data that the inner
uloop_run call is still processing.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Fixes a per-SSL-connection memory leak
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
calls to 3, maximum number of connections to 100
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
for the connection: close|keep-alive header
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|