Full Firmware Package for the STM32U5 series: HAL+LL drivers, CMSIS, BSP, MW, plus a set of Projects (examples and demos) running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits).
Other
121
stars
67
forks
source link
IOT_HTTP_WebServer application does not send HTTP headers as intended #10
The IOT_HTTP_WebServer application does not send HTTP headers as intended.
How to reproduce the bug
Run the IOT_HTTP_WebServer application on the B-U585I-IOT02A board.
Open the "STM32U5 Webserver Demo" website in Chrome.
Open the Chrome developer tools and examine the HTTP headers, for example for "chunk.css".
There is no "Response Headers" section present while according to the source code "text/css" should be present as "Content-Type" header, and there should be additional HTTP headers:
Compare that to the response for "chunk.js" which has "Response Headers" including "Content-Type: text/javascript":
That "chunk.js" has the HTTP headers is purely by coincidence as explained below.
Additional context
The problem is caused by the fact that two parameters are passed in the wrong order whenhttp_send_response() calls http_send_headers_response():
Note the call http_send_headers_response(headers_id, socket, headers_buff, data_size), while the signature of http_send_headers_response is http_send_headers_response(uint32_t socket, uint32_t headers_id, ...). The parameters headers_id and socket are passed in the wrong order.
This also explains why the headers for the JavaScript file is sent. It works by accident because the socket id is 1 and because HTTP_HEADER_JS_ID is defined as 1.
Thank you for your contribution. This issue has been fixed in the frame of version v1.2.0 of the STM32CubeU5. Please allow me then to close this thread.
Describe the set-up
Describe the bug
The IOT_HTTP_WebServer application does not send HTTP headers as intended.
How to reproduce the bug
Compare that to the response for "chunk.js" which has "Response Headers" including "Content-Type: text/javascript":
That "chunk.js" has the HTTP headers is purely by coincidence as explained below.
Additional context
The problem is caused by the fact that two parameters are passed in the wrong order when
http_send_response()
callshttp_send_headers_response()
:https://github.com/STMicroelectronics/STM32CubeU5/blob/133d940e5bd3a38955b9ba0cdf316f9681d0af2d/Projects/B-U585I-IOT02A/Demonstrations/IOT_HTTP_WebServer/WebServer/App/http/webserver_http_response.c#L243-L276
Note the call
http_send_headers_response(headers_id, socket, headers_buff, data_size)
, while the signature ofhttp_send_headers_response
ishttp_send_headers_response(uint32_t socket, uint32_t headers_id, ...)
. The parametersheaders_id
andsocket
are passed in the wrong order.This also explains why the headers for the JavaScript file is sent. It works by accident because the socket id is 1 and because
HTTP_HEADER_JS_ID
is defined as 1.The following patch fixes the problem:
With that patch applied the HTTP headers are sent as expected for all elements.