アカウント名:
パスワード:
HTTP/2 は Google の SPDY がもとになるなど、RFC制定にもGoogleが関わっている、Googleの陰謀ともいえる規格です。実は、HTTP/2 の 広告ブロックが困難というか事実上不可能になるというデメリット(Googleにとっては最大限のメリットであることから)が隠されています。Google は 表向きはユーザのプライバシーを理由に TLS 化を推進していますが、裏に広告ブロックを妨害したいという陰謀が隠れていると思います。
まず、Microsoft が反対したこともあって RFC では TLS は必須とはなりませんでしたが、Chrome と Firefox(Firefox の最大のスポンサーは残
世に中に溢れてる大半のIEは対応していないのでこんな企画でっちあげても使われることはないかと
まあ、Win10 / IE11 or Edgeからってのは確かですが(そっちはPUSH対応してそうっぽい...)、それ言ってもしょうがない気が。
# Push Promiseは帯域的とかよりは、クライアント側からNAKすれば(予約を通知されたストリームIDでの応答でリセットかける)とか# たとえ押しこまれてもレンダリングしないはあるよな、とかもうちょっとやりようはありそう# すくなくとも完全に無理矢理ではない気がする。
そもそもアドサーバと本サーバが同じ(or リダイレクト的にあれこれする設定がされてる)とか本格的にアレじゃないとこの想定は機能しないような
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:5, 参考になる)
HTTP/2 は Google の SPDY がもとになるなど、RFC制定にもGoogleが関わっている、Googleの陰謀ともいえる規格です。実は、HTTP/2 の 広告ブロックが困難というか事実上不可能になるというデメリット(Googleにとっては最大限のメリットであることから)が隠されています。Google は 表向きはユーザのプライバシーを理由に TLS 化を推進していますが、裏に広告ブロックを妨害したいという陰謀が隠れていると思います。
まず、Microsoft が反対したこともあって RFC では TLS は必須とはなりませんでしたが、Chrome と Firefox(Firefox の最大のスポンサーは残
Re: (スコア:0)
世に中に溢れてる大半のIEは対応していないのでこんな企画でっちあげても使われることはないかと
Re: (スコア:1)
まあ、Win10 / IE11 or Edgeからってのは確かですが(そっちはPUSH対応してそうっぽい...)、それ言ってもしょうがない気が。
# Push Promiseは帯域的とかよりは、クライアント側からNAKすれば(予約を通知されたストリームIDでの応答でリセットかける)とか
# たとえ押しこまれてもレンダリングしないはあるよな、とかもうちょっとやりようはありそう
# すくなくとも完全に無理矢理ではない気がする。
M-FalconSky (暑いか寒い)
Re:HTTP/2 では広告ブロックが困難、というか不可能になる (スコア:1)
そもそもアドサーバと本サーバが同じ(or リダイレクト的にあれこれする設定がされてる)とか本格的にアレじゃないとこの想定は機能しないような
M-FalconSky (暑いか寒い)