普段"HTTPヘッダ"と呼んでるものについて、仕様上は "header fields" と呼ぶらしかったり、自分でも整理できていなかった。 今後もHTTP関連の仕様を読んでいく上でも理解しておきたかったので、この記事では、下記の用語について整理していく HTTP field header/trailer field field line HTTP セマンティクス まず、参照するドキュメントについて簡単に補足します。今回触れる用語は、HTTPセマンティクスの仕様である「HTTP Semantics(ドラフト版)」で定義されています。 HTTPセマンティクスとは、HTTPメッセージ(HTTPメソッドや、レスポンスコード、フィールド)の意味の定義です。 各HTTP/1.1~HTTP/3の仕様ではこのHTTPメッセージをどのように送るか(例えば、HTTP/2ではストリーム上のフレームで送信する)を

(落ちの無い話です) [追記] IETF107 (2020/03/25)において、Googleでの利用例が共有されました。それについて、記事最後に追記しました。 公式な情報はまだないが、GoogleがQUICコネクションをVPNとして利用する「QUIC as a VPN (QBone)」なるものを作ってるのは窺い知ることができる。 2017年6月に、GoogleでQUICの開発に携わっているIan Swett氏より「QUIC Messages」という提案書が出ている。この提案書の、提案背景の章で「QUIC as a VPN (QBone)」は登場する。 Today, most production QUIC traffic is HTTP. However, developers are actively working on running WebRTC over QUIC (aka Q

HTTP over QUIC (HTTP/3) がUDPベースとなるニュースを見て、いわゆるAmplification攻撃(アンプ攻撃, 増幅攻撃などとも)について気になってる人もいるようなので、初心者ながら簡単に調べる。 なお、トランスポートプロトコルであるQUIC側の機能であり正確にはHTTP3で提供される対策機能ではない。 IETF版QUIC draft-16ベースの説明になります。 QUICについて 手前味噌ですが、前提となるQUICに関する資料は下記を参照 QUICの話 (QUICプロトコルの簡単なまとめ) HTTP over QUICと、その名称について (HTTP3について) QUICのコネクションマイグレーションについて アンプ攻撃とは そもそもアンプ攻撃とは、送信元アドレスを攻撃対象となる対象のIPに偽装したUDPパケットをサーバに送信することによって、サーバからの応答を

QUICについて (2020/06 追記) 手前味噌ですが、QUICについて別途まとめましたので、参考にして頂ければ 2020/06/01 時点でHTTP/3, QUICの解説書を書きました https://github.com/flano-yuki/http3-note あわせて個人ブログもどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) QUICの話 (QUICプロトコルの簡単なまとめ) HTTP over QUICと、その名称について (HTTP3について) QUICとは QUICとはGoogleの考案したHTTPのメッセージを効率よく高速かつ安全にやりとりするためのプロトコルであり。UDP上でTCP+TLS1.3+HTTP/2のような機能を持ち、信頼性のある安全な通信を行う。 スタック図を見ると分かる通り、TCPのような輻輳制御やロスリカバリと、TL

418 I’m a tea potとは ステータスコード 418 I’m a tea potは、エイプリルフールに発行されたジョークRFCであるRFC2324「Hyper Text Coffee Pot Control Protocol」 で定義されているステータスコードです。 Googleでも 418 を返すURLがあります。 Error 418 (I’m a teapot)!? https://www.google.com/teapot 昨日、golangとnodejsにおいて、418 I’m a tea pot の実装を削除するIssue が投げられています。 golang: net/http: remove support for status code 418 I'm a Teapot nodejs: 418 I'm A Teapot #14644 Issue中でも書かれている通

はじめに 去年ぐらいからCookieに関する議論が活発に行なわれているように感じます。そこでCookie関連の最新動向について仕様の観点から幾つか列挙します。 Deprecate modification of 'secure' cookies from non-secure origins Cookie Prefixes Same-site Cookies A Retention Priority Attribute for HTTP Cookies Content Security Policy: Cookie Controls GoogleのMike West氏による提案がほとんどです。議論はIETFのHTTPbis WGやW3Cで行なわれており将来的には正式に標準化されるものもあるでしょう。 また、幾つかはChromeへの実装が進められています。 (間違いなどありましたらご指摘下さ

はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。 バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。 意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。 バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H

IETFのOAuth WGでは、今あるOAuth2.0関連の仕様を整理し、一つの仕様としてまとめなおし OAuth2.1 として標準化するとりくみが進められています。 今回は、簡単にOAuth2.1について紹介します。 OAuth 2.0 OAuth 2.0は2012年10月に「RFC6749 The OAuth 2.0 Authorization Framework」として標準化されています。その後、OAuth2.0の改善は続けられ、セキュリティ向上のために利用すべき機能(PKCE)などが追加されているほか、逆に非推奨になっている機能(Implicit Grant)などがあります。 IETFのOAuth WGではOAuth2.0を安全に利用するためのベストカレントプラクティスを「OAuth 2.0 Security Best Current Practice」としてまとめています。 この