Do not add zero Content-Length by default in GET requests

[Sravan-Apps]

Describe the bug
ZAP Automated scan (Spider and Active Scan) sends Request header Content-Length: 0 in case of GET requests. This can trigger some servers or WAF's and block the ZAP scan.

To Reproduce
Steps to reproduce the behavior:

1. Start zap using java -jar zap-2.10.0.jar
2. Use netcat to listen on tcp port 7777 nc -4lkp 7777 from a terminal
3. Now in ZAP Click on Automated scan icon. In Url to Attack enter http://127.0.0.1:7777 and click Attack button.
4. Go to terminal window where netcat is listening and see the request sent from ZAP.

Expected behavior
Content-Length: 0 Header will not be added for GET requests.

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Pragma: no-cache
Cache-Control: no-cache
Host: 127.0.0.1:7777

Per RFC we should not add Content-Length header for GET,HEAD,TRACE methods. https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2

A user agent SHOULD NOT send a Content-Length header field when the request message does not contain
a payload body and the method semantics do not anticipate such a body.

Content-Length is valid only for POST,PUT, PATCH, DELETE methods.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

Screenshots

$ nc -4lkp 7777
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 0
Host: 127.0.0.1:7777

Software versions

• ZAP: 2.10.0
• Add-on: quickstart and spider
• OS: Debian 10
• Java: openjdk 11.0.11
• Browser: NA

Errors from the zap.log file
NA

Additional context
After looking at code I found that this is happening due to code here.

From git history I found that the code is there since v1.2.0 and this was probably carried over from Paros.

This change will be similar to #4593

Would you like to help fix this issue?
Yes.. I made a patch, will submit a PR.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.