Description

Oversized multipart uploads were reported as bypassing custom ErrorHandler responses and surfacing as a generic client-side network error instead of a 413 response. This PR adds regression coverage for that path so multipart requests exceeding BodyLimit are verified to return the same custom error response shape as other oversized requests.

• What changed

  • Added an integration test for oversized multipart/form-data requests handled through a custom ErrorHandler
  • Asserted the response status remains 413 Request Entity Too Large
  • Asserted the custom handler response body and content type are preserved for multipart uploads

• Regression coverage

  • Exercises the server-level oversized body path with a real multipart payload
  • Verifies the error is translated into *fiber.Error and serialized by the app’s custom error handler, rather than failing as a transport-level "error" on the client

• Example

  app := fiber.New(fiber.Config{
      BodyLimit: 128,
      ErrorHandler: func(c fiber.Ctx, err error) error {
          code := fiber.StatusInternalServerError
          var fiberErr *fiber.Error
          if errors.As(err, &fiberErr) {
              code = fiberErr.Code
          }
  
          return c.Status(code).JSON(fiber.Map{
              "code":    code,
              "message": err.Error(),
          })
      },
  })

Changes introduced

List the new features or adjustments introduced in this pull request. Provide details on benchmarks, documentation updates, changelog entries, and if applicable, the migration guide.

• Benchmarks: Describe any performance benchmarks and improvements related to the changes.
• Documentation Update: Detail the updates made to the documentation and links to the changed files.
• Changelog/What's New: Include a summary of the additions for the upcoming release notes.
• Migration Guide: If necessary, provide a guide or steps for users to migrate their existing code to accommodate these changes.
• API Alignment with Express: Explain how the changes align with the Express API.
• API Longevity: Discuss the steps taken to ensure that the new or updated APIs are consistent and not prone to breaking changes.
• Examples: Provide examples demonstrating the new features or changes in action.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• Enhancement (improvement to existing features and functionality)
• Documentation update (changes to documentation)
• Performance improvement (non-breaking change which improves efficiency)
• Code consistency (non-breaking change which improves code reliability and robustness)

Checklist

Before you submit your pull request, please make sure you meet these requirements:

• Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
• Conducted a self-review of the code and provided comments for complex or critical parts.
• Updated the documentation in the /docs/ directory for Fiber's documentation.
• Added or updated unit tests to validate the effectiveness of the changes or new features.
• Ensured that new and existing unit tests pass locally with the changes.
• Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
• Aimed for optimal performance with minimal allocations in the new code.
• Provided benchmarks for the new code to analyze and improve upon.

Commit formatting

Please use emojis in commit messages for an easy way to identify the purpose or intention of a commit. Check out the emoji cheatsheet here: CONTRIBUTING.md