fix: correct HTTP statusText and Gemini GET/HEAD handling

[NieiR]

Summary

• Fix statusText bug: was HTTP/1.1 200 200, now HTTP/1.1 200 OK (use STATUS_CODES from node:http instead of String(statusCode))
• Fix Gemini request body handling: skip JSON.stringify for GET/HEAD requests which should not have a body

Problem

This PR fixes two separate bugs in the proxy forwarder:

1. Incorrect HTTP statusText: Responses were being constructed with numeric status codes repeated in the status line (e.g., HTTP/1.1 200 200 instead of HTTP/1.1 200 OK), which violates HTTP/1.1 specification and could cause issues with strict HTTP clients.

2. Gemini GET/HEAD request serialization: Gemini API providers were incorrectly attempting to serialize request bodies for GET/HEAD requests, which should not have request bodies according to HTTP specification. This caused errors or malformed requests.

Solution

StatusText Fix

Changed from String(undiciRes.statusCode) to STATUS_CODES[undiciRes.statusCode] ?? "OK" using Node.js's built-in STATUS_CODES map from node:http.

Gemini Request Body Fix

Added check for HTTP method before serializing request body:

const hasBody = session.method !== "GET" && session.method !== "HEAD";
if (hasBody) {
  const bodyString = JSON.stringify(session.request.message);
  requestBody = bodyString;
}

Changes

Core Changes

• src/app/v1/_lib/proxy/forwarder.ts:827-831 - Added method check before JSON.stringify for Gemini requests
• src/app/v1/_lib/proxy/forwarder.ts:1963 - Use STATUS_CODES from node:http for proper status text

Documentation Changes

• CHANGELOG.md - Entry added for v0.3.38

Test plan

• Verify HTTP response status line format is correct (e.g., HTTP/1.1 200 OK)
• Test Gemini GET/HEAD requests work without body serialization errors

---

Description enhanced by Claude AI

Greptile Summary

Fixed two bugs in HTTP response handling: corrected status line format from HTTP/1.1 200 200 to HTTP/1.1 200 OK using Node.js's STATUS_CODES map, and prevented Gemini GET/HEAD requests from incorrectly serializing request bodies.

Key Changes:

• Import STATUS_CODES from node:http and use it for proper HTTP status text mapping (forwarder.ts:1967)
• Added method check before JSON serialization for Gemini requests to skip body for GET/HEAD methods (forwarder.ts:830-834)
• Pattern aligns with existing body handling for other providers at line 1103
• CHANGELOG updated with comprehensive v0.3.38 release notes

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• Both fixes are straightforward bug corrections using established patterns: STATUS_CODES is a standard Node.js API, and the GET/HEAD body check matches the existing pattern at line 1103. The changes fix real HTTP specification violations without introducing new logic or side effects.
• No files require special attention

Important Files Changed

Filename	Overview
src/app/v1/_lib/proxy/forwarder.ts	Fixed statusText bug and added GET/HEAD body handling check for Gemini requests - changes are correct and consistent with existing patterns
CHANGELOG.md	Added comprehensive release notes for v0.3.38 - properly documented all features, fixes, and optimizations

Sequence Diagram

sequenceDiagram
    participant Client
    participant ProxyForwarder
    participant Provider as Provider API
    
    Client->>ProxyForwarder: HTTP Request (GET/POST/etc)
    
    alt Gemini Provider
        ProxyForwarder->>ProxyForwarder: Check method type
        alt GET or HEAD request
            ProxyForwarder->>ProxyForwarder: Skip body serialization
        else POST or other methods
            ProxyForwarder->>ProxyForwarder: JSON.stringify(request body)
        end
    else Other Providers
        ProxyForwarder->>ProxyForwarder: Standard body handling
    end
    
    ProxyForwarder->>Provider: Forward request with proper body
    Provider->>ProxyForwarder: Response (statusCode)
    
    ProxyForwarder->>ProxyForwarder: Map statusCode to STATUS_CODES
    Note over ProxyForwarder: Was: String(200) → "200"<br/>Now: STATUS_CODES[200] → "OK"
    
    ProxyForwarder->>Client: Response with correct statusText

Loading

[gemini-code-assist]

Summary of Changes

Hello @NieiR, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses two critical issues related to API request and response handling. It standardizes the HTTP statusText in responses to align with common HTTP specifications, improving client compatibility. Additionally, it refines the handling of Gemini API requests by preventing the serialization of request bodies for GET and HEAD methods, which are not designed to carry a payload, thereby resolving potential errors and ensuring correct API interaction.

Highlights

• HTTP Status Text Correction: The statusText in HTTP responses has been corrected to use standard phrases (e.g., "OK" for 200) by leveraging node:http.STATUS_CODES, resolving an issue where it previously duplicated the status code (e.g., "200 200").
• Gemini GET/HEAD Request Body Handling: Request body serialization (JSON.stringify) is now conditionally applied for Gemini API calls, ensuring that GET and HEAD requests, which should not contain a body, are handled correctly without serialization errors.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces two important fixes. First, it corrects the HTTP response statusText by using standard status codes from node:http, which is a great improvement over using the status code number. Second, it properly handles Gemini GET/HEAD requests by ensuring no body is sent, which resolves potential errors. The changes are well-implemented, though I have a small suggestion to make the statusText fallback more robust for non-standard error codes. Additionally, please note that the update to CHANGELOG.md appears to contain entries for a different set of changes and does not reflect the fixes in this PR, which might cause confusion.

[gemini-code-assist]

The content added to the changelog for v0.3.38 seems to be unrelated to the changes in this pull request, which focuses on fixing statusText and Gemini GET/HEAD request handling. The changelog entries describe new features and optimizations that are not part of this PR. This could lead to confusion about what is included in the release. Please verify if this changelog update is intended for this PR.

[gemini-code-assist]

Using "OK" as a fallback for statusText can be misleading for non-standard error status codes. For example, if undiciRes.statusCode is a custom error code like 599, STATUS_CODES[599] will be undefined, and the response status line would become HTTP/1.1 599 OK, which is incorrect. A safer approach is to use an empty string "" as the fallback. This allows the Response constructor to use its default status text for known codes or leave it empty for unknown ones, which is more accurate.

Suggested change

	statusText: STATUS_CODES[undiciRes.statusCode] ?? "OK",
	statusText: STATUS_CODES[undiciRes.statusCode] ?? "",

[github-actions]

Code Review Summary

This PR fixes two specific bugs in the proxy forwarder: HTTP statusText formatting and Gemini GET/HEAD request handling. Both changes are well-targeted and follow existing patterns in the codebase.

PR Size: S

• Lines changed: 37 additions, 4 deletions
• Files changed: 2 (CHANGELOG.md, src/app/v1/_lib/proxy/forwarder.ts)

Issues Found

Category	Critical	High	Medium	Low
Logic/Bugs	0	0	0	0
Security	0	0	0	0
Error Handling	0	0	0	0
Types	0	0	0	0
Comments/Docs	0	0	0	0
Tests	0	0	0	0
Simplification	0	0	0	0

Analysis Summary

Change 1: HTTP statusText fix (line 1964)

• Replaces String(undiciRes.statusCode) with STATUS_CODES[undiciRes.statusCode] ?? "OK"
• Corrects the status line from HTTP/1.1 200 200 to HTTP/1.1 200 OK
• Uses Node.js http.STATUS_CODES mapping for proper reason phrases
• Provides sensible fallback for undefined status codes
• Confidence: This is a correct fix that addresses the reported bug

Change 2: Gemini GET/HEAD body handling (lines 826-831)

• Adds conditional check: hasBody = session.method !== "GET" && session.method !== "HEAD"
• Only calls JSON.stringify() when the HTTP method allows a request body
• Follows the exact same pattern used elsewhere in the file (line 1099)
• The session.method property is defined as readonly string in ProxySession class and set via c.req.method.toUpperCase()
• Confidence: This is a correct fix that prevents JSON serialization of GET/HEAD requests

Review Coverage

• Logic and correctness - Changes are bug fixes that align with HTTP specs
• Security (OWASP Top 10) - No security issues introduced
• Error handling - No error handling changes
• Type safety - Types are consistent with existing code
• Documentation accuracy - No comment changes needed
• Test coverage - No test file changes (fixes are straightforward)
• Code clarity - Changes improve code correctness

Notes

1. STATUS_CODES import: The import import { STATUS_CODES } from "node:http"; is added at line 1, which is the correct location for module imports.

2. Consistent pattern: The hasBody check at line 828 uses the exact same logic as line 1099, maintaining consistency with existing code patterns in the same file.

3. CHANGELOG.md update: The PR includes a changelog entry (lines 9-37 in CHANGELOG.md) documenting the fixes, which follows project conventions.

4. No tests added: Given the straightforward nature of these bug fixes (using standard library constant and applying HTTP method semantics), the lack of test coverage is acceptable. The changes are well-scoped and follow existing patterns.

---

Automated review by Claude AI

[greptile-apps]

Greptile found no issues!

From now on, if a review finishes and we haven't found any issues, we will not post anything, but you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}

[NieiR]

Closing: will resubmit after further testing