HTTPSの接続情報を通知する "HTTPS DNSレコード" の提案仕様 (2021/07更新) - ASnoKaze blog
HTTPSで通信を開始する際に、事前に知っていると有用な情報が幾つかあります。 サーバがHTTP/3に対応しているか(Alt-Svc情報) TLS Encrypted Client Hello で必要な情報 サーバがHSTSを要求してくるか このような情報を提供する新しいDNSレコードを定義する仕様が提案されています。提案仕様「Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)」では、サービスに関する情報を通知する一般形式であるSVCBレコードと、HTTPS用であるHTTPSレコードを定義しています。 もともとはHTTPSSVCレコードという名称でしたが、最近改称されHTTPSレコードになりました。 また、このHTTPSレコードを用いることでANAMEレコードが解決しようとしていた
Fetch Metadataリクエストヘッダについて (Sec-Fetch-*) - ASnoKaze blog
ブラウザがリソースをFetchするさいに、そのFetchに関するメタ情報をリクエストヘッダに付与するというのがFetch Metadataという仕様です。 この情報を用いれば、画像の読み込みのFetchで銀行用のAPIが叩かれるはずがないといった、明らかな不正なリクエストを検知することができるようになる。 毎度おなじみGoogleのMike West氏によって仕様「Fetch Metadata Request Headers」が書かれている。 以前「Sec-Metadataヘッダについて」で紹介したSec-Metadataをより改良したものです。 ヘッダを分けることでヘッダ圧縮の仕組みとも相性が良くなっています。 Example 以下のような、そのフェッチに関する情報を示すSec-Fetch-*ヘッダが付与される。 Sec-Fetch-Dest: image Sec-Fetch-Mode:
Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog
20191226 追記 SameSite属性のついたCookie自体を拒否する古いクライアントにご注意ください https://sites.google.com/a/chromium.org/dev/updates/same-site/incompatible-clients 20190823 追記 suidenOTI さまよりご指摘いただきました 不具合があったためChrome80でのリリースに延期になったようです。 https://www.chromestatus.com/feature/5088147346030592 https://www.chromestatus.com/feature/5633521622188032 20190523 追記 Firefoxでも同様の動きがあります https://groups.google.com/forum/#!msg/mozilla.de
Cross-Origin-Opener-Policyについて - ASnoKaze blog
Cross-Origin-Opener-Policy (COOP)は現在、ChromeやFirefoxで実装が進められている機能です。 Chrome: Implement Cross-Origin-Opener-Policy firefox: Implement Cross-Origin-Opener-Policy 仕様としては、whatwgで長らく議論がされており、おそらく仕様に入るでしょう Restricting cross-origin WindowProxy access (Cross-Origin-Opener-Policy) · Issue #3740 · whatwg/html · GitHub Cross-Origin-Opener-Policy: provide a clearer spec. · Issue #4580 · whatwg/html · GitHub 面白
新しいWebの双方向通信 "WebTransport" について - ASnoKaze blog
関連記事 WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog WebTransport over HTTP/2 の仕様について - ASnoKaze blog WebTransport over QUIC について - ASnoKaze blog WebTransportという新しい双方向通信フレームワークの議論が始まっている。 GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。 discourse.wicg.io WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計にな
HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog
この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである「QPACK 」について説明します。（執筆時 draft 07） 2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com HTTP/2の場合 ハフマン符号 静的テーブル、動的テーブル HTTP/3とQPACKの導入背景 QPACKの概要 Encoder Instructions Decoder Instructions Header Block Instructions 相対インデックス Compressed Headers エラーハンドリング その他 QPACKという名称について HTTP/2の場合 簡単に、HTTP/2で導入されたヘッダ圧縮の仕組みである「RFC7541 HPACK」について補足します。飛ばしていただいても大丈夫です。 HTTP/2の元となったSPD
Signed Exchange Reporting for distributors について - ASnoKaze blog
Webサイトを一つに固めて署名して再配布可能にする、Web Packagingという仕組みがあります。 現在、Web Packagingは以下の3つの仕様からなっています。 Signed HTTP exchanges Bundled HTTP exchanges Loading AMPなどをより標準化された仕組みで実現するために、現在議論が進められています。 HTTPリクエストとHTTPレスポンスの対(HTTP exchanges)を署名したsxgというファイルを再配布するわけですが、このsxgファイルの検証エラーをユーザエージェントからレポートできるようにする「Signed Exchange Reporting for distributors」という議論がされています。 Signed Exchange Reporting for distributors 概要 publisherがar
QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP
ブラウザからシリアルポートにアクセスするSerial API - ASnoKaze blog
blink-devメーリングリストに「Intent to Implement: Serial API」として「Serial API」の実装に着手する旨の投稿がされている。 この「Serial API」はW3CのWICGで議論がされており、ブラウザからシリアルポートにアクセス可能にする。3DプリンタやArdbinoなど、様々なデバイスと接続できるようになる。 パーミッションの要求については、すでに実装されている「Web Bluetooth」「WebUSB API」とおなじになるようだ。 sample 仕様では、Ardinoからデータを読み込む例が示されている //Request the list of ports from the user SerialPort.requestPorts().then(ports => { //Pick the first matching port var
Chrome 71で検討されている iframeへのPermission Delegation - ASnoKaze blog
Webサイトがカメラや位置情報をアクセスする際にパーミッションを要求する場合がある。iframeで埋め込んだページでも同じようにパーミッション要求が行える。 Chrome 71で導入が検討されている「Permission Delegation」では、iframeで埋め込まれたページでのパーミッション要求の仕組みがわかりやすくなる。(iframe内のドメインからパーミッション要求されても、普通のユーザにはわかりにくい) iframe内でパーミッションが必要になった際、top level origin(URLバーに表示されているサイト)がパーミッションを要求し、その権限を移譲する形になる。 その結果各パーミッションはtop level originに紐づくため、ユーザは権限の管理が行いやすくなる。 例 https://asnokaze.com/pd.html は以下のように、iframeを埋め
キャッシュがHitした情報を示すCacheヘッダの標準化提案 - ASnoKaze blog
20191104 追記 draft 01でCache-Status に改称されるとともに、内容も変わりました 更新記事を書きました asnokaze.hatenablog.com CDNなどのサービスは、リクエストがキャッシュにヒットしたかどうかをx-cacheヘッダに格納してレスポンスしてくれます このx-cacheヘッダは独自の形式であり、例えば以下のようになっています。 （CDNによっては、x-cache以外のヘッダを使うものもあります） fastly (document) X-Cache: MISS, HITAmazon CloudFront X-Cache: Hit from cloudfront先述のように、x-cacheヘッダは標準化されておらずCDN毎に独自に使用されています。 そこで、IETFのHTTbisにおいて キャッシュのHit情報などを格納するcacheヘッダの標
NginxでTLS1.3の0-RTTハンドシェイク (ssl_early_data)を試す - ASnoKaze blog
追記20180922 OpenSSLも対応しました 「support for TLSv1.3 early data with OpenSSL.」 http://hg.nginx.org/nginx/rev/548a63b354a2 昨日、NginxがTLS1.3の0-RTTハンドシェイクをサポートしたので試した。無事動作することが確認できた。 該当コミットはこの2つ SSL: enabled TLSv1.3 with BoringSSL. SSL: support for TLSv1.3 early data with BoringSSL. TLS1.3の0-RTTハンドシェイクは、一度ハンドシェイクをした相手とはClientHelloに続けてアプリケーションデータ(HTTPリクエスト)を送信することで、より早くデータのやりとりを開始する方法です。 (引用: https://blog.cl
Clear-Site-Dataヘッダでブラウザに記憶されているデータを消す
Webブラウザは表示したサイトに関する様々なデータを記憶しています 例えば cookie cache HTTP認証の情報 localStorage service worker registrations しかしサーバ側からこれらのデータを明示的に消すのは難しい場合があります。例えば、httpOnlyのcookieは現在ブラウザにどのようなCookieがセットされているか知るのは難しいでしょう。 そこで、そのようなデータを消す Clear-Site-Data レスポンスヘッダ がW3Cで議論されています。実は、3年前に「Clear Site Data、ブラウザのローカルデータを削除する仕組み」で書いたときから微妙な変更が入っている。 また、ブラウザへの実装も進んでおり試せるような段階となってきている。 mozilla.dev.platform: Intent to ship: Clear-
ブラウザの廃止される機能を使っていることを検知する Deprecation Reports (+ Intervention reports ) - ASnoKaze blog
20180713追記 Intervention reports について追記しました ブラウザのバージョンアップは定期的に行われており、その度に廃止される機能もあります。 廃止されることは公式にアナウンスされますが、そもそも自分が使っているかどうかすべてを把握することは難しいでしょう。JavaScriptのAPIであったり、HTTPヘッダだったりとその範囲は非常に広く、ライブラリの特定のバージョン以下だと問題になるといったケースも有るかと思います。 このような場合に役に立つ、廃止される機能が使用されていることをWebデベロッパー側で検知する仕組みが「Deprecation Reports」です。 Blink開発者メーリングリストでも議論されていますが、すでにChrome Canaryで動作するので、簡単に動作確認してみます。 Reporting API 表示してるページのエラーなどを指定し
ブラウザのネットワークエラーをレポートさせるNetwork Error Loggingが来た - ASnoKaze blog
20180727追記 CORS対応が必要になりました asnokaze.hatenablog.com 20180703追記 ドキュメントはhttps://w3c.github.io/network-error-logging/ にが移されました 20180608追記 仕様上は、jsonの各値はハイフンではなく、アンダースコアを使用するようになります report-to => report_to max-age => max_age ... etc https://github.com/WICG/network-error-logging/commit/86c4d1c0fa4c5d5ca1d8bdcd9fa931e7e4ab65c2 こんな感じ nel: {"report_to": "network-errors", "max_age": 2592000, "include_subdomai
CT対応を示すExpect-CTヘッダとは - ASnoKaze blog
追記 2021/11/15 Expect-CTヘッダの役割は、CTの利用が必須となり不要となる方向です asnokaze.hatenablog.com Certificate Transparency Certificate Transparencyと呼ばれる、不正な証明書の発行を検知する仕組みがGoogle社によって考案され、RFC 6962として標準化されています。もちろん、Google Chromeもこの機能に対応しており、ログサーバーにSigned Certificate Timestamp(SCT)を検証し、正しく発行された証明書なのかを検証します。 詳しい仕組みについては、各社CAの説明を読むとわかりやすいかと思います。 CertificateTransparency（証明書の透明性）とは - Symantec Certificate Transparency（証明書の透明性）
NginxがHTTP2サーバプッシュに対応したので試す - ASnoKaze blog
追記 [nginx-announce] nginx-1.13.9 http://mailman.nginx.org/pipermail/nginx-announce/2018/000207.html 1.13.9でサーバプッシュがサポートされました 先程、Nginxでサーバプッシュをサポートするコミットが入ったので試す。 HTTP/2: server push. http://hg.nginx.org/nginx/rev/641306096f5b ビルド $ git clone https://github.com/nginx/nginx.git $ cd ./nginx $ ./auto/configure --with-http_ssl_module --with-http_v2_module $ make $ sudo make install #一旦インストールしてしまう 設定 一
Nginxのリバースプロキシでバックエンドとhttp2通信する - ASnoKaze blog
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
Webページを丸ごとパッケージングする Web Packagingとは - ASnoKaze blog
20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog 20180208追記 Bundled HTTP Exchangesについて記事を書きました Bundled HTTP Exchanges とは (WebPackagingの議論より) - ASnoKaze blog 20180121追記 署名の仕組みとして Origin-Signed HTTP Exchanges を利用する方向のようです HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様 - ASnoKaze blog 20171001追記 IETF99にてユースケースについてまずまとめるべき気というフィードバックが有り、それをうけて「Use Cases and
Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
