ESP8266(ESP-WROOM-02)の内容。ESP-WROOM-32ではないのでがおおよそ同じと思う。

現象

ESP8266のWiFiClientSecureでサーバからデータを取得しようとした。本来レスポンスの本体(ペイロード本文)は”[0]“を期待していたが以下の下３行のようにレスポンスが期待していたものと違う形になっていた。

Connecting to https://hoge.co.jp/api/fuga
Connected to server
Server: nginx
Date: Wed, 21 Feb 2024 05:21:47 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: close

3
[0]
0

理由

これはTransfer-Encoding: chunkedになっていてペイロード本文が

データ1のバイト数\r\nデータ1\r\n0\r\n

というフォーマットになっているため。長いもの送る場合は

データ1のバイト数\r\nデータ1\r\nデータ2のバイト数\r\nデータ2\r\n…データxのバイト数\r\nデータx\r\n…0\r\n

となる。なおデータのバイト数は16 進数表記。

対処

その１

対処としてそういうものとして読み込んでもよいけど、マルチバイトの場合データ1,2の間でぶった切られるのでつなげるのとか面倒。

その２

可能ならサーバ側で送る際にTransfer-Encoding: chunkedじゃなくしたい。

今回はサーバ側はpythonのBaseHTTPRequestHandlerを使っているがレスポンスにContent-Lengthをつけてやれば自動でTransfer-Encoding: chunkedじゃなくなった。「とりあえず、Content-Lengthついてないからchunkedでおくとっくわ」という仕様だったっぽい。（明示的にヘッダー付けた場合に消えるかは未確認）

from http.server import BaseHTTPRequestHandler, HTTPServer
from reserve_count import reserve_count
import urllib.parse

class MyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        parsed_path = urllib.parse.urlparse(self.path)
        query_params = urllib.parse.parse_qs(parsed_path.query)


        if parsed_path.path == '/api/reserve_count':
            response_content = "ほげ".encode('utf-8')
            self.send_response(200)
            self.send_header('Content-type', 'text/html')
            self.send_header('Content-Length', len(response_content))
            self.end_headers()

http1.1の仕様的にはTransfer-Encoding: chunkedの時にはContent-Length不要らしい。