Fixed Responses to OPTIONS Requests ignore Body

[Kapsonfire-DE]

Fixes #15082

Rules for containing body didnt align to Docs

[Kapsonfire-DE]

Im not sure if these simple changes needs new tests.
things to consider in testings: do we have a server we can fetch with OPTIONS method and always returning a body? Issue Creator showed example with google, but whats about google changes to not providing a body?

[cirospaciari]

We should follow the spec and add tests for it if anything is changed

https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1

   A payload within a GET request message has no defined semantics;
   sending a payload body on a GET request might cause some existing
   implementations to reject the request.

for CONNECT we need more work:

  CONNECT is intended only for use in requests to a proxy.  An origin
server that receives a CONNECT request for itself MAY respond with a
2xx (Successful) status code to indicate that a connection is
established.  However, most origin servers do not implement CONNECT.

 A server MUST NOT send any Transfer-Encoding or Content-Length header
fields in a 2xx (Successful) response to CONNECT.  A client MUST
ignore any Content-Length or Transfer-Encoding header fields received
in a successful response to CONNECT.

A payload within a CONNECT request message has no defined semantics;
sending a payload body on a CONNECT request might cause some existing
implementations to reject the request.

for OPTIONS we also need more checks:

  A client that generates an OPTIONS request containing a payload body
MUST send a valid Content-Type header field describing the
representation media type.  Although this specification does not
define any use for such a payload, future extensions to HTTP might
use the OPTIONS body to make more detailed queries about the target
resource.

[Kapsonfire-DE]

shall I remove the .CONNECT Change for simpleness of this PR to fix the existing bug and address the OPTIONS request body later?

[cirospaciari]

shall I remove the .CONNECT Change for simpleness of this PR to fix the existing bug and address the OPTIONS request body later?

You can reduce the context to only change the OPTIONS behavior but we will still need tests for Bun.serve, fetch and node:http and node:https

EDIT: I meant OPTIONS sorry

[Kapsonfire-DE]

The current bug is, that Responses to OPTIONS have no body in bun, even though the server sends it. So I would reduce the changes, to allow OPTIONS Responses to have body and add a test for this.

So we can close this bug.

I'd address the OPTIONS Requests with Body in a later PR.
For CONNECT is more work to be done, so I'd remove it completely out of scope for this for now

[cirospaciari]

The current bug is, that Responses to OPTIONS have no body in bun, even though the server sends it. So I would reduce the changes, to allow OPTIONS Responses to have body and add a test for this.

So we can close this bug.

I'd address the OPTIONS Requests with Body in a later PR. For CONNECT is more work to be done, so I'd remove it completely out of scope for this for now

Sure I meant OPTIONS sorry, you can reduce the context for only 1 change at a time sure, we still will need the tests.