We've been using your example with great success for a while but have recently run into an issue with file downloads. After digging in to the issue, it turns out the https_client used in this example is not compliant with HTTP 1.1.
Per the HTTP 1.1 spec:
All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand.
When a response is chunked, no Content-Length header is sent (see here for more details); however, the HTTPS client will fail if the Content-Length header is not set in the response:
|
// We're mainly interested in the content length. |
|
// The server should either send the Content-Length header or should close the connection at the end. |
|
int contentLength = 0; |
|
if (!http_parse_key_value_int(httpRequest->response_buffer, "Content-Length:", &contentLength)) { |
|
ESP_LOGD(TAG, "Content-Length: %d", contentLength); |
|
httpContext->content_length = contentLength; |
|
} else { |
|
ESP_LOGW(TAG, "Content length header missing, dropping the packet. '%s'", httpRequest->response_buffer); |
|
// TODO error callback?? |
|
return 0; |
|
} |
We've been using your example with great success for a while but have recently run into an issue with file downloads. After digging in to the issue, it turns out the https_client used in this example is not compliant with HTTP 1.1.
Per the HTTP 1.1 spec:
When a response is chunked, no
Content-Lengthheader is sent (see here for more details); however, the HTTPS client will fail if theContent-Lengthheader is not set in the response:esp32-ota-https/main/https_client.c
Lines 215 to 225 in 88c001b