Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/content/iss
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
女性も参加しやすい（でも女性限定ではない）Ruby勉強会「TokyoGirls.rb Meetup vol.2」。Webプログラマーの塩井美咲氏が、最近気になっているライブラリ「Rack」について学ぶため、自ら「TraceHeader」というRackミドルウェアを作りました。その実装と有効性の検証について紹介します。講演資料はこちら 最近気になるライブラリ「Rack」でミドルウェアを作った話 塩井美咲氏（以下、塩井）：すみません、なんの脈絡もなくRackの話をしようとしています。他意はありません。 （会場笑） 先にお伝えしておきたいことがあって、今回、発表資料の枚数がだいたい60枚ぐらいあります。私はもともとすごく早口なんですけど、今日はちょっと自分の限界に挑戦してみたいと思っています（笑）。よろしくお願いします。詳細な資料についてはのちほど共有します。 私はしおいといいます。普段はこの辺
安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1950日前 メールで報告済み 編集 This artblished on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICのAckとロスリカバリについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze
HRSとは 2018年の7月に、「XSS due to the header Transfer-Encoding: chunked」というタイトルで本語の情報源としては徳丸さんによるこちらの記事が参考になります。 この脆弱性は下記のように、HTTPリクエストヘッダ内に一見矛盾していたり、明確でない内容が含まれている場合の挙動についてのものでした。 Transfer-Encoding: chunked Content-Length: 25 この問題はHTTPリクエストスマグリング(HTTP Request Smuggling、以下HRS)と呼ばれていて、今から13年前、2005年に知られたものです。筆者は今から11年前に「ウェブアプリケーションセキュリティ」という本(通称:金床本)
まとめ サーバ側のHTTPレスポンスヘッダに Cache-Control: no-transfChromeにおける帯域圧縮時のEXIF欠損について、という記事でモバイル版Chromeの「データ使用量を節約」機能を利用している場合には画像のEXIF情報を利用するWebアプリの動作に支障があるという話を書きました。 自分の場合にはEXIFデータのOrientation（画像の回転方向）を利用したアプリにおいて、モバイル版Chromeのデータ使用量節約時に画像の回転方法がおかしくなる不具合がありました。 この件について、2014年11月に開催されたハイパフォーマンス ブラウザネットワーキング ミートアップにてGoogleのIlya Grigorikさんに直接質問できる機会があり聞いてみたところ、HT
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「fHTML の関係を明確化(thanx koichik) 2014/03/29: HT
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが frame または iframe で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
Preface This post contains details about a coding pitfall I recently identified in many iOS applications, which we call HTTP Request Hijacking (HRH). Adi Sharablem, its ramifications, and some fix suggestions to developers later today at RSA Europe (14:10 – 15:00 | Room: G102). If you are an iOS developer in a hurry to fi
■ HTTPリクエストの圧縮をサポートする HTTPクライアントから大きなデータをPOSTするときに圧縮可能ならそうして欲しい場合があって(もちろんブラウザはそんなことしてくれないので専用クライアントを使う前提)、サーバアプリは圧縮・未圧縮の状況にかかわりなく書きたいので、その部分だけRackミドルウェアにしてみた。ちなみにリクエストではなくてレスポンスなら普通の話なので何も考えずにRack::Deflaterを使えば良い。 最初、Rackでリクエストのbodyを操作する方法がわからなくてTwitterでつぶやいたら@moroが教えてくれたので解決。いつもいつも助かります(^^; こんな感じで使える: require 'rack/request_decompressor' use Rack::RequestDecompressor クライアントはContent-Encodingヘッダを追加
■ HTTPでHashやArrayを送る手法に仕様は存在しない……の? jQueryでこんなふうに書くと: $.post('/', { hash: { foo: 'hoge', bar: 'fuga'}, array: ['baz', 'piyo'] }); サーバ側でこんなふうに受け取れて(これはSinatra): post '/' do params.each do |key, val| puts "#{key}: #{val} as #{val.class}" end end ちゃんとHashやArrayとしてアクセスできる: hash: {"foo"=>"hoge", "bar"=>"fuga"} as Hash array: ["baz", "piyo"] as Array ああこりゃ便利だね、で済ましてもいいんだけど、HTTP POSTの中身なんてただのバイト列なんだから型の情
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編） 大津 繁樹（株式会社インターネットイニシアティブ） 前回のHTTP/2.0接続試験参加（標準化作業編）に続き、今回お届けするのは技術解説編。既存のSPDYでは使われていないようなHTTP/2.0で新しく議論された技術仕様、相互接続試験のポイントとなった技術要素などを中心にレポートします。 HTTP/2.0相互接続試験で重要な技術要素の概要 SPDYを技術ベースにして検討されているHTTP/2.0仕様は、現在60ページ弱の分量です。従来のHTTP/1.1と異なりバイナリー通信を基本とするため、その多くはフレームフォーマットの説明に割かれています。HTTP/2.0で新しく導入されたヘッダ圧縮の仕様(HPACK)は、現在HTTP/2.0の仕様と分離されていますが、将来的には統合することも検討されています。 HTTP
ひさびさの単著となる『HTTPの教科書』が2013年5月24日に発売になります。 内容はタイトルの通り、Webに関わる全ての人に捧げるHTTPを学ぶための教科書です。基礎を学びたい初心者の方から、机の上に置いてリファレンス的に使いたい方までを対象としています。 HTTPの教科書発売元: 翔泳社価格: ￥ 2,730発売日: 2013/05/25posted with Socialtunes at 2013/05/21 HTTP関連の書籍は『今夜わかるHTTP (本を2004年に出しています。その頃からHTTP/1.1が主流であるというのは、今でも変わりませんがそれを取り巻く環境というのは変わりつつあります。 HTTPを学ぶ上での要点がわかりやすく、そして読みやすくなっております。前作のリニューアルっぽく感じるかと思いますが、9割以上は書き直しや追記しており
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
