普段**"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ではストリーム上のフレームで送信
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
Cross-Origin-Opener-Policy (COOP)は現在、ChromeやFirefoxで実装が進められている機能です。 Chrome: Implement Cross-Origin-Opener-Policy firefox: Implement Cross-Origin-Opener-Policy 仕様としては、whatwgで長らく議論がされており、おそらく仕様に入るでしょう Restricting cross-origin WindowProxy access (Cross-Origin-Opener-Policy) · Issue #3740 · whatwg/html · GitHub Cross-Origin-Opener-Policy: provide a clearer spec. · Issue #4580 · whatwg/html · GitHub 面白
脳内キャッシュが全然足りてません✧（・ㅂ・）و こんにちは。クイックSREチームのみっちーです。 今回は、弊社のWebサイトにブラウザキャッシュ設定を実装したときに悩んだ箇所を簡単にまとめてみました。 今回の記事は、こんな人向けです。 そもそも「ブラウザキャッシュ」ってなんだろう？ ブラウザキャッシュは知ってるけど、設定方法がよくわからない。 とりあえず「Webサイトの表示を速くしたい」と思っている。 目次 1. キャッシュとは 2. ブラウザキャッシュの基礎 3. ブラウザキャッシュの設定方法 4. ブラウザキャッシュ設定時のCDNの挙動 1. キャッシュとは 最初に、キャッシュについての説明をします。 キャッシュ プログラム処理結果をディスクやメモリ上に保存し、次回以降に同じ要求が来た場合には計算を省略することで、応答速度の向上を図る仕組みです。 キャッシュと一括りにしても、大きく分け
Intro リファラはリンクなどでページを遷移する際に、遷移元の URL をリクエストの Referer ヘッダに載せる仕様である。 この付与はブラウザが自動で行うため、場合によっては非公開として扱っている URL が意図せず漏れることがある。 この挙動を制御することができる、Referrer-Policy ヘッダについて解説する。 Referer or Referrer 本来の英語としては RefeRRer が正しいが、HTTP Header ではスペルミスした RefeRer が互換性を保つためそのまま使われている。 しかし、新しく定義された Referrer-Policy は、正しいスペルが採用されている。 Referer ヘッダ 例えば https://example.com/index.html に貼られたリンクから https://blog.jxck.io に遷移する場合を考え
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などからはセマンティクスの仕様を参照でき、仕様としてより整理された形となります。
ブラウザキャッシュとレスポンスヘッダの関係を調べてみた。 調べたブラウザ Firefox 3.5 IE 6 Opera 9.64 Google Chrome 2.0.172.33 レスポンスヘッダ Expires Last-Modified Cache-Control Pragma 結論 以下のレスポンスヘッダを返す。 Expires、Last-Modified、Cache-Control、Pragma 以外のヘッダについては任意。 キャッシュさせたい場合 Cache-Control: private, max-age=有効期間の秒数 条件付GETをさせたい場合 Expires: 過去の時刻 Last-Modified: 過去の時刻 キャッシュさせたくない場合 Cache-Control: no-cache 調査方法 それぞれのブラウザで以下のレスポンスヘッダを返すページを読み込んだときに
欲しいものリストから送って頂き、読んでいた。ようやく読了。 Webを支えるプロトコルであるHTTPについて、メソッドとはというところから始まり、HTTP/2に関する話題まで、幅広く網羅している。 主にクライアント側の視点で書かれている。 O'Reilly Japan - Real World HTTP Go言語でサンプルを実装したり、curlを使って実際にどんなレスポンスが返ってくるか試したりしながら、進んでいく。 Goでのサンプルは実際に写経しながら進めた。その成果が下記のリポジトリ。 全部やったわけではないが、TLS、チャンク、プロトコルアップグレード、OAuth2などを実装できたのはよかった。 curlについても少しは使えるようになった。どんなレスポンスが返ってくるのか見れるので、覚えると面白いと思う。 Webに関する基本的な知識を広げたくて、本書を読んだ。 JavaScriptでプ
opening connection to www.google.co.jp... opened <- "GET / HTTP/1.1\r\nConnection: close\r\nHost: www.google.co.jp\r\nAccept: */*\r\n\r\n" -> "HTTP/1.1 200 OK\r\n" -> "Date: Sun, 30 Sep 2012 01:49:21 GMT\r\n" -> "Expires: -1\r\n" -> "Cache-Control: private, max-age=0\r\n" -> "Content-Type: text/html; charset=Shift_JIS\r\n" -> "Set-Cookie: PREF=ID=be9181a7dc77ebf4:FF=0:TM=1348969761:LM=1348969761:S
gistfile1.md 先輩に学ぶ HTTP Status Code 超雑にまとめました。修正してください。 登場人物 アプリケーション先輩: いつも忙しい。横に広がるのが得意(デブじゃない)。 後輩: 頼んでばっかしで役に立たない。 サーバー先輩: アプリケーション先輩と仲がいい。Unix Socket でつながるくらい仲良し。 プロクシ先輩: アプリケーション先輩とかサーバー先輩と後輩の間を取り持って代わりに伝えたりしてくれる。たまに勝手にレスポンスを書き換える。 1xx 系 100 Continue 後輩「あ、先輩！お願いが！」 アプリケーション先輩「おー、聞いてやる。詳しく話せ」 101 Switching Protocols 後輩「せんぱーい、お願いなんですけどー」 アプリケーション先輩「ちょっと待て、お前 HTTP 1.0 で喋るな、 HTTP 1.1 か TLS 1.0 で
Rubyには標準でnet/httpが入っていますが、これはちょっと低レイヤ寄りで使いづらいので、使いやすくしたHTTPクライアントライブラリが多数あります。 ありすぎてどれを選んでいいか調べていたところ、HTTPClientの作者さんによる比較スライドを見つけました： http://www.slideshare.net/HiroshiNakamura/rubyhttp-clients-comparison まとめると httpartyとrest-clientが2大人気（ソースはGemのダウンロード数とgithubのスター数。faradayはラッパーなので別枠） この2つで出来ることはほとんど同じ 違いはDigest認証（httppartyは可）、multipart post（rest-clientは可）くらい どちらもKeep-Aliveに対応していない HTTPClientはDigest
This document summarizes and compares Ruby HTTP client libraries. It discusses the sync and async APIs of 16 libraries including Net::HTTP, HTTPClient, and Faraday. It covers their compatibility, supported features like keep-alive connections, and performance based on benchmarks. The document recommends libraries based on priorities like speed, HTML handling, API clients, and SSL support. It encou
@egapoolです。今回初めてISUCON7に参加させていただきました。（チーム名：元pyns） 当日やったこととこかはこちらにまとめています。 ISUCON7に参加して予選突破しませんでした。 – そろそろちゃんとやります 今回のお題の一つ目の壁は、いかに画像ファイル（アバターアイコン）をキャッシュさせてサーバーからデータを返さないようにするかでした。 8時間の大部分をこの対応に費やしましたが解決は出来ませんでした。 原因はきっちり304を返すための基礎知識が足りていなかったことです。 ですのでこれを機に勉強しなおしてみました。 304 (Not Modified) 大前提ですが、304ステータスコードは キャッシュの有効無効の確認付きリクエストに対して、有効である場合に返すステータスコード です。 この場合サーバーはリソースデータ(ペイロード)を送信しません。 すなわち，サーバは、［
概要 Webフロントのパフォーマンス診断 - Carpe Diem で指摘されたブラウザキャッシュの対応をするため調べてみました。 大きく分けて強いキャッシュと弱いキャッシュの２種類のキャッシュがあります。 強いキャッシュ ブラウザ側でリソースを保持し、期限が切れるまでサーバにHTTPリクエストを発行しません。 なので一度ブラウザにキャッシュされるとサーバ側からハンドリングすることができなくなります。 これを設定する方法は Cache-Controlヘッダー Expiresヘッダー の２つがあります。 Cache-Control: max-age サーバからのレスポンスで以下のようにCache-Controlヘッダーを付けます。 Cache-Control: max-age=3600 このヘッダーが付いたリソースはブラウザ上では強いキャッシュとして残ります。 max-ageは秒数なので、こ
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
概要 サーバが301リダイレクトを返してきた場合、ブラウザはリダイレクト先のURLをキャッシュして、次に元のURLにアクセスした際には直接リダイレクト先のURLにアクセスする。 元URLにアクセスしないので、現在はコンテンツがあっても考慮されない！ この現象自体を知らないと原因究明が出来なくてハマる。っていうかハマった。 例 「http://example.com/hoge」にアクセス。 301が返ってきて「http://example.com/piyo」にリダイレクト。 「http://example.com/hoge」にアクセス。 「http://example.com/hoge」にアクセスすることなく「http://example.com/piyo」が表示。 解決方法 この状態になってしまったらブラウザのキャッシュ削除。 古いIEだとキャッシュを削除してもリダイレクトの設定は残るらし
Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload
このページは、 Web プラットフォーム関連の様々な仕様の日本語訳の一覧と， それらの日本語訳に共通な事項についての説明です。 これらの翻訳の正確性は保証されません。 これらの仕様の公式な文書は英語版であり、 日本語訳は公式なものではありません。 誤訳が無いことは保証されません。 ［ 当の仕様の策定者たちが想定している／当の仕様に期待されている ］意味論を完全かつ正確に反映することは保証されません。 翻訳なので、 語彙レベルで原文と正確に一致する意味を表すことは決してありません。 日本語は自然言語なので、 誰がいつどこで読んでも同じ解釈になることは保証されません。 ）（ 実際に誤訳が見つかることも時折あります。 それらについては見つかり次第修正され， 加えて用語の対訳や言い回しなども時折修正されるので、 これらの翻訳が「完成」する日は永遠に来ません。 逆に原文仕様が誤っていることもあり、
ほとんどのブラウザで、通常リロードは Cache-Control: max-age=0、スーパーリロードで Cache-Control: no-cache がリクエストヘッダとして送られてくるみたいなのですが、実際の挙動はともかく意味の違いがよくわかりませんでした。 RFC7234 によると max-age は The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く