Structured Field Values による Header Field の構造化 | blog.jxck.io
Token が文字列とは別に定義されているため、実装する言語によっては設計に悩む(JS 実装では Symbol を使っている)。 Parameter Parameter は Item に付与できるメタデータだ。 例えば以下は String の "abc" に対してパラメータを 2 つ付与している。 // "abc";a=1;b=2 { "value": "abc", "params": { "a": 1, "b": 2 } } データ表現には基本的に Key/Value/Metadata の 3 つがあることが望ましい。 例えば XML/HTML のようなフォーマットは Attribute がメタデータを担うが、これを再現可能になる。 <p id="foo" class="bar">hello</p> // p="hello world";id="foo";class="bar" { "p
HTTPのバージョンについて、現在のまとめ - Qiita
はじめに 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
HTTP/1.1 (RFC 7230 〜 7235) の改訂作業がはじまる - ASnoKaze blog
2021/10/21 追記。変更点について別記事を書きました。 asnokaze.hatenablog.com HTTP/1.1の仕様は下記の通り、6つのRFCで標準化されています。 rfc7230 rfc7231 rfc7232 rfc7233 rfc7234 rfc7235 これら、HTTPリクエスト・レスポンスヘッダや、ステータスコード、キャッシュや認証の仕組みといったHTTPの意味(セマンティクス)はHTTP/2でもHTTP over QUICでも変わっていません。 つまり、引き続きHTTPのセマンティクスを定義しているこれらのドキュメントは整備(メンテナンス)し続ける必要があります。 また、今回の作業によりHTTP/1.1のシンタックスと、HTTPのセマンティクスの仕様を分離することで、HTTP/3などからはセマンティクスの仕様を参照でき、仕様としてより整理された形となります。
キャッシュサーバの効率を改善するHTTP Variantsという提案仕様 - ASnoKaze blog
HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。 この機能は、Fastly VCLの機能の標準化のようです。 少々想定している背景がわかりづらいのですが、自分なりに簡単にまとめてみる。 背景 Webにおいて、サーバはクライアントからのリクエストヘッダを見てコンテンツを出し分けています。 例えば、Accept-Languageリクエストヘッダを見てコンテンツの言語を変更しています。キャッシュサーバももちろんこのAccept-Languageを見て、それぞれ毎にコンテンツをキャッシュする必要があります。 次の例を見てみましょう 1. ブラウザは下記のHTTPリクエストを送信する GET /foo H
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
