fix: add Content-Type validation before JSON parsing in API client #370
Conversation
Prevents "Unexpected token '<'" errors when servers return HTML instead of JSON (e.g., login pages, maintenance pages). The API client now: - Checks Content-Type header before parsing JSON responses - Provides clear error messages when receiving unexpected content types - Detects HTML responses even without proper Content-Type headers - Handles edge cases gracefully (missing headers, test environments) This fixes MCP-SERVER-E9P and MCP-SERVER-E9S errors where HTML error pages were being parsed as JSON, causing cryptic parse errors. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## main #370 +/- ##
==========================================
+ Coverage 62.40% 62.46% +0.05%
==========================================
Files 77 77
Lines 6828 6844 +16
Branches 601 613 +12
==========================================
+ Hits 4261 4275 +14
- Misses 2567 2569 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
The listOrganizations method was missing Content-Type validation for the regions endpoint response, leaving it vulnerable to the same "Unexpected token '<'" errors that the rest of the fix addresses. This ensures all JSON parsing in the API client goes through the same validation logic. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
Centralizes JSON response handling by introducing a requestJSON method that combines request() and parseJsonResponse(). This simplifies all API methods and ensures consistent Content-Type validation across the entire API client. All methods that expect JSON responses now use requestJSON directly instead of the two-step process, making the code more maintainable and less prone to missing validation. The request() method is still available for non-JSON responses like binary downloads (e.g., getEventAttachment). 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
There was a problem hiding this comment.
Bug: JSON Parsing Fails on Non-JSON Content
The parseJsonResponse method's if (!response.headers?.get) condition incorrectly bypasses Content-Type validation when response.headers.get is falsy or not a function. This allows non-JSON responses (e.g., HTML) to be passed to response.json(), leading to parsing errors, inconsistent behavior, and potential security risks. The condition should instead verify that response.headers.get is a function.
packages/mcp-server/src/api-client/client.ts#L317-L321
sentry-mcp/packages/mcp-server/src/api-client/client.ts
Lines 317 to 321 in c852c22
Was this report helpful? Give feedback by reacting with 👍 or 👎
Prevents "Unexpected token '<'" errors when servers return HTML instead of JSON (e.g., login pages, maintenance pages). The API client now:
This fixes MCP-SERVER-E9P and MCP-SERVER-E9S errors where HTML error pages were being parsed as JSON, causing cryptic parse errors.
🤖 Generated with Claude Code