Http Content Range

[td-pradecki]

Content-Range parsing has been added to the http subsystem.
PR consist of changes in:

• http_parser: Added parsing Content-Range header. Parsing is done by writing
  the output to the output structure called "http_content_range".
  Structure contains fields: start, end, total. Unit automatically translates to bytes.

• http_client: If header field matches Content-Range scheme, fields are returned via
  http_content_range struct. cr_present flag indicates that Content-Range is present.

Changes are much needed because currently Zephyr doesn't support Content-Range header, which
is extensively used approach in http-based download apps.

[github-actions]

Hello @td-pradecki, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[jukkar]

I think we could change this to
const char content_range[]="Content-Range";
This way we avoid allocating a pointer and can use sizeof instead of strlen
Same change could be done for content-lenght.
Perhaps it could be even static.

[mrodgers-witekio]

FYI as an alternative approach it should be possible to handle the Content-Range (or any other header) at an application level by passing your own callbacks in the http_cb parameter of the struct http_request.

The approach in this PR also works, but hard-coding the response headers to be processed in the HTTP parser state machine might not be the most scalable approach if we want to handle more headers in future.

E.g. a quick example of what I mean by modifying the HTTP client sample app:

diff --git a/samples/net/sockets/http_client/src/main.c b/samples/net/sockets/http_client/src/main.c
index 5c89fb42b27..f3eee3aa74a 100644
--- a/samples/net/sockets/http_client/src/main.c
+++ b/samples/net/sockets/http_client/src/main.c
@@ -149,6 +149,23 @@ static int connect_socket(sa_family_t family, const char *server, int port,
        return ret;
 }
 
+int cb_header_field(struct http_parser *parser, const char *at, size_t length)
+{
+       LOG_INF("Header field: '%.*s'", length, at);
+       return 0;
+}
+
+int cb_header_value(struct http_parser *parser, const char *at, size_t length)
+{
+       LOG_INF("Header value: '%.*s'", length, at);
+       return 0;
+}
+
+static const struct http_parser_settings http_parser_cbs = {
+       .on_header_field = cb_header_field,
+       .on_header_value = cb_header_value,
+};
+
 static int run_queries(void)
 {
        struct sockaddr_in6 addr6;
@@ -201,6 +218,7 @@ static int run_queries(void)
                req.response = response_cb;
                req.recv_buf = recv_buf_ipv4;
                req.recv_buf_len = sizeof(recv_buf_ipv4);
+               req.http_cb = &http_parser_cbs;
 
                ret = http_client_req(sock4, &req, timeout, "IPv4 GET");

[rlubos]

Looks good just some nits.

[rlubos]

This line break seems unnecessary?

[rlubos]

Weird that checkpatch doesn't complain about this:

Suggested change

	uint16_t content_len_len = sizeof(content_len)-1;
	uint16_t content_range_len = sizeof(content_range)-1;
	uint16_t content_len_len = sizeof(content_len) - 1;
	uint16_t content_range_len = sizeof(content_range) - 1;

[jukkar]

I think this could be a bool to make it clear the meaning of the field.

Gave +1 too early

[rlubos]

Looks good provided the remaining comment is addressed.

[github-actions]

Hi @td-pradecki!
Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!

To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.

Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁