coder / coder/websocket

Reconsider and document redirect policy

オープン
#518 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Go
スター
5.5k
フォーク
372
PR マージ指標
30日以内にマージされた PR はありません

説明

## The problem

It looks like that by default the library uses the default HTTPClient:

https://github.com/coder/websocket/blob/d1468a75eee5525d183123766fbf288dca1eed9b/dial.go#L76-L103

And [the default HTTP client](https://pkg.go.dev/net/http#Client) _does_ follow redirects:

> // If CheckRedirect is nil, the Client uses its default policy,
> // which is to stop after 10 consecutive requests.

Edit: actually, doesn't the fact that we _do_ specify a `CheckRedirect` function mean that we do not stop after 10 consecutive requests?

I am aware that it is possible to provide your own `HTTPClient` struct to the `Dial()` function, and it is nice to rely on built-in defaults, I think a WebSocket library should be more concrete in this regard. Especially given the fact that this particular one claims to be able to target WASM. And, according to [the browser WebSocket spec](https://websockets.spec.whatwg.org/#websocket-opening-handshake), redirects are not followed:

> [redirect mode](https://fetch.spec.whatwg.org/#concept-request-redirect-mode) is "error"

> The reason redirects are not followed and this handshake is generally restricted is because it could introduce serious security problems in a web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the internet, even if the script checks that the URL has the right hostname.

This IMO can be considered an inconsistency between different targets.
Note that changing redirect policy for the WASM version is not possible, according to this library's docs:

> HTTPClient, HTTPHeader and CompressionMode in DialOptions are no-op

***

For reference, the WebSocket spec itself states:

> the server might redirect the client using a 3xx status code (but clients are not required to follow them)

Also for reference, the Gorilla WebSocket library IMU does not follow redirects, see this issue: https://github.com/gorilla/websocket/pull/965 and [the code](https://github.com/gorilla/websocket/blob/5e002381133d322c5f1305d171f3bdd07decf229/client.go#L377-L388).

## Suggested solution

1. Document that the library follows redirects, but not in the WASM version.
2. For the next version: Do not follow redirects by default, and document this.
This can either be considered a breaking change (so it goes to v2.x.x), or a bug fix.

***

Related issue: https://github.com/coder/websocket/issues/333

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

dial.go の 76-103 行目と DialOptions を説明しているライブラリのドキュメントから始め、リダイレクトの挙動を、引用されている WebSocket 仕様および WASM の制限と比較してください。現在のポリシーを明確にして文書化し、将来のバージョンでデフォルトを変更すべきかどうかを判断してください。関連する issue #333 に追加のコンテキストがあります。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
go
領域
api, networking
issue の種類
機能追加
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。