For Contributors

Fixing a Bug

• Related Issues:

  • No existing issue; encountered this bug during development.

• Tests Added:

  • Currently pending. Will follow the guidelines as per Next.js Testing Documentation.
  • Planned Coverage: Intending to add tests that cover scenarios where Request and RequestInit objects are passed as inputs to ensure proper handling without altering HTTP methods or other options.

• Error Handling:

  • Not applicable for this change.

What?

This update improves the handling of inputs in our custom Request class, ensuring that when a Request or RequestInit object is passed, all existing options are preserved.

Why?

The current implementation fails to maintain options from the original Request or RequestInit object, leading to unexpected behavior. Specifically, it results in scenarios where POST requests unintentionally become GET requests, as seen in my case within middleware.ts. This change prevents such issues, maintaining the integrity of the request configuration.

How?

The fix is implemented by modifying the Request class constructor to properly handle instances where the input is either a Request object or a RequestInit object. Specifically:

1. Type Checking:

   • The code first checks if the input is an instance of Request or if it’s a non-string object containing a url property. This is done using the condition:

     if (input instanceof Request || (typeof input !== 'string' && 'url' in input))

   • This ensures that all relevant data from the input object is retained when creating the new Request object.

2. Preservation of Input Properties:

   • If the input matches the above condition, it calls super(input, init), ensuring that all properties and methods from the input Request or RequestInit object are preserved when initializing the new Request.
   • This avoids the issue where POST requests were being unintentionally transformed into GET requests due to loss of options.

3. Fallback:

   • If the input is a simple string (e.g., just a URL), the code falls back to creating a Request object with the given url and init options:

     else super(url, init)

This ensures that the Request object is constructed correctly in all scenarios, maintaining the integrity of HTTP methods and any additional request options.

Note: This is my first contribution to this project. Feedback and guidance on the approach or any improvements are welcome.

Next Steps:

• Complete the pending tests to ensure robustness.
• Possibly open a new issue documenting this bug for historical reference and to assist other developers who might encounter similar issues.
• Await feedback or approval from maintainers.

Request for Feedback:
Could a maintainer review this approach? I'm especially interested in whether there's a more optimal way to handle preserving options when constructing a new Request object.