Skip to content

Case-insensitive header parsing needed #184

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

Open
tjoyal opened this issue Apr 17, 2025 · 0 comments
Open

Case-insensitive header parsing needed #184

tjoyal opened this issue Apr 17, 2025 · 0 comments
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project

Comments

@tjoyal
Copy link

tjoyal commented Apr 17, 2025

Being new to the Arduino ecosystem and not yet confident in my C++ skills, I'm unable to propose a pull request at this time. However, I wanted to share my investigation in case it proves helpful to others facing a similar problem.

The behavior I observed with client.responseBody() seemed to vary depending on the server I was communicating with. For a server sending { "test": 1234 }, the function returned:

10
{ "test": 1234 }
0

(indicating the hexadecimal size of the payload, the payload itself, and a null terminator).

Furthermore, the client.isResponseChunked() method, intended to indicate a transfer-encoding chunked response, sometimes returned 0 and other times 1.

Through investigation, I discovered that the relevant header in the response was transfer-encoding: chunked. The current code appears to be looking for the case-sensitive Transfer-Encoding: chunked.

#define HTTP_HEADER_TRANSFER_ENCODING "Transfer-Encoding"

For reference, RFC 2616 section 4.2, HTTP header field names are defined to be case-insensitive.
https://datatracker.ietf.org/doc/html/rfc2616#section-4.2

In my local testing, modifying #define HTTP_HEADER_TRANSFER_ENCODING "transfer-encoding" resolved the issue when interacting with my particular server. Enhancing the header parsing logic for case-insensitive comparisons of header field names would, I believe, eliminate a category of difficult-to-explain errors. I am uncertain whether HTTP_HEADER_CONTENT_LENGTH is subject to a similar issue.

@per1234 per1234 added type: imperfection Perceived defect in any part of project topic: code Related to content of the project itself labels Apr 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project
Projects
None yet
Development

No branches or pull requests

2 participants