fix(http): fix invalid content-length header in http get (IDFGH-13571)

[TeXniKK]

According to RFC9110 Section 8.6 "Content-Length": A user agent SHOULD NOT send a Content-Length header field when the request message does not contain content and the method semantics do not anticipate such data.

This fix removes invalid(empty) Content-Length header for HTTP GET requests.

Presence of this header is causing error 400 to be returned by AWS services via secure connection in some cases:

D (90345) HTTP_CLIENT: Write header[3]: GET /feed HTTP/1.1
User-Agent: IotDevice
Host: <servername>
Content-Length: 0
D (90651) HTTP_CLIENT: on_message_begin
D (90652) HTTP_CLIENT: HEADER=Server:awselb/2.0
D (90652) HTTP_CLIENT: HEADER=Date:Mon, 19 Aug 2024 18:55:53 GMT
D (90653) HTTP_CLIENT: HEADER=Content-Type:text/html
D (90655) HTTP_CLIENT: HEADER=Content-Length:122
D (90656) HTTP_CLIENT: HEADER=Connection:close
D (90656) HTTP_CLIENT: http_on_headers_complete, status=400, offset=150, nread=150
D (90656) HTTP_CLIENT: http_on_body 122
D (90657) HTTP_CLIENT: http_on_message_complete, parser=3f81f998
D (90657) HTTP_CLIENT: content_length = 122
D (90657) HTTP_CLIENT: Close connection
I (90661) OTA: HTTP GET Status = 400, content_length = 122```

[CLAassistant]

All committers have signed the CLA.

[github-actions[bot]]

	Messages
:book:	🎉 Good Job! All checks are passing!

👋 Hello TeXniKK, we appreciate your contribution to this project!

---

📘 Please review the project's Contributions Guide for key guidelines on code, documentation, testing, and more.

---

🖊️ Please also make sure you have read and signed the Contributor License Agreement for this project.

---

Click to see more instructions ...

This automated output is generated by the PR linter DangerJS, which checks if your Pull Request meets the project's requirements and helps you fix potential issues.

DangerJS is triggered with each push event to a Pull Request and modify the contents of this comment.

Please consider the following:
- Danger mainly focuses on the PR structure and formatting and can't understand the meaning behind your code or changes.
- Danger is not a substitute for human code reviews; it's still important to request a code review from your colleagues.
- To manually retry these Danger checks, please navigate to the Actions tab and re-run last Danger workflow.

Review and merge process you can expect ...

We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

This GitHub project is public mirror of our internal git repository

1. An internal issue has been created for the PR, we assign it to the relevant engineer.
2. They review the PR and either approve it or ask you for changes or clarifications.
3. Once the GitHub PR is approved, we synchronize it into our internal git repository.
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing.
- At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the default branch.
5. On next sync from the internal git repository merged change will appear in this public GitHub repository.

Generated by :no_entry_sign: dangerJS against c87cb854f3205cb3f1c69f31ac654a4f278d5628

[snake-4]

§ 9.3.1 states that content within GET request is allowed if the origin server indicates that it supports such requests. Maybe there should be an option to keep the header?

You could also add HEAD and DELETE requests to the check as they have the same wording within the RFC (§ 9.3.2 and § 9.3.5).

[TeXniKK]

Agreed. Updated PR with checks for HEAD and DELETE. Also added a check on write_len != 0 to support unlike case where these requests would actually have a body.

[nileshkale123]

sha=c87cb854f3205cb3f1c69f31ac654a4f278d5628