ZTMS掲示板

無通信による切断でエラーになってしまう事例がありました。
https://news.tbs.co.jp/
この URL はリダイレクトするのですが、リダイレクト先を直接登録した場合は問題ないようです。

ログはこのようになっています。
────
10:02:49.805 [0:1176]接続:127.0.0.1
10:02:49.805 [0]受信:POST /:poke HTTP/1.1 Host: localhost:60080 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0 Accept: */* Accept-Language: ja,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded; charset=UTF-8 If-Modified-Since: Thu, 01 Jun 1970 00:00:00 GMT X-Requested-With: XMLHttpRequest Content-Length: 26 Origin: http://localhost:60080 DNT: 1 Connection: keep-alive Referer: http://localhost:60
10:02:49.805 [0]URL0:https://news.tbs.co.jp/
10:02:49.925 [1124]外部接続(SSL):news.tbs.co.jp=2001:260:306:c::a32d:7601:443
10:02:49.925 [1124]外部送信:GET / HTTP/1.1 Host: news.tbs.co.jp User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0 Accept-Encoding: gzip,deflate Accept-Language: ja,en Accept: */*
10:05:50.960 [0]スレッド実行中待機...(無通信)
10:05:50.960 [1124]外部受信0bytes:
10:05:50.992 [0]中断します...
10:05:51.959 [0]切断(無通信)
────

content-length: 0 の取り扱い関係で不必要な待機をしているんじゃないかと想像します。
それとこの無通信エラーが出る URL のリンク切れ調査と同時に調査している URL があった場合にそちらも一緒にエラーとなってしまうようです。

齊藤さん

ありがとうございます。遅くなりました。
ご指摘の無通信エラーの症状は私の環境でもすぐ再現しました。

原因は Content-Length:0 の扱いではなさそうで、受信データが来ているように見えるが実際は1バイトもデータを読み取れず(SSL_read)、
さらにタイムアウト判定にも不具合があったことが重なり、無限に受信を待ち続けてしまっているような状態でした。

ひとまず無限に待機してしまう問題は回避できましたが、
なぜSSL_readでデータを読み取れないのか？どうすれば読み取れるのか？がはっきりしていません。。

いまのところ「HTTP/2を知らない時代のSSLクライアントがアクセスしてもすぐに切断されてしまい正常応答(リダイレクト)を返してくれない」ように見えています。
curlコマンドで確認してみたのですが、HTTP/2を知らない時代のバージョンではエラーになって応答を受信できませんでした。
私の確認した範囲では、正常に応答受信できたブラウザとcurlコマンドは、どちらもHTTP/2通信でした。

HTTP/2しか受け付けてくれないサーバーがあるのでしょうか・・。

もしJCbookmark側がHTTP/2に対応しないと正常に応答受信できないということになりますと、
自力でHTTP/2クライアントを実装するか・・ちょっとハードルが高そうなので他のライブラリに頼る方向で選定をはじめるか迷います。
どちらにせよ時間がかかりそうな事態です。。

ひとまず、無通信エラーではなく約5秒後に受信タイムアウトになるよう対応した JCBookmark.exe ファイルをこちらに用意しました。
https://ztmsdf.appspot.com/jcbookmark/JCBookmark-v20220509.exe.zip

ただリダイレクト応答を受信できませんので中途半端なバージョンです。。
無通信エラーによる副作用のような症状は多少軽減されているかもしれませんが。。

ありがとうございます。
個人的には (少なくとも現時点では) HTTP/2 に対応しないという仕様でも良いと思うのですが、エラーにするならするでそれを上手くハンドリングする必要はあるだろうなとは思います。
通信は相手があることですから中には規格に反する変な挙動だってあるでしょうし、しかしそれでもクライアントが暴走するようなことがあってはいけませんから。