Lines Matching +full:in +full:- +full:application
19 The server operation is generally transparent for the application, running in a
20 background thread. The application can control the server activity with
23 Certain resource types (for example dynamic resource) provide resource-specific
24 application callbacks, allowing the server to interact with the application (for
29 * Static resources - content defined compile-time, cannot be modified at runtime
32 * Dynamic resources - content provided at runtime by respective application
35 * Websocket resources - allowing to establish Websocket connections with the
39 resource types usage. See :zephyr:code-sample:`sockets-http-server` for more
45 A few prerequisites are needed in order to enable HTTP server functionality in
46 the application.
48 First of all, the HTTP server has to be enabled in applications configuration file
51 .. code-block:: cfg
56 All HTTP services and HTTP resources are placed in a dedicated linker section.
57 The linker section for services is predefined locally, however the application
62 Linker sections for resources should be defined in a linker file. For example,
65 .. code-block:: c
66 :caption: ``sections-rom.ld``
72 Finally, the linker file and linker section have to be added to your application
75 .. code-block:: cmake
78 zephyr_linker_sources(SECTIONS sections-rom.ld)
86 registered in the system.
94 The application needs to define an HTTP service (or multiple services), with
98 .. code-block:: c
109 .. code-block:: c
126 HTTPS services rely on TLS credentials being registered in the system.
128 configure TLS credentials in the system.
133 Application can enable resource wildcard support by enabling
138 POSIX API function is used to match the pattern in the URL paths.
142 .. code-block:: c
154 Static resource content is defined build-time and is immutable. The following
156 in the application:
158 .. code-block:: c
177 The resource content and content encoding is application specific. For the above
179 following code to the application's ``CMakeLists.txt`` file:
181 .. code-block:: cmake
186 generate_inc_file_for_target(app ${source_file_index} ${gen_dir}/index.html.gz.inc --gzip)
193 Static filesystem resource content is defined build-time and is immutable. The following
194 example shows how the path can be defined as a static resource in the application:
196 .. code-block:: c
208 All files located in /lfs1/www are made available to the client. If a file is
211 content-encoding to the HTTP header.
218 .. code-block:: c
220 HTTP_SERVER_CONTENT_TYPE(json, "application/json")
226 the server and the application.
231 .. code-block:: c
239 enum http_method method = client->method;
250 processed += request_ctx->data_len;
253 http_method_str(method), request_ctx->data_len);
254 LOG_HEXDUMP_DBG(request_ctx->data, request_ctx->data_len, print_str);
262 response_ctx->body = request_ctx->data;
263 response_ctx->body_len = request_ctx->data_len;
264 response_ctx->final_chunk = (status == HTTP_SERVER_DATA_FINAL);
284 the application should be able to keep track of the received data progress.
286 The ``status`` field informs the application about the progress in passing
287 request payload from the server to the application. As long as the status
288 reports :c:enumerator:`HTTP_SERVER_DATA_MORE`, the application should expect
289 more data to be provided in a consecutive callback calls.
290 Once all request payload has been passed to the application, the server reports
291 :c:enumerator:`HTTP_SERVER_DATA_FINAL` status. In case of communication errors
295 the application shall reset any progress recorded for the resource, and await
299 The ``request_ctx`` parameter is used to pass request data to the application:
301 * The ``data`` and ``data_len`` fields pass request data to the application.
304 headers to the application, if
307 The ``response_ctx`` field is used by the application to pass response data to
310 * The ``status`` field allows the application to send an HTTP response code. If
313 * The ``headers`` and ``header_count`` fields can be used for the application to
314 send any arbitrary HTTP headers. If not populated, only Transfer-Encoding and
315 Content-Type are sent by default. The callback may override the Content-Type
320 * The ``final_chunk`` field is used to indicate that the application has no more
323 Headers and/or response codes may only be sent in the first populated
324 ``response_ctx``, after which only further body data is allowed in subsequent
328 to the application, and the application reports there is no more data to include
329 in the reply.
334 Websocket resources register an application callback, which is called when a
337 the application takes full control over the socket, i. e. is responsible to
340 .. code-block:: c
367 processing of the Websocket connection is application-specific, hence outside
368 of scope of this guide. See :zephyr:code-sample:`sockets-http-server` for an
369 example Websocket-based echo service implementation.
374 The application can register an interest in any specific HTTP request headers.
376 from within a dynamic resource callback. Request headers are only included in
383 Then the application can register headers to be captured, and read the values
386 .. code-block:: c
388 HTTP_SERVER_REGISTER_HEADER_CAPTURE(capture_user_agent, "User-Agent");
393 size_t header_count = client->header_capture_ctx.count;
394 const struct http_header *headers = client->header_capture_ctx.headers;