Skip to content

Add nginx websocket locations for v2 extensions#3947

Open
rutger-seascape wants to merge 1 commit into
bluerobotics:masterfrom
rutger-seascape:feature/nginx-extension-websockets
Open

Add nginx websocket locations for v2 extensions#3947
rutger-seascape wants to merge 1 commit into
bluerobotics:masterfrom
rutger-seascape:feature/nginx-extension-websockets

Conversation

@rutger-seascape

@rutger-seascape rutger-seascape commented Jun 11, 2026

Copy link
Copy Markdown

There are currently no nginx location blocks generated for v2 extensions that use websockets, this pull request aims to solve that.

Summary by Sourcery

New Features:

  • Introduce nginx location blocks to proxy websocket traffic for v2 extensions.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 1 issue, and left some high level feedback:

  • The new websocket location block duplicates all the proxy header configuration from the existing HTTP route; consider extracting a shared nginx snippet or Python template fragment to avoid divergence if headers need changing later.
  • Double-check that hard-coding /ws on the upstream (proxy_pass http://127.0.0.1:{port}/ws;) matches how v2 extensions expose websocket endpoints; if some extensions mount websockets at different paths, you may want to make this path configurable or derived from metadata instead of fixed.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- The new websocket `location` block duplicates all the proxy header configuration from the existing HTTP route; consider extracting a shared nginx snippet or Python template fragment to avoid divergence if headers need changing later.
- Double-check that hard-coding `/ws` on the upstream (`proxy_pass http://127.0.0.1:{port}/ws;`) matches how v2 extensions expose websocket endpoints; if some extensions mount websockets at different paths, you may want to make this path configurable or derived from metadata instead of fixed.

## Individual Comments

### Comment 1
<location path="core/services/helper/main.py" line_range="489-486" />
<code_context>
         proxy_set_header X-Forwarded-Proto $scheme;
         }}
+
+        location /extensionv2/{name}/ws {{
+        proxy_pass http://127.0.0.1:{port}/ws;
+        proxy_set_header Upgrade $http_upgrade;
+        proxy_set_header Connection "upgrade";
+        proxy_set_header Host $host;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header X-Forwarded-Proto $scheme;
+        }}
         """
</code_context>
<issue_to_address>
**issue (bug_risk):** Add `proxy_http_version 1.1;` in the WebSocket location to ensure Upgrade works reliably.

Without explicitly setting HTTP/1.1 in this `location` block, some setups can fall back to HTTP/1.0 semantics and ignore the `Upgrade`/`Connection` headers, leading to intermittent WebSocket failures. Please add:

```nginx
proxy_http_version 1.1;
```

inside `location /extensionv2/{name}/ws`.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@@ -485,6 +485,16 @@ def setup_nginx_route(metadata: ServiceMetadata, port: int) -> bool:
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): Add proxy_http_version 1.1; in the WebSocket location to ensure Upgrade works reliably.

Without explicitly setting HTTP/1.1 in this location block, some setups can fall back to HTTP/1.0 semantics and ignore the Upgrade/Connection headers, leading to intermittent WebSocket failures. Please add:

proxy_http_version 1.1;

inside location /extensionv2/{name}/ws.

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be interesting to have the following lines for CORS conflicts.
proxy_hide_header Access-Control-Allow-Origin;
include cors.conf;

Add the following line for websocket upgrade:
proxy_http_version 1.1;

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @patrickelectric ,

Thanks for the review.

It would be interesting to have the following lines for CORS conflicts. proxy_hide_header Access-Control-Allow-Origin; include cors.conf;

Do you want me to include this in the default extension v2 location or just for the websocket location block?

And do you think I should make the websocket location block nested inside the other block? To reduce duplicate headers?

Add the following line for websocket upgrade:
proxy_http_version 1.1;

Will do!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants