Fediver

今更ながらHTTP/2に対応した

ひょっとしてCloudflare Tunnel使ってMisskey動かしてるときってストリーミング見れない？？
こんなエラーが出るんだけど

Traceback (most recent call last):
  File "/tmp/test.py", line 33, in <module>
    asyncio.run(brm.main())
  File "/usr/local/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.10/site-packages/brcore/core.py", line 126, in main
    await asyncio.create_task(self.__runner(backgrounds))
  File "/usr/local/lib/python3.10/site-packages/brcore/core.py", line 209, in __runner
    raise e
  File "/usr/local/lib/python3.10/site-packages/brcore/core.py", line 144, in __runner
    async with websockets.connect(self.__WS_URL) as ws:
  File "/usr/local/lib/python3.10/site-packages/websockets/asyncio/client.py", line 587, in __aenter__
    return await self
  File "/usr/local/lib/python3.10/site-packages/websockets/asyncio/client.py", line 543, in __await_impl__
    await self.connection.handshake(
  File "/usr/local/lib/python3.10/site-packages/websockets/asyncio/client.py", line 114, in handshake
    raise self.protocol.handshake_exc
  File "/usr/local/lib/python3.10/site-packages/websockets/client.py", line 325, in parse
    self.process_response(response)
  File "/usr/local/lib/python3.10/site-packages/websockets/client.py", line 142, in process_response
    raise InvalidStatus(response)
websockets.exceptions.InvalidStatus: server rejected WebSocket connection: HTTP 403

危なくないホスト名もexample\.comとかexample[.]comみたいにエスケープするの不思議だったけどhttp://とか勝手に付くことあるからなのに気づいた

[Auto Note]:Updated
Fetch URL: https://github.com/misskey-dev/misskey
Commit: 39c487e1 to 96fc7e30
Bump version to 2025.2.1-beta.2
fix(backend): S3_SAFEかつURL_SAFEでない文字列をprefixに使えないように (#15455)
fix(frontend): ユーザのサジェスト中に@を入力してもサジェスト結果が消えないように (#15435)
fix(backend): カスタム絵文字の一括インポートをした時にHTTPプロキシの除外設定が効かないのを修正 (#15431)

#みーくりあ！UpdateLog

Nginx君, HTTPの仕様に従ってデフォルトではWebSocket通さないの, 間違ってはないけど不便なのでやめてくれ

うちの個人サイトのCaddyfile
（RailwayのバックエンドでPHP動かしているやつ、コンテナ内部でポート8000の plaintext HTTP で待ち受けている。拡張機能 supervisor で php-fpm 起動しているので supervisor ありでビルドしないと動かない）
https://github.com/kuropen/kuropen-org-2025/blob/main/docker-resource/Caddyfile

@nagutabby httpでアクセスしたならそこからの応答は信頼できないので、httpsにリダイレクトするのは意味がないという立場。
hsts (preloadでない) でhttp通信に付いてくるヘッダを無視するのはこのせい

hsts preloadが登録にhttpからのリダイレクトを求めるの、意味ない気がするんだけどまあ独自仕様だししょうがないか。

@s3_odara ちなみにhttp→httpsリダイレクトしないとHSTS Preload出来ない

@dampuzakura 切り捨てるメリットがないし、それなら最初からhttp塞げばいいから

httpからhttpsにリダイレクトするとアクセスできない端末が出てくるし意味ないので必要ない派

[Auto Note]:Updated
Fetch URL: https://github.com/misskey-dev/misskey
Commit: 4f31dcfe to 8232ea69
fix(backend): デフォルト起動時のメインプロセスはHTTPサーバモジュールのみ読み込む (#15355)

#みーくりあ！UpdateLog

@dampuzakura HTTP/1.1はさっさと滅んだほうがいいが, 16年もHTTP/1.1が最新な状態が続いてしまったせいでHTTP/1.1が前提のシステムが大量にあるから

@dampuzakura HTTP/1.1からUpgrade可能なプロトコルって時点でWebSocketのがマシ

@dampuzakura むしろ可能な限りすべてをブラウザで動かすべきだと思ってる
Web技術はどこでも動くからね
httpよりいい規格よりもhttpを拡張した規格を考えるべきじゃないかな

@dampuzakura 可能な限り全てをhttp(s)に載せるモチベーションってブラウザで扱いたいからじゃないのか?

この発想はQUICが由来だけど､QUICはそれ自体に暗号化の機能が付いているので公開HTTPサーバー以外の用途に活用しづらい

藍ちゃんから出てるエラー

app-1  | Uncaught exception: 
app-1  | RequestError
app-1  |     at ClientRequest.<anonymous> (file:///ai/node_modules/got/dist/source/core/index.js107)
app-1  |     at Object.onceWrapper (node639:26)
app-1  |     at ClientRequest.emit (node536:35)
app-1  |     at emitErrorEvent (node104:11)
app-1  |     at TLSSocket.socketErrorListener (node512:5)
app-1  |     at TLSSocket.emit (node524:28)
app-1  |     at emitErrorNT (node:internal/streams/destroy8)
app-1  |     at emitErrorCloseNT (node:internal/streams/destroy3)
app-1  |     at process.processTicksAndRejections (node:internal/process/task_queues:90:21)AggregateError [ETIMEDOUT]: 
app-1  |     at internalConnectMultiple (node1128:18)
app-1  |     at afterConnectMultiple (node1693:7) {
app-1  |   input: undefined,
app-1  |   code: 'ETIMEDOUT',
app-1  |   timings: {
app-1  |     start: 1736517638497,
app-1  |     socket: 1736517638497,
app-1  |     lookup: 1736517638504,
app-1  |     connect: undefined,
app-1  |     secureConnect: undefined,
app-1  |     upload: undefined,
app-1  |     response: undefined,
app-1  |     end: undefined,
app-1  |     error: 1736517775311,
app-1  |     abort: undefined,
app-1  |     phases: {
app-1  |       wait: 0,
app-1  |       dns: 7,
app-1  |       tcp: undefined,
app-1  |       tls: undefined,
app-1  |       request: undefined,
app-1  |       firstByte: undefined,
app-1  |       download: undefined,
app-1  |       total: 136814
app-1  |     }
app-1  |   },

可能な限り変な環境でGensokyo Radioを聴いてみた
127.0.0.1:8080にはlocal_proxy_rsがスタンバってる

ポイントはHTTP/1.0でアクセスすること､1.1だとchunked形式で返してくるから単純なスクリプトだと処理できん

ちなみにページにHTTPレスポンスヘッダが表示されるのは謎
リクエストはHTTP/1.0で送ってるのにレスポンスはHTTP/0.9を期待してるんじゃないかという仮説はある