Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Allow customize how HTTP errors are rendered when `websocket.Accept` fails to upgrade

オープン
#545 コメント 4 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

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

調査の方向性

websocket.Accept と websocket.AcceptOptions から始め、アップグレードに失敗したときに現在使用されている HTTP エラーのレンダリングを調べます。既存のデフォルトを維持しながら、設定可能なエラーレンダリング動作を定義し、その後、呼び出し元が必要な JSON エラーレスポンスを生成し、説明されているとおりにエラーを区別できることを検証します。

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

説明

IDEA: Might be as simple as a new HttpErrorRenderer (or OnError, etc.) option added to websocket.AcceptOptions. When unspecified, default to a fn that implements current rendering behavior. It would take at minimum a ctx, the err and the http status code.

Nice addition: the full set of errors.New("..") would be exposed to user so that one can use errors.Is to get more granularity than provided http statuses.

We need this feature in order to produce https://www.rfc-editor.org/rfc/rfc9457.html (a standardized JSON error response format) when an error occurs in order to match the rest of our API which produces this error response format for all of its endpoints. Current hard-coded behavior prevents us to comply with our policy when WS upgrade fails in this library. Our user thus can't systematically assume this nice JSON format and must workaround this limitation...

主要言語
Go
スター
5.5k
フォーク
377
30日以内にマージされた PR はありません

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

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

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

coder/websocket のほかの issue

coder/websocket の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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