fix(core): fix sec-websocket-protocol in deno #1339

NathanFlurry · 2025-10-03T19:04:23Z

No description provided.

vercel · 2025-10-03T19:04:28Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
rivetkit-serverless	Error			Oct 5, 2025 0:45am

claude · 2025-10-03T19:04:37Z

Claude finished @NathanFlurry's task —— View job

Code Review for PR #1339

Reviewing the fix for sec-websocket-protocol in Deno.

Todo List:

Read and analyze the changed file (packages/rivetkit/src/manager/router.ts)
Understand the context and purpose of the changes
Review code quality and best practices
Check for potential bugs or issues
Assess performance considerations
Evaluate security concerns
Consider test coverage needs
Provide comprehensive feedback

Review Summary

This PR adds a middleware to automatically set the Sec-WebSocket-Protocol header to "rivet" for WebSocket upgrade requests in Deno environments. The fix addresses KIT-339 where some Deno WebSocket providers don't auto-set this protocol header, causing client failures.

Code Quality ✅

Strengths:

Clean, focused implementation that addresses a specific compatibility issue
Proper middleware pattern using Hono's createMiddleware
Clear comments explaining the purpose and context (KIT-339 reference)
Minimal performance impact with early returns

Minor suggestions:

The comment mentions this is a "HACK" - consider if this could be refined or if the comment should be more specific about when this workaround can be removed

Implementation Analysis ✅

The middleware correctly:

Checks for GET requests with upgrade: websocket header
Sets Sec-WebSocket-Protocol: rivet for qualifying requests
Places middleware early in the chain (after logging, before routes)

Logic verification:

upgrade?.toLowerCase() === "websocket" - ✅ Case-insensitive check
c.req.method === "GET" - ✅ WebSocket upgrades are GET requests
Early placement in middleware chain - ✅ Ensures header is set before routing

Potential Issues ⚠️

Protocol value hardcoded: The protocol is hardcoded as "rivet". Verify this aligns with:
- Client expectations in gateway.ts:63 where protocols are parsed
- The constants defined in actor-router-consts.ts
Missing validation: The middleware doesn't validate if a protocol was already set by the client, which could potentially override legitimate client protocols.
Deno-specific but applied globally: The fix is applied to all platforms, not just Deno. Consider if this could have unintended effects on other environments.

Security Considerations ✅

Low risk: Setting a WebSocket protocol header is a standard operation
No injection vulnerabilities: Hard-coded value, no user input processed
Doesn't expose sensitive information: Protocol header is part of standard WebSocket negotiation

Performance Considerations ✅

Minimal overhead: Simple header checks and conditional header setting
Early exit: Efficient with early returns when conditions aren't met
No async operations: Synchronous operations before calling next()

Test Coverage Recommendations ⚠️

The PR lacks test coverage. Consider adding tests for:

WebSocket upgrade requests should have the header set:

// Test that Sec-WebSocket-Protocol is set for WebSocket upgrades
const response = await app.request('/', {
  method: 'GET',
  headers: { 'upgrade': 'websocket' }
});
expect(response.headers.get('sec-websocket-protocol')).toBe('rivet');

Non-WebSocket requests should not have the header set:

// Test that header is not set for regular requests
const response = await app.request('/');
expect(response.headers.get('sec-websocket-protocol')).toBeNull();

POST WebSocket requests (edge case) should not trigger the middleware

Questions for Consideration

Backwards compatibility: Does this change maintain compatibility with existing clients that might set their own protocols?
Protocol negotiation: Should this middleware check if sec-websocket-protocol is already present in the request and handle negotiation properly?
Platform detection: Would it be better to only apply this fix when running on Deno?

Recommendation ✅

Approve with suggestions: The fix is sound and addresses a real compatibility issue. The implementation is clean and focused. Consider adding the recommended test coverage and reviewing the questions above for potential improvements in future iterations.

NathanFlurry · 2025-10-03T19:04:38Z

feat: freestyle example #1317
feat(serverless): make runner 0 config #1335
fix(core): fix sec-websocket-protocol in deno #1339 👈 (View in Graphite)
main

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

merge queue - adds this PR to the back of the merge queue
hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

_{An organization admin has enabled the Graphite Merge Queue in this repository.} _{Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.}

This stack of pull requests is managed by Graphite. Learn more about stacking.

pkg-pr-new · 2025-10-03T19:06:42Z

More templates

@rivetkit/actor

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/actor@1339

@rivetkit/cloudflare-workers

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/cloudflare-workers@1339

@rivetkit/core

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/core@1339

@rivetkit/db

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/db@1339

@rivetkit/framework-base

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/framework-base@1339

@rivetkit/next-js

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/next-js@1339

@rivetkit/react

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/react@1339

rivetkit

pnpm add https://pkg.pr.new/rivet-dev/rivetkit@1339

@rivetkit/sql-loader

pnpm add https://pkg.pr.new/rivet-dev/rivetkit/@rivetkit/sql-loader@1339

commit: 9cd6530

claude · 2025-10-05T00:43:57Z

Claude finished @NathanFlurry's task —— View job

Claude is reviewing the PR

Code Review for PR #1339

Reviewing the fix for sec-websocket-protocol in Deno.

Todo List:

Read and analyze the changed file (packages/rivetkit/src/manager/router.ts)
Understand the context and purpose of the changes
Review code quality and best practices
Check for potential bugs or issues
Assess performance considerations
Evaluate security concerns
Consider test coverage needs
Provide comprehensive feedback

Review Summary

This PR adds a middleware to automatically set the Sec-WebSocket-Protocol header to "rivet" for WebSocket upgrade requests in Deno environments. The fix addresses KIT-339 where some Deno WebSocket providers don't auto-set this protocol header, causing client failures.

Code Quality ✅

Strengths:

Clean, focused implementation that addresses a specific compatibility issue
Proper middleware pattern using Hono's createMiddleware
Clear comments explaining the purpose and context (KIT-339 reference)
Minimal performance impact with early returns

Minor suggestions:

The comment mentions this is a "HACK" - consider if this could be refined or if the comment should be more specific about when this workaround can be removed

Implementation Analysis ✅

The middleware correctly:

Checks for GET requests with upgrade: websocket header
Sets Sec-WebSocket-Protocol: rivet for qualifying requests
Places middleware early in the chain (after logging, before routes)

Logic verification:

upgrade?.toLowerCase() === "websocket" - ✅ Case-insensitive check
c.req.method === "GET" - ✅ WebSocket upgrades are GET requests
Early placement in middleware chain - ✅ Ensures header is set before routing

Potential Issues ⚠️

Protocol value hardcoded: The protocol is hardcoded as "rivet". Verify this aligns with:
- Client expectations in gateway.ts:63 where protocols are parsed
- The constants defined in actor-router-consts.ts:29 (WS_PROTOCOL_STANDARD = "rivet")
Missing validation: The middleware doesn't validate if a protocol was already set by the client, which could potentially override legitimate client protocols.
Deno-specific but applied globally: The fix is applied to all platforms, not just Deno. Consider if this could have unintended effects on other environments.

Security Considerations ✅

Low risk: Setting a WebSocket protocol header is a standard operation
No injection vulnerabilities: Hard-coded value, no user input processed
Doesn't expose sensitive information: Protocol header is part of standard WebSocket negotiation

Performance Considerations ✅

Minimal overhead: Simple header checks and conditional header setting
Early exit: Efficient with early returns when conditions aren't met
No async operations: Synchronous operations before calling next()

Test Coverage Recommendations ⚠️

The PR lacks test coverage. Consider adding tests for:

WebSocket upgrade requests should have the header set:

// Test that Sec-WebSocket-Protocol is set for WebSocket upgrades
const response = await app.request('/', {
  method: 'GET',
  headers: { 'upgrade': 'websocket' }
});
expect(response.headers.get('sec-websocket-protocol')).toBe('rivet');

Non-WebSocket requests should not have the header set:

// Test that header is not set for regular requests
const response = await app.request('/');
expect(response.headers.get('sec-websocket-protocol')).toBeNull();

POST WebSocket requests (edge case) should not trigger the middleware

Questions for Consideration

Backwards compatibility: Does this change maintain compatibility with existing clients that might set their own protocols?
Protocol negotiation: Should this middleware check if sec-websocket-protocol is already present in the request and handle negotiation properly?
Platform detection: Would it be better to only apply this fix when running on Deno?

Recommendation ✅

Approve with suggestions: The fix is sound and addresses a real compatibility issue. The implementation is clean and focused. Consider adding the recommended test coverage and reviewing the questions above for potential improvements in future iterations.

graphite-app · 2025-10-05T00:44:51Z

Merge activity

Oct 5, 12:44 AM UTC: NathanFlurry added this pull request to the Graphite merge queue.
Oct 5, 12:45 AM UTC: CI is running for this pull request on a draft pull request (#1344) due to your merge queue CI optimization settings.
Oct 5, 12:46 AM UTC: Merged by the Graphite merge queue via draft PR: #1344.

This was referenced Oct 3, 2025

feat: freestyle example #1317

Open

feat(serverless): make runner 0 config #1335

Closed

vercel bot deployed to Preview October 3, 2025 19:07 View deployment

fix(core): fix sec-websocket-protocol in deno

89f1f51

NathanFlurry force-pushed the 10-03-fix_core_fix_sec-websocket-protocol_in_deno branch from 9cd6530 to 89f1f51 Compare October 5, 2025 00:43

graphite-app bot pushed a commit that referenced this pull request Oct 5, 2025

fix(core): fix sec-websocket-protocol in deno (#1339)

a164196

vercel bot had a problem deploying to Preview October 5, 2025 00:45 Failure

graphite-app bot closed this Oct 5, 2025

graphite-app bot deleted the 10-03-fix_core_fix_sec-websocket-protocol_in_deno branch October 5, 2025 00:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(core): fix sec-websocket-protocol in deno #1339

fix(core): fix sec-websocket-protocol in deno #1339

Uh oh!

NathanFlurry commented Oct 3, 2025

Uh oh!

vercel bot commented Oct 3, 2025 •

edited

Loading

Uh oh!

claude bot commented Oct 3, 2025 •

edited

Loading

Uh oh!

NathanFlurry commented Oct 3, 2025 •

edited

Loading

Uh oh!

pkg-pr-new bot commented Oct 3, 2025

Uh oh!

claude bot commented Oct 5, 2025 •

edited

Loading

Uh oh!

graphite-app bot commented Oct 5, 2025 •

edited

Loading

Uh oh!

Uh oh!

fix(core): fix sec-websocket-protocol in deno #1339

fix(core): fix sec-websocket-protocol in deno #1339

Uh oh!

Conversation

NathanFlurry commented Oct 3, 2025

Uh oh!

vercel bot commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

claude bot commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review for PR #1339

Todo List:

Review Summary

Code Quality ✅

Implementation Analysis ✅

Potential Issues ⚠️

Security Considerations ✅

Performance Considerations ✅

Test Coverage Recommendations ⚠️

Questions for Consideration

Recommendation ✅

Uh oh!

NathanFlurry commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How to use the Graphite Merge Queue

Uh oh!

pkg-pr-new bot commented Oct 3, 2025

Uh oh!

claude bot commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review for PR #1339

Todo List:

Review Summary

Code Quality ✅

Implementation Analysis ✅

Potential Issues ⚠️

Security Considerations ✅

Performance Considerations ✅

Test Coverage Recommendations ⚠️

Questions for Consideration

Recommendation ✅

Uh oh!

graphite-app bot commented Oct 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merge activity

Uh oh!

Uh oh!

vercel bot commented Oct 3, 2025 •

edited

Loading

claude bot commented Oct 3, 2025 •

edited

Loading

NathanFlurry commented Oct 3, 2025 •

edited

Loading

claude bot commented Oct 5, 2025 •

edited

Loading

graphite-app bot commented Oct 5, 2025 •

edited

Loading