Skip to content

Make Request Body Size Configurable #116

Description

@AnkanMisra

Summary

The gateway still hardcodes its request body size limit, and the limit is enforced in more than one place. That makes deployment-specific tuning impossible and risks inconsistent behavior if only one call site is updated.

Current State

The gateway currently enforces a hardcoded 10 * 1024 * 1024 request-body limit in two places:

  • gateway/main.go on the summarize request path via http.MaxBytesReader
  • gateway/cache.go in the cache middleware via a second hardcoded size check

The issue is no longer just "replace one constant". Both call sites need to read from one shared helper or the gateway will disagree with itself depending on which path rejects the request first.

What to build

Introduce a single shared gateway helper for request-body size configuration and update both call sites to use it.

Use a bytes-based environment variable name that stays consistent with the project's existing verifier naming, and preserve the current 10 MiB default when unset or invalid.

Acceptance Criteria

  • A shared helper returns the gateway request-body limit in bytes.
  • Both gateway/main.go and gateway/cache.go use that shared helper instead of hardcoded constants.
  • The default remains 10485760 bytes (10 MiB) when the variable is unset or invalid.
  • The chosen environment variable is documented in the canonical config docs.
  • Tests cover the helper default/invalid-input behavior and verify that oversized requests are rejected consistently.

Non-goals

  • Do not change unrelated verifier body-size behavior in this issue.
  • Do not change the default size limit.
  • Do not introduce different limits for cache vs summarize paths.

Verification

  • Run cd gateway && go test ./...
  • Start the gateway with a reduced body-size limit and confirm oversized requests are rejected consistently.
  • Confirm both gateway call paths use the same configured limit.

Blocked by

None - can start immediately.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestgoPull requests that update go codelevel:beginnerSmall, well-scoped work suitable for newer contributors.type:featureNew user-facing or API-facing capability.type:securitySecurity, abuse resistance, secret safety, or payment integrity work.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions