第1章 進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る | gihyo.jp
HTTP/3入門 第1章進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る この特集記事は2021年6月24日に発売されたWEB+DB PRESS Vol.123に掲載された特集1「HTTP/3入門」を再掲したものです。 先日2022年6月にHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここではRFCの正式リリースに伴い、いち早く変更点を抑え、囲みボックスを用いた加筆解説でわかりやすくお伝えしております。 特集のはじめに HTTP（Hypertext Transfer Protocol）の最新版であるHTTP/3が登場しました。HTTP/3では、より安全で速い通信が行えます。本特集では、今までのHTTPにあった課題と、HTTP/3で課題をどのように解決し、改善が行われたかを解説します。 本章では、HTTPそのものと各バージ
デフォルトでCookieをオリジンに紐づける、ChromeのOrigin-Bound Cookies - ASnoKaze blog
Blinkの開発者メーリングリストで「Intent to Prototype: Origin-Bound Cookies」という議論が行われています。 Cookieをより安全にするために、デフォルトでCookieをオリジンに紐づけるようにする提案です。Cookieをset-cookieしたオリジン以外からは、そのCookieにアクセスできないようになります。 詳しい背景や仕組みについては次のページから確認できます。 github.com かんたんに、Origin-Bound Cookiesの動作をみていきましょう。 例 オリジンは、スキーム、ホスト名、ポートの組です。それらのうち一つでも異なれば、オリジンが異なることになります。 例えば、次のようになります。 http://example.comによってセットされたcookieは、http://example.comにのみ送信されます。ht
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
nginxでの静的ファイル配信時のキャッシュ(ETagやLast-Modifed) - [Dd]enzow(ill)? with DB and Python
ISUCON7の予選は、画像へのアクセスをいかに304で処理して帯域を節約できるかが肝でした。そこでnginxのETagやLast-Modified等の設定周りを見直してみます。 環境 以下の環境で試しました。 OS: Ubuntu 16.04 nginx: 1.10.3 Client: python-requests 2.8.1 初期設定 サーバ上の/public/sample.pngにサンプルの画像を配置し、http://host/sample.pngでアクセスできるようにnginx.confを設定します。以下で拡張子が*.cssや*.js、*.pngの場合は/public配下より配信されます。 server { listen 80; location ~* \.(css|js|png)$ { root /public; } } 今回はアクセスのテスト用にPythonのrequests
![nginxでの静的ファイル配信時のキャッシュ(ETagやLast-Modifed) - [Dd]enzow(ill)? with DB and Python](https://cdn-ak-scissors.b.st-hatena.com/image/square/ae2a97c1b1685f861b17e78c5fe093218691402a/height=288;version=1;width=512/https%3A%2F%2Fcdn.image.st-hatena.com%2Fimage%2Fscale%2F3bc70b787d615e8e70fe7f6cf0f78c1d74316a8d%2Fbackend%3Dimagemagick%3Bversion%3D1%3Bwidth%3D1300%2Fhttps%253A%252F%252Fcdn-ak.f.st-hatena.com%252Fimages%252Ffotolife%252Fd%252Fdenzow%252F20171126%252F20171126221155.png)
HTTPレスポンスボディを送ったあとに、Cache-Controlを変更可能にする仕様 - ASnoKaze blog
HTTPでキャッシュは、サーバがHTTPレスポンスを返す際、Cache-Controlヘッダをつけることで、どのようにキャッシュするか指示することができます。ヘッダ自体はレスポンスボディより前に送る必要があります。 Mark Nottingham氏らによって提案された「Updating HTTP Caching Policy in Trailers」という仕様では、HTTPレスポンスボディを送り終わってから、Cache-Controlを変更可能にします。 具体的には、Trailer FieldでCache-Controlを送った際の挙動について定義を与えています。 HTTP Trailer Field まずは、Trailer Fieldについて説明します。 HTTPのセマンティクスの仕様(URL)では、HTTPボディを送ったあとにあとからヘッダ(正確にはFieldと呼ぶ)を送ることができま
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
Brotli を用いた静的コンテンツ配信最適化と Accept-Encoding: br について | blog.jxck.io
Intro High Sierra に乗る Safari 11 で Brotli 対応がされるということで、メジャーブラウザの Brotli 対応が概ね揃うことになる。 そこで、本サイトも Brotli による静的コンテンツ配信に対応した。 brotli brotli は Google が開発した新しい圧縮形式である。 Brotli Compressed Data Format LZ77 とハフマン符号化を合わせたものであり、元々は WOFF2 の仕様の一部として作られたものが、汎用化されたものである。 過去に公開されている zopfli と比べても、さらに圧縮率が 20-26% 向上しており、解答速度は zlib 相当とされている。 この効果に寄与する特徴的な要因として、仕様に含まれる辞書が挙げられる。 Static Dictionary 圧縮アルゴリズムは、簡単に言えば頻出する一致部分
HTTP の圧縮 - HTTP | MDN
HTTPガイドHTTP の概要典型的な HTTP セッションHTTP メッセージMIME タイプ（IANA メディア種別）HTTP の圧縮HTTP キャッシュHTTP 認証HTTP Cookie の使用HTTP のリダイレクトHTTP 条件付きリクエストHTTP 範囲リクエストコンテンツネゴシエーションHTTP/1.x のコネクション管理HTTP の進化プロトコルのアップグレードの仕組みプロキシサーバーとトンネリングHTTP クライアントヒントHTTP セキュリティサイトの安全化HTTP ObservatoryPermissions Policy Experimental コンテンツセキュリティポリシー (CSP)オリジン間リソース共有 (CORS)Cross-Origin Resource Policy (CORP)ヘッダーリファレンスHTTP ヘッダーAcceptAccept-CHAc
HTTPメソッドのPUT・DELETEは、本当に冪等（べきとう）なのか？ – knowledge capsule
GET・HEAD GET・HEADが冪等というのは、納得がいく。 確かに、同じリソースファイルのURLに何度GET・HEADリクエストしようとも、リソースの状態は変わらないだろう。 少し引っかかるのは、クライアントに返却されるレスポンスコードは変わるということだ。 GETのレスポンスは、リソースファイルがクライアントでキャッシュされているかによって、200（200）か304（Not Modified）になるだろう。 PUT、DELETEについては疑問が残る。 PUTは、対象のリソースを更新するが、リソースがなければ作成する。 DELETEは、対象のリソースがあれば削除するが、リソースがなければ何もしない。 サーバーのリソースの状態を見ると、PUTの場合、1度目のリクエストでリソースが作成され、2度目のリクエストでリソースが更新される。 DELETEの場合、1度目のリクエストでリソースが削除
Cache Digest と HTTP2 Server Push の現状 | blog.jxck.io
Intro httpbis のチェアである mnot から、 Cache Digest についての現状確認が ML に投稿された。 もしこのまま反応がなければ、 Cache Digest は終わり、対ブラウザキャッシュの Server Push は現実的ではなくなる。 Update mozilla standard position に RFP を上げたところ「実装はしないが仕様については non-harmful」となりそうだ。 PFP: Cache Digest Issue #131 mozilla/standards-positions HTTP2 Push HTTP2 の仕様策定時に盛り込まれた新機能として、 Server Push があった。 これは、例えば RPC 的な用途で双方向性のある通信を可能にした。 Web においては、リクエストが来る前にレスポンスを返しキャッシュに入れ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
httpbin.org