はてなブックマーク

普段**"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ではストリーム上のフレームで送信

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」としてまとめています。 この

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? IETFで議論されている、HTTP/3やWeb関連の応用トピックについて、次回ミーティングセッションに合わせ紹介していく。 IETF 107について QUICやHTTP/3は現在IETFで標準化が進められています。 そんなIETFの107回目のミーティングが今週(3/23~27)から開催されます。元々はバンクーバーで開催予定でしたが、急遽リモートでの開催となりました。 それに合わせ、開催セッションも少なくなっています(Agenda参照)。開催されるセッションは、今後の作業の進め方を決める必要がある初開催のWGや、BoF（同じ課題に興味を

(落ちの無い話です) [追記] 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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? HTTP over QUIC (HTTP/3) がUDPベースとなるニュースを見て、いわゆるAmplification攻撃(アンプ攻撃, 増幅攻撃などとも)について気になってる人もいるようなので、初心者ながら簡単に調べる。 なお、トランスポートプロトコルであるQUIC側の機能であり正確にはHTTP3で提供される対策機能ではない。 IETF版QUIC draft-16ベースの説明になります。 QUICについて 手前味噌ですが、前提となるQUICに関する資料は下記を参照 QUICの話 (QUICプロトコルの簡単なまとめ) HTTP over

DNS Queries over HTTPSにおいて、HTTPのキャッシュとDNSのキャッシュの話が面白かったのでメモ DoH IETFで「DNS Queries over HTTPS (DoH)」と呼ばれる、HTTP上でDNS通信を行うプロトコルが議論されている。DoHと呼ばれており、実装もすでに広く行われている。 外とのDNS通信を遮断するようなネットワークでもHTTPSとして出ていくため経路上からは判別することができない。特にHTTP2などで通常のWebサーバとのコネクション上でDNSクエリが送られれば見分けはつかない。 また、CDNからの配信も既存のWebの仕組みに乗っかることができるほか、HTTP/2 ServerPushも行えるなど応用の幅は広い。 例 GETとPOSTに対応しているが、GETでwww.example.comの名前解決を行う例を示す。 このように、HTTPリクエ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 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の

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? (2025/05/04追記 2022年6月公開された『RFC 9110 HTTP Semantics』にて、418は Unusedになりました) 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

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 去年ぐらいから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 G