ChromeがHTTPSに優先アクセスする307リダイレクトをHSTS関係なくやるようになった - Code Day's Night
2023年11月1日の時点の情報です。 先にまとめを書きます。興味があれば詳細もどうぞ。 まとめ 10月16日のChrome 118からHTTPS ファーストモードがデフォルトでオンに 条件によってHTTPS Upgradeが働いてhttpのサイトにアクセスするとhttpsに優先的にアクセスさせる挙動（Chromeが内部で擬似的に307リダイレクトを返してhttpsに誘導） HSTSサイトではないhttpサイトでもこの挙動となるケースがある httpsにアクセスできない場合やレスポンスに3秒以上かかる場合はフォールバックでhttpに誘導（Chromeが内部で擬似的に307リダイレクトを返して元のhttpに誘導） 詳細 条件 307で擬似的にリダイレクトする条件は、いくつかあるようです。把握しているものを列挙します。 HSTSサイト（HSTSヘッダ指定、Preloadリストのサイト） HST
Chrome の Back button を押した際に「意図しない Cache」が利用されて、期待と違うページが表示される問題について調査した - Nao Minami's Blog
以前、同僚と話していた際に「同じ URL で Accept request header に応じて response の Content-Type を変えていると、Chrome で Back button を押した際の結果が意図しないものになる」ということが話題になりました。 これは、自分も過去に経験した事があり、不思議に思っていた部分です。Safari や Firefox では発生せず、Chrome だけで発生するというのもポイントです。この挙動について、今回は調査してみました。 TL; DR 今回の調査内容を簡潔にまとめると、以下のようになります。 同じ URL で Accept request header に応じて response の Content-Type を変えると、Chrome では Back button を押した際に意図しないコンテンツが表示される事がある。Safar
ChromeとFastlyのEarly Hintsの効果計測に貢献する — HACK The Nikkei
この記事は Nikkei Advent Calendar 2020 20 日目の記事です。 日経電子版 Web チームの阿部です。今回は HTTP/2 の目玉機能の 1 つであった Server Push の事実上の終焉と、現在 Chrome チームや Fastly 社が実験中の 103 Early Hints について、日経電子版 Web での取り組みを紹介させていただきます。 HTTP/2 Server Push HTTP/2 Server Pushは HTTP/2 で策定された、一言で言ってしまうと「必要なリソースがリクエストされる前にサーバーからクライアントに送ってしまおう」という技術です。 これによりクライアントがリクエストするリソースを先回りしてサーバーが送ることで、必要なリソースが揃うまでにかかる時間を短縮できるため、パフォーマンスの向上が期待されていました。 Server
Web Application開発に10080番ポートは使ってはいけない
要約 現在最新のGoogle Chormeで10080番ポートが使用できなくなった Firefoxではすでにブロック済み NAT Slipstreaming v2攻撃への対応のため ブラウザからアクセスするサーバを建てる場合は10080以外のポートにするべき 回避方法は一応ある Chrome 91以降は10080番ポートがブロックされる Google Chormeの91 (2021/05/25 リリース)から10080番ポートへのサーバに接続できなくなります。 例えば Google Chrome 90だと以下のように10080番のポートを受け付けるサーバにアクセスできますが、91以降だとアクセスできなくなります % python -m http.server 10080 Serving HTTP on 0.0.0.0 port 10080 (http://0.0.0.0:10080/) .
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
HTTP Headers という 5万人が使っている Chrome 拡張のマルウェア疑惑。セッション盗まれて BTC も盗まれそうになった話。 - clock-up-blog
疑惑どころか 99.99% くらい黒な話。 （後記：セッション盗まれたと思ってたけど、よくよく考え直してみると生パスワードごと盗まれてる可能性もあるしやばい） 追記：続報 11月3日 今回指摘した HTTP Headers 以外にも、「Tab Manager」「Give Me CRX」「Live HTTP Headers」等で同様（？）の問題が報告されています。第三者が元の作者からソフトウェア権利を買い取って悪用する、というケースが割とある模様（？）。皆さま情報ありがとうございます。 11月4日 Zaif については、「不正な Chrome 拡張」と「スクリプトから保護されていなかったクッキー」のコンボによりセッションが盗まれていた可能性あり。 Zaif のセッション情報が盗まれた原因のひとつについて。JavaScript からクッキー値を取得させない方法。 - clock-up-blog
簡単にSSL証明書を取得可能＆シンプルな設定ファイルでHTTP/3も利用できるGo製ウェブサーバー「Caddy」
ウェブサーバーとして有名なソフトウェアはApacheやnginxですが、設定が難しいと感じる人も少なくないはず。Google発のプログラミング言語「Go」で開発された「Caddy」は、最低限の設定でSSLによる暗号化やHTTP/3での通信も可能なウェブサーバーです。 Caddy 2 https://caddyserver.com/v2 CaddyはUbuntuやCentOSなどのLinuxで利用可能。今回はUbuntu 18.04にCaddyをインストールしてみます。 下記コマンドを実行すれば、Caddyをインストールすることができます。 echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" \ | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list sudo apt update s
ChromeのHTTP/3(ドラフト版)対応 - ASnoKaze blog
追記(2019/12/24) 最新版ですと、h3-23ではなくh3-24が必要ですー 「The latest Chrome Canary supports h3-24 instead of h3-23」 https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/trZsbXM_2CM Chrome CanaryがHTTP/3のドラフト版に対応していたので、簡単に見てみる (登場するバージョンについての説明は、後述する。) 動作確認 デフォルトでは喋ってくれない。chrome canaryの起動オプションに下記を追加する。 --enable-quic --quic-version=h3-23(起動コマンドがわからない場合は、chrome://version/ を開くと確認できる) HTTP/3 draft-23に対応し
ヘッドレスブラウザ(Chrome)を使ってSPAをスクレイピングする - Qiita
一般的なスクレイピング手法とその問題点 スクレイピングというと、HTTPクライアントライブラリを用いてHTML取得し、HTML/XMLパーサーで解析するというのが一般的だと思います。 この手法の場合、以下の場合にうまく処理できません。 ターゲットのページがJavaScriptにより動的にDOMを操作する場合 HTML/XMLパーサーが取得したHTMLを正しく解釈できない場合(正しくないHTMLでもブラウザはなんとか処理するが、パーサーライブラリは正確なHTMLでないと処理できないことがある) 特に問題になるのは前者でしょう。最近のWebサイトではJavaScriptでDOMを操作することは珍しくなくなってきています。SPAであればなおさら難しく、もはやこういった手法によるスクレイピングは不可能でしょう。 ヘッドレスブラウザによるスクレイピング 動的なDOMやパーサーがうまく解釈できないとい
Webでのライブ動画再生の基礎知識について - console.lealog();
知ってることを自分の中で整理するためのメモです。 知ってることしか知らないしそこまで使い込んでないので、間違ってる可能性は多いにありです。 動画配信とライブ配信 Webで動画を配信するには2つのパターンがある 完成した動画ファイルをまるっと取得して再生するか 動画ファイルの一部を「逐次」取得して再生する（ストリーミング）か クライアントサイドとしては、サーバーにあるメディアを逐次取得するだけなので、そういう意味での違いはない 今回の記事は後者の方法について Web = HTTPベースのストリーミング用にいくつかプロトコルがある HDS(= HTTP Dynamic Streaming) HLS SS(= Smooth Streaming) MPEG-DASH このうち、HLS / MPEG-DASHが最近の主流の2つ だいたい似たような仕組みになってて、ざっくりAdaptive Strea
HTTPSにまつわる怪しい伝説を検証する - Google I/O 2016のセッションから - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今年はGoogle I/Oに初めて社員ではない立場で参加しました。全体の感想は Google I/O 2016まとめ（Web的視点） で公開していますが、今回はその中で、気に入ったセッションの1つである"Mythbusting HTTPS: Squashing security’s urban legends"について書いてみたいと思います。 セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近い
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
お疲れさまXMLHttpRequest、こんにちはfetch - Qiita
Service Workersでプッシュ通知を受信できるようになったわけですが([1]: GCM)([2]: Web Push)、Chromeではバージョン48まではGCMで通知だけができるようになっただけで、メッセージ本体は通知を受けてからService Workerでサーバから改めて受け取るような実装をする必要があったりします。 ここで、Service Workersでは、XMLHttpRequestが使えません。その代わり、XMLHttpRequest (以下、XHR)に代わるWHATWGの仕様としてFetch APIがあり、Service WorkersではこのFetch APIを使うことになっていますので、その使い方を簡単に紹介します。 Fetch API自体は、Service Workers専用のものではなく、メインスレッドでもXHRの代わりに使うことが可能です。現時点で実装し
Chrome ページセキュリティアイコンの簡略化について
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Postman | API Development Environment
Chrome Platform Status
Engadget | Technology News & Reviews
chromebook-webrtc
