先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ(優先度制御)まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、5月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
Command Line mitmproxy is your swiss-army knife for debugging, testing, privacy measurements, and penetration testing. It can be used to intercept, inspect, modify and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols. You can prettify and decode a variety of message types ranging from HTML to Protobuf, intercept specific messages on-the-fly, modify th
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICのAckとロスリカバリについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze
Intro リファラはリンクなどでページを遷移する際に、遷移元の URL をリクエストの Referer ヘッダに載せる仕様である。 この付与はブラウザが自動で行うため、場合によっては非公開として扱っている URL が意図せず漏れることがある。 この挙動を制御することができる、 Referrer-Policy ヘッダについて解説する。 Referer or Referrer 本来の英語としては RefeRRer が正しいが、 HTTP Header ではスペルミスした RefeRer が互換性を保つためそのまま使われている。 しかし、新しく定義された Referre-Policy は、正しいスペルが採用されている。 Referer ヘッダ 例えば https://example.com/index.html に貼られたリンクから https://blog.jxck.io に遷移する場合を考
Intro Clear-Site-Data Header の実装が進んでいる。 このヘッダについて解説する。 Clear-Site-Data 例えばログアウト処理を実施する場合は、レスポンスヘッダで Cookie を無効にするといった形で実現されるだろう。 しかし、最近では Cookie 以外にも多くのストレージがあり、アカウント特有のデータが保存されていることが多い。 local storage session storage indexed db service worker cache api これらを、ログアウト処理の中で各 API を適切に呼び出し、全て確実に削除するのは簡単ではない。 また、 httponly の Cookie や browser cache などは、 JS からの削除もできない。 SPA のように実装されている場合は、その状態を含めて初期化しないと不整合が発生
プログラミング・IT関連。知っていると便利なこと、気になって調査したこと、はまったけど解決できたことなど。 Haskellでは、http-clientライブラリを用いることで、HTTPクライアント機能を簡単に実装できます。http-client以外にも何種類かライブラリがありますが、今回はhttp-client, http-client-tlsの機能と使い方をまとめておきます。 本エントリで紹介するhttp-client, http-client-tlsライブラリの機能: 単純なHTTP GETリクエスト 主要な型の説明 Managerのカスタマイズ https proxy設定 タイムアウト値の設定 Requestのカスタマイズ ベーシック認証 リクエストヘッダ Responseの操作 ストリーミング受信 レスポンスヘッダの参照 エラーハンドリング 単純なHTTP GETリクエスト {-#
HTTP Live Streaming (also known as HLS) is an HTTP-based adaptive bitrate streaming communications protocol developed by Apple Inc. and released in 2009. Support for the protocol is widespread in media players, web browsers, mobile devices, and streaming media servers. As of 2022, an annual video industry survey has consistently found it to be the most popular streaming format.[2] HLS resembles MP
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための(レスポンスボディに載せられる)標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
私はpingが大好きです!簡単に使えて、ネットワークが稼働しているかを直接明らかにできます。 「 Pingはセキュリティの欠陥ではない!(むしろ友達である) 」、「 Traceroute上級 」の記事をご参照ください。少なくとも、外行きのping(trust(=信頼されるゾーン)からunstrust(=そうでないゾーン)へ)はセキュリティ上の心配なしに用いられるべきです。しかし、これらのuntrustからDMZへのICMPエコー・リクエストは多くの会社で拒否されているため、すべてのサーバが起動・稼働しているかをテストするのが困難になっています。 私は、顧客のサイトのDMZファイアウォールの置き換えに取り組んでいました。当然ながら私は「すべてのサーバが適切に接続されているか(NAT)」「ファイアウォールが接続を許可しているか(ポリシー)」を(外部から)知ろうとしました。 そこで私は、さまざま
Identity-based networking with ConsulConsul uses service identities and traditional networking practices to help organizations securely connect applications running in any environment. The pillars of service networkingA modern service networking solution requires that we answer four specific questions: Where are my services running? How do I secure the communication between them? How do I automate
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く