アカウント名:
パスワード:
アクセスのキャンセルが効かずに処理が進む。中断のために接続完了までキャンセルし続けなければならないなんて馬鹿げている。
HTTPのコネクション管理は、特にHTTP/2やTLSが絡むと複雑で、いつでもキャンセルできるわけじゃないの
Escキーでキャンセルした途端、相手が送ってくるパケットは全部dropすればいいと思うかもしれんけどサーバ側はパケット再送したりタイムアウトまでコネクションを維持し続けたりすることになってリソースを一定時間占有して迷惑になるよ?
特に最近はnode.jsとかAPIの流行でapacheやnginxなどの有名サーバを使わずに独自に小規模なwebサーバをapi用とかに作る傾向があってその作りが悪いと変なタイミングで切断されると不具合が生じたりメモリが解放されなかったりパケットの再送がループしたり滅茶苦茶になることだってある
適切なタイミングまで普通の処理を続けてからじゃないと切断できないというのは、サーバへの迷惑をかけないための適切な実装だよ。
ところで、Google Chrome は、2014年6月以前、自分が高速にデータを得るため、RFCの仕様に反して大量のコネクションを1つのサーバに張ってサーバに負荷をかけていた迷惑なブラウザだったことをご存知?2014 年 6 月 に HTTP1.1 の改訂版 (RFC 7230~) が出る前に有効だった RFC 2616 の HTTP 1.1 の仕様
A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.シングルユーザクライアントは、どんなサーバやプロクシへも 2 接続より多く維持すべきではない。
今は2コネクションの制限無くなったからRFC違反じゃなくなったけど、当時は今よりサーバのリソースが限られている中、Google Chromeはユーザが早くページを表示させることだけを考えて、RFC違反の過剰なコネクションでサーバに負荷をかけていた。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
MS製ブラウザは嫌い (スコア:0, おもしろおかしい)
アクセスのキャンセルが効かずに処理が進む。
中断のために接続完了までキャンセルし続けなければならないなんて馬鹿げている。
変なタイミングで接続を破棄したら迷惑です! (スコア:0)
HTTPのコネクション管理は、特にHTTP/2やTLSが絡むと複雑で、いつでもキャンセルできるわけじゃないの
Escキーでキャンセルした途端、相手が送ってくるパケットは全部dropすればいいと思うかもしれんけど
サーバ側はパケット再送したりタイムアウトまでコネクションを維持し続けたりすることになって
リソースを一定時間占有して迷惑になるよ?
特に最近はnode.jsとかAPIの流行でapacheやnginxなどの有名サーバを使わずに独自に小規模なwebサーバをapi用とかに作る傾向があって
その作りが悪いと変なタイミングで切断されると不具合が生じたりメモリが解放されなかったりパケットの再送がループしたり滅茶苦茶になることだってある
適切なタイミングまで普通の処理を続けてからじゃないと切断できないというのは、サーバへの迷惑をかけないための適切な実装だよ。
ところで、Google Chrome は、2014年6月以前、自分が高速にデータを得るため、RFCの仕様に反して大量のコネクションを1つのサーバに張ってサーバに負荷をかけていた迷惑なブラウザだったことをご存知?
2014 年 6 月 に HTTP1.1 の改訂版 (RFC 7230~) が出る前に有効だった RFC 2616 の HTTP 1.1 の仕様
A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
シングルユーザクライアントは、どんなサーバやプロクシへも 2 接続より多く維持すべきではない。
今は2コネクションの制限無くなったからRFC違反じゃなくなったけど、当時は今よりサーバのリソースが限られている中、Google Chromeはユーザが早くページを表示させることだけを考えて、RFC違反の過剰なコネクションでサーバに負荷をかけていた。