API」という仕様があります。今回紹介する機能もchromeでいくつか実際に使用できます。もこの仕様によって定義されていました。APIを利用しています。API」のドキュメントで定義されていましたが、議論の結果それぞれ独立したドキュメントに分離されることになりました。背景は以下を参照discourse.wicg.io分離されたドキュメントはそれぞれ下記のとおりです。https://wicg.github.io/crash-reporting/https://wicg.github.io/deprecation-reporting/https://wicg.github.io/intervention-reporting/レスポンスヘッダで下記のように設定することで、そのドメインでエラーなどが発生した場合に、指定したエンドポイントにレポートが送信されます。}前述のブログでも紹介しましたが、改めてそれぞれ簡単に紹介ようかとおもいます。Reportingサイトを閲覧したブラウザがクラッシュした際に、サイト所有者に通知する機能。API)を利用していた場合に、サイト所有者に通知する機能。Reportingサイトを閲覧したブラウザがJavaScriptを実行した際など、セキュリティなどの理由によって動作が変更されたりブロックされた場合に、サイト所有者に通知する機能。internet-draftあまり知られていないがCookieにはPriority属性がある。Cookies」も2016年に提出されているが標準化には至ってない。ここらへんの議論は当時の"メーリングリスト"を参照してください。(JavaScriptからPriority属性を指定して、Cookieを設定した例)超簡単にだが仕様を紹介する。AttributeCookieのPriorityは保持優先度です。ブラウザが保存容量(ドメイン毎)の都合でCookieを消す場合はPriorityの低いCookieから消していきます。値としては下記の3つです。それ以外の値が指定された場合はMediumとして扱われます。HighMediumLow消す際は、LowとMediumごとにLデータ量・Mデータ量ふるい方から消されていきます。細かいところは実装依存になりそうです。draft-14が出ておりところどころ変わっているので書き直します。新しいHTTPヘッダを定義するときに、新しい仕様毎にシンタックスを記述するのは非常に煩わしい作業です。HTTP」として与えることで、新しいHTTPヘッダを定義するときはこの仕様を参照しリストや辞書形式のヘッダを定義できるようになります。実際、近年提案されている仕様ではしばしば参照されています。仕様ではこれらのデータ構造のパース手順も定義されており、実装としてもパースの処理が汎用的に再利用できるようになります。Listsを持ち、カンマで区切られます。Listsに関連付けられたKey/Valueのペアです。Listsの後ろに;で記述されます。l);q="9";r=wDictionariesDictionariesはKey/Valueからなる順序付きのマップです。Headersは多くの仕様で参照されていますが、一つの例をあげます。Header」では、CacheにHitしたかなどをレスポンスヘッダで通知する新しいヘッダを定義しています。このようにCache-StatusはListであると定義しています。Headersを参照するだけになります。[I-D.ietf-httpbis-header-structure]:Listの中身についてはもう少し細かい言及があるのですが、詳細は割愛します実際のCache-Statusヘッダの例です。collapse-hit=?1Parameters及びBooleansが使用されている事がわかりますね。その他このようなHTTPヘッダでデータ構造を扱うという案が出たとき、最初はJSONを使うことが検討されましたが、議論のすえ現在の形式となっています。興味ある方はよんでみてはいかがでしょうか。internet-draftHTTPリクエストは一度中断してしまうと、途中から再開することは出来ません。大きなファイルをアップロードしている場合は、最初からやり直すことになってしまいます。HTTP」という仕様が提出されています。この仕様では、PATCHメソッドとContent-Rangeヘッダを使用して部分的なアップロードを行います。Resource(具体的な番号はTBD)を新しく定義しています。部分的なアップロードは、Content-Typeにmessage/byterangeを指定し、PATCHメソッドでデータを送信します。message/byterangeはmultipart/byterangesのような構造を持ちますが単一のRange領域からなります(Content-Rangeは必須)。部分アップロードの最初の1リクエストは以下のようになります。この例では600バイト中200バイトをアップロードしています。bytes...]つづけて、次の200バイトをアップロードする場合は、以下のようになります。最初同様message/byterangeを指定します。Resourceを使用します。Resourceレスポンスは、データ全体を受信したわけではないが該当の部分アップロードリクエストはエラーではないことを示します。Header」が提出されています。この仕様の目的は、ブラウザでより詳しいトランスポートレイヤのパフォーマンスを取得することが目的となっており。HTTPレスポンスヘッダに通信の情報(RTTやMSS)が格納されます。API」よりもより詳しい情報が取得できます。Headersの規則に則って表現されます。dstport=12345まず最初に製品やサービスを示す識別子(例ではExampleEdge)が入ります。エッジサーバ側のメトリックが続きます。WebDoHはプライバシー向上のための重要な技術です。(IETFの資料を参照)。課題の一つに、DoHの利用が適さないネットワークにおいて、それをどうブラウザ(クライアント)に通知するのかの問題がある。domainという仕組みを用いてこれを実現しています。domainFifrefoxでは、そのネットワークでDoHを使用するか判断するにあたって「use-application-dns.net.」というを利用します。実際にアクセスするとMozillaの解説サイトに飛びます。use-application-dns.netの名前解決をしてDoHを使用するか決めます。名前解決し、以下のどちらかの場合はDoHを使用しません。NXDOMAIN(存在しないドメイン)やSERVFAILなど、NOERROR以外のレスポンスコードが返ってきたNOERRORレスポンスコードだが、AやAAAAレコードが含まれないネットワーク管理者(社内DNSやISPのDNS管理者)がuse-application-dns.netの名前解決に対してNXDOMAINを返すようにすることで、ユーザに対してDoHの利用を抑制できるようになります(DoHが無効になる条件は他にもあり、OSのペアレントコントロール設定なども検出します)。利用状況NXDOMAINを返す、ISP内のリゾルバの割合です。Information関連記事QUICは現在IETFで標準化が進められているトランスポートプロトコルであり、HTTP/3はそのQUICの上で効率よくHTTPのメッセージをやりとりするプロトコルです。Nginxなどがすでに実装を行っており、「相互接続テスト」を定期的に実施している。その他多くの実装があり、「Implementations」から確認ができる。Update」の資料が良かったので、大変おこがましいが自分なりに補足しながら紹介したい。(関連記事をブログ最後に羅列しておきます)。WGでは、下記の4つをコアドキュメントとして扱っている。draft-24であり、各ドキュメントとも歩調を合わせて改定されている。Processという2段階のステージにのっとって議論を進めている。Processではドキュメントの著者の裁量が強く早く柔軟性が強いです。Processでは、WG内でのコンセンサスが得られたものが仕様に反映されます。Processへの移行も近そうです。先述の通り実装をもちよっての相互接続テストを実施し仕様の確度を高めています。Callが予定されています。実装及びデプロイ結果からのフィードバックを受け付けるため、長い停止時間が設けられます。Group)に送られレビューされます。その後RFCとしての体裁が整えられ、RFCとして出版されることになります。VersionsQUICではたくさんの仕組みや機能が導入されていますが、闇雲になんでも機能追加するわけではなくQUICv1として世の中に出す機能は絞られてきました。そのため、FECやマルチパスといったいくつかの機能はQUICv2へと見送りになってきました。QUICv2が問題なく使えるように、バージョンのネゴシエーション・管理の仕組みや、ossification(硬直化)を避ける仕組みが議論され導入されています。現時点でQUICv2がどの様になるかは、パケットファーマット(invariants以外の部分)や機能含め具体的な議論は始まっていません。ExtensionsQUICは拡張できるようになっています。(pauly-quic-datagram)QUICのロードバランサとバックエンドが連携するための仕様、バージョンをより柔軟にネゴシエーションする仕様、再送を必要としないアプリケーションデータの送信などが拡張として議論されています。その他に、下記の仕様が検討されています。(deconinck-quic-multipath)経路上からQUICコネクションでパケロス発生したことを観測できるようにする仕様、経路特性を学習し接続を再開したときによりスループットを良くする仕様、Wi-Fiとキャリア回線など複数経路を用いて通信を行うマルチパスの仕様などが議論されています。ApplicationsQUICはトランスポートプロトコルですので、アプリケーションプロトコルはHTTP/3に限りません。QUIC、VPNのようにつかうmasqueプロトコル。QUICなど様々です。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。