-
Notifications
You must be signed in to change notification settings - Fork 7.6k
net: http: service: enhance HTTP service with optional custom socket create #92732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
net: http: service: enhance HTTP service with optional custom socket create #92732
Conversation
1c3c8f2
to
6e11e8d
Compare
84fe49b
to
3aadf05
Compare
3aadf05
to
5770cd8
Compare
include/zephyr/net/http/service.h
Outdated
@@ -220,14 +225,14 @@ struct http_service_desc { | |||
* @param _sec_tag_list_size TLS security tag list size used to setup a HTTPS socket. | |||
*/ | |||
#define HTTPS_SERVICE_DEFINE(_name, _host, _port, _concurrent, _backlog, _detail, \ | |||
_res_fallback, _sec_tag_list, _sec_tag_list_size) \ | |||
_res_fallback, _sec_tag_list, _sec_tag_list_size, ...) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH I think I'd prefer to keep all of the macro parameters explicit instead of hiding optional parameters behind __VA_ARGS__
- it might get super confusing if someone wanted to add yet another parameter in the future, it'd be tricky to document also.
We could just extend the macros/service struct with an additional struct http_service_config
where we could keep any optional per-service configurations, including this custom socket struct, so in case any other custom configurations will be needed in the future, we could just extend the struct w/o touching the macros again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rlubos
Good point!
If we want to both prevent future modifications and stay backwards compatible,
I can also alternatively create new macroses which accept struct http_service_config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, the API is still experimental so I'm not sure if we need to care that much about backward comptibility, I'd just update the existing macros.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rlubos
I modified the API as you suggested.
Could you please have a brief look?
If that change is okay for you, I'll go ahead with the formalities - fixing samples, docs, twister tests etc. (never done twister tests in Zephyr itself yet)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jukkar @mrodgers-witekio
Could you please have a look too? I don't want to move ahead with fixing the tests and samples if the change is not okay for you
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The approach looks good to me.
May be worth adding a note in the migration guide to mention the change to the public API, although I've just noticed that there isn't a draft migration guide for v4.2 --> v4.3 yet (assuming this change won't make it into the v4.2 release), anyone know who would usually create this?
6cf7a0b
to
2f72b82
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, IMHO we can proceed with this approach.
@@ -156,7 +156,11 @@ int http_server_init(struct http_server_ctx *ctx) | |||
proto = IPPROTO_TCP; | |||
} | |||
|
|||
fd = zsock_socket(af, SOCK_STREAM, proto); | |||
if (svc->config != NULL && svc->config->socket_creat != NULL) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: socket_creat
a0dbf21
to
ba165ca
Compare
122e2df
to
405ce47
Compare
405ce47
to
0f8b7b7
Compare
Updated tests and docs. Also updated release notes, not sure if it is needed for 4.2 |
Please update 4.3 release notes instead given this won't make it into 4.2 which is currently in feature freeze and a week away from being released. Thanks! |
Update the HTTP service API to allow setting per-service configuration, currently it is only custom socket creation callback, but in the future it can be extended with other parameter Signed-off-by: Andrey Dodonov <Andrey.Dodonov@endress.com>
e164b8b
to
0dc2add
Compare
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks!
Currently webserver does not support custom socket creation e.g. for offloaded socket.
Update the HTTP service API to allow custom socket creation through a function pointer in the service descriptor.
The existing socket creation method is retained as a fallback if no custom function is provided.
This functionality is per-service, i.e. it allows to specify which http services will work on which sockets.
Backwards-compatible.
Partially related to #89960