A _res_fallback parameter to HTTP_SERVICE_DEFINE is added to optionally
specify a fallback resource detail, which will be served if no other
resource matches the URL.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Fixes#84198.
If a '?' character is used as part of a wildcard resource, do not treat
this as the end of the string when comparing with a path from the HTTP
request. Only the path from the HTTP request may be terminated by '?'
(in the case of a request with query parameters).
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Content-Range functionality added in recent commits has been propagated
to http_client module. If "Content-Range" string is detected on header
field, Content-Range are returned via http_response structure.
Signed-off-by: Piotr Radecki <piotr.radecki@jrdltd.co.uk>
Content-Range hasn't been supported in zephyr. This change adds
Content-Range header parsing to http_parser module. Range start,
range end, and total size are supported. All units are currently
interpreted as bytes.
This is much needed change, because many applications responsible
for http data download are based on Content-Range approach.
Signed-off-by: Piotr Radecki <piotr.radecki@jrdltd.co.uk>
Template string for HTTP 1.0 500 response expects content length as a %d
but was getting passed a 'long unsigned int' instead of an 'int'.
Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
In case of errors during HTTP2 request processing (or after the HTTP1
upgrade response was sent), send 500 Internal Server Error response
before shutting down the connection.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Since there is a helper function to generate/send headers frame, the
flag can be set there instead of being set separately in various places.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case of internal server errors during HTTP1 request processing,
send 500 Internal Server Error response before shutting down the
connection.
Make sure http1_headers_sent is set whenever sever starts replying, to
avoid duplicate response in case of errors, as that would be protocol
violation.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Reply with 405 Method not allowed not only for static FS resource types,
but also for others. Also, the method checking for for static resources
was messed up - those resource types only support GET by design, so no
need to compare resource method bitmask - it should be checked that the
request was actually GET instead.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When serving a static file to the HTTP client, we need to supply also
content length field so that the connection can be closed immediately
when the file is fully sent.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Ensure that HTTP resources can only be served to a client connected on
the specific service(s) that the resource was registered against using
the HTTP_RESOURCE_DEFINE macro.
This allows different resources to be registered to different services,
for example to make some resources only available via an HTTPS service
and not via unencrypted HTTP.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Passing HTTP upgrade request context to the user callback allows the
user to decide whether to accept or reject the websocket connection
based on the HTTP headers in the request. The primary reason for this is
to enable authentication of the websocket connection (e.g. via cookies
or Authorization header).
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Extend the list of methods supported by dynamic resources with
PUT/PATCH/DELETE. The methods does not require any extra handling
from the server perspective, so the existing method handlers could be
reused.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Concurrent HTTP POST requests on different HTTP2 concurrent streams
require that the client's header_capture_context is re-used to capture
headers on a second stream before all of the body data has been received
(and sent to the application) on the first stream.
As a result, any captured headers must be sent to the application
callback before any headers can be received on a different stream. In
practice this means that for HTTP2 the application callback is called
for the first time on receiving a headers frame, before any data frames
are received. All subsequent application callbacks will not include the
request header data.
While this mechanism is not necessary for HTTP1, it is also updated to
only send headers in the first application callback for consistency.
Fixes#82273
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
To correctly handle concurrent HTTP POST requests via different http2
streams on the same client context, it is necessary to store the
resource detail at an HTTP2 stream level rather than at an HTTP client
level, otherwise only one resource detail can be stored.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Verify the result of the fs_read() operation when handling filesystem
resources, and abort processing the resource in case of errors.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Web browsers don't support HTTP Upgrade mechanism to upgrade to HTTP2.
Instead, HTTP2 is supported only over TLS, and ALPN is used to negotiate
the protocol to be used.
This commit adds the supported HTTP protocols to the ALPN list, so that
web browsers can use HTTP2 with the server.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
This creates a websocket based shell backend that is used to
implement a websocket console that can be connected using a browser.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
GCC 12.2.0 can give this warning (version 11.4.0 did not), when
CONFIG_SPEED_OPTIMIZATIONS=y
subsys/net/lib/http/http_client.c: In function 'http_send_data.constprop':
subsys/net/lib/http/http_client.c:114:33: warning: 'strncpy' specified
bound depends on the length of the source argument [-Wstringop-truncation]
114 | strncpy(send_buf + end_of_send,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
115 | data + end_of_data,
| ~~~~~~~~~~~~~~~~~~~
116 | remaining);
| ~~~~~~~~~~
subsys/net/lib/http/http_client.c:87:41: note: length computed here
87 | remaining_len = strlen(data + end_of_data);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
The code properly checks that we do not overwrite the destination
buffer even if we use the source buffer length to determine how much
to copy. One possible fix is to use memcpy() or strcpy(), I opted
to use memcpy() because it has the length option which feels more
natural.
Fixes#79326
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The http_client_req() function's timeout parameter is allowed
to be SYS_FOREVER_MS. However, K_MSEC() does not convert this
to a proper k_timeout_t, so sys_timepoint_calc() ends up
returning 0, which is causes immediate timeouts.
Check for this case specifically and force value passed to
sys_timepoint_calc() to be correct.
Signed-off-by: Pete Skeggs <peter.skeggs@nordicsemi.no>
The size_t type may vary from machines. Current snprintk code was
causing below build issue on arm64.
error: format '%x' expects argument of type 'unsigned int', but argument
4 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=].
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
After introduction of struct http_response_ctx, the dynamic resource
data buffer is no longer needed for transferring data between the
application callback and the server. It is therefore removed to avoid
unnecessary copying of data.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Add tests covering new method of providing a response for dynamic
resources.
Tests cover the application sending response codes and headers,
overriding "default" headers, and sending various combinations of
headers and body data. Each case is tested for HTTP1 & HTTP2, both POST
and GET methods.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Allow the application to send headers and response codes from a dynamic
resource callback by filling out a response context structure.
This also allows simple requests to be completed in a single execution
of the callback, by setting the final_chunk flag.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Fixing the regression caused by 3949873886 ("Allow service to be
created with NULL host"). If the host parameter is null when creating
the HTTP service, the IPv6 socket is created by default. This can cause
issues if both IPv4 and IPv6 are enabled, like in HTTP server sample,
and the HTTP client connection is done by IPv4.
To fix this, we need to enable IPv4-to-IPv6 mapping in order to allow
IPv6 socket to serve a IPv4 connection. Allow also user to override this
if needed.
Fixes#78112
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Allow application to register certain HTTP request headers to be stored
by the server. These stored headers can then be accessed from a dynamic
resource callback.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
Without this it is not possible to serve both IPv6 and IPv4
connections if service host is NULL.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Allow NULL host parameter when creating HTTP service. This means
that the socket is created without specifying binding address.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Using strncasecmp to match HTTP headers can give unexpected results when
the strings to be compared match up until the end of one string, but the
other string contains additional characters. This can result in falsely
matching a HTTP header value, for example:
strncasecmp("Upgrade-Something", "Upgrade", sizeof("Upgrade") - 1) --> 0
In this case we know that both strings are NULL terminated since one is
a string literal and we have just length-checked and explicitly NULL
terminated the other. So we can just use strcasecmp without a max
length.
Signed-off-by: Matt Rodgers <mrodgers@witekio.com>
http1_headers_sent flag has to be cleared when entering
HTTP_SERVER_REQUEST_STATE and not only on the client init. Otherwise,
serving multiple HTTP1 POST requests over the same connection does not
work as intended (headers were not sent for the second and further
requests).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
adds filesystem as a resource for the http_server which serves static
(gzipped) files from a filesystem to the client.
Signed-off-by: Gerhard Jörges <joerges@metratec.com>
In case no "Connection: close" header is present in the request, the
server should keep the connection open for the client. Hence, after
serving a request, we need to check if the header was present (the
parser sets a flag for it), and only close the connection immediately,
if the client requested it. In case the client remains silent, the
connection will be closed anyway after the inactivity timer kicks in.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case there were active connections when restarting the server, it
can't be re-initialized immediately, as binding to the server port will
fail. We need to wait for the TCP connection teardown, as even with
REUSEADDR socket option set, binding will fail if the sockets are not in
TCP TIMED_WAIT state (i. e. connections are active).
Because of this, add a configurable delay when restarting the server.
Additionally, make server initialization failures non-fatal, i. e. try
to restart the server again after the delay if the initialization fails.
It's been observed with Chromium, that it tends to keep connections open
even after closing them on the server side (socket lingers in FIN_WAIT_2
state), so the server re-initialization may fail even with delay, so
it's beneficial in such case to keep retrying the server
re-initialization.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case of fatal errors (during poll() or when handling listening
socket), the server operation is restarted. It was missed however, that
sockets opened for the server should be closed in such case.
Additionally, in case there were active client connections, it's needed
to cleanup related resources, otherwise running timers may trigger a
crash.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In previous batch of fixes it was overlooked that streams are
HTTP2-specific concept. While for HTTP2 we need to track headers reply
state for each individual stream, at HTTP1 level we need to track this
at the client level. Hence, reintroduce respective flags to track
headers reply state, but only for HTTP1.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The information about replied headers or END_OF_STREAM flag are
stream-specific and not general for a client. Hence, need to move them
to the stream context.
For the upgrade case, we need to allocate a new stream now when HTTP1
request /w upgrade field is received. The stream ID in such case is
assumed to be 1 according to RFC.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case client decides to send a trailing headers frame, the last data
frame will not carry END_STREAM flag. In result, with current logic
server would not include END_STREAM flag either, causing the connection
to stall. This commit fixes this logic, so that the server replies
accordingly in case END_STREAM flag is present in the trailing headers
frame.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
CONTINUATION frames are tricky, because individual header fields can be
split between HEADERS frame and CONTINUATION frame, or two CONTINUATION
frames. Therefore, some extra logic is needed when header parsing
returns -EAGAIN, as we may need to remove the CONTINUATION frame header
from the stream before proceeding with headers parsing.
This commit implements the above logic and additionally adds more checks
to detect when CONTINUATION frame is expected. Not receiving a
CONTINUATION frame when expect should be treated as a protocol error.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Frame printouts should not be done from the state handlers, but rather
during state transition, otherwise a single frame can be printed several
times as new data arrive. This also simplifies code a bit, as we just
print the frame in a single place, instead of duplicating code.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
There's really no good reason to have an upper bound on the buffer sizes
and this limits testing in some cases, so just remove them.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case RST_STREAM frame is received it should not be ignored, but the
corresponding stream should be closed.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case priority flag is present in the HTTP2 headers frame header, we
should expect additional priority fields before the actual frame
content.
The stream priority signalling has been deprecated by RFC 9113, however
we should still be able to handle this in case some implementation
(nghttp for instance) sends them.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Data and header frames can contain padding - we need to take this into
account when parsing them, otherwise the stream is broken.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
