タグ

httpに関するtkawaのブックマーク (42)

  • HTTPキャッシュを使いこなして、Webアプリを快適に(1) | IIJ Engineers Blog

    セキュリティセキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい!」とフラグを...。 cats_dogs開発者のヒラマツです。 HTTPキャッシュをうまく使う技術、HTTPキャッシュ制御を解説します。 HTTPキャッシュは、WebアプリなどのWebサービスの通信を最適化する技術です。 HTTPのCache-Controlヘッダーの使い方の話でもあります。 HTTPキャッシュ制御と言っても、Cache-Controlヘッダーの設定だけなので、簡単そうに思えます。 しかし、正しく設定しようとすると、案外、複雑で苦労します。 また、理解なしに使うと、情報漏えいの問題を起こす可能性もあり、適当に設定するのは危険です。 ぜひ、この文章を読んで、理解した上で、Catch-Controlを設定してください。 cats_dogsの仕様を書くときに、

    HTTPキャッシュを使いこなして、Webアプリを快適に(1) | IIJ Engineers Blog
    tkawa
    tkawa 2023/05/29
  • モダンWebにおけるキャッシングのための新HTTP標準 | POSTD

    一般ユーザー向けの大規模なWebサイトや、モダンWeb上で動作するWebアプリケーションを運営する場合、CDNなどのキャッシングサービスによって静的コンテンツをキャッシュすることが極めて重要です。 しかしこうしたサービスは、非常に複雑で分かりにくいものです。 幸い、IETF(Internet Engineering Task Force)のHTTPワーキンググループがこの状況を改善すべく、HTTPの新標準策定に取り組んでいます。 最近、同ワーキンググループでは、キャッシングのデバッグとキャッシュ設定の管理を容易にすることを目的とした、HTTPヘッダに関する2つの新標準案の発表に向けて活発な動きがありました。 このことが何を意味し、どのように機能するのか、そしてWeb制作に携わる開発者全てがなぜ注目すべきなのかについて見ていきます。 新標準 この記事で取り上げる標準案は以下の2つです。 Ca

    モダンWebにおけるキャッシングのための新HTTP標準 | POSTD
    tkawa
    tkawa 2022/09/01
  • 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

    HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
    tkawa
    tkawa 2022/06/16
  • Web 技術解体新書「第二章 Cache 解体新書」リリース

    Web 技術解体新書「第二章 Cache 解体新書」リリース Intro 「Web 技術解体新書(Web Anatomia)」の第二章として「Cache 解体新書(Cache Anatomia)」をリリースしました。 これで予定している八章のうち二章が終わりました。 第一章: Origin 解体新書 第二章: Cache 解体新書 Cache 解体新書 以下の Response Header Field がどういう意味を持つか正確に説明できますか? おそらく多くの Web 開発者が一度は見たことがあり、これを「1 時間キャッシュする」という意味で指定している人もおおいでしょう。 では、どこから 1 時間で、 1 時間経ったらなにが起こるのか、これが Response でなく Request に付与されたらどう変わるのか、きちんと把握できていますか? そもそも、一般的にキャッシュ機構における

    Web 技術解体新書「第二章 Cache 解体新書」リリース
    tkawa
    tkawa 2022/06/10
    これは注目
  • 新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog

    新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等

    新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
    tkawa
    tkawa 2021/11/11
    既存のProxyが対応するかどうかは別問題
  • ChromeとFastlyのEarly Hintsの効果計測に貢献する — HACK The Nikkei

    この記事は Nikkei Advent Calendar 2020 20 日目の記事です。 日経電子版 Web チームの阿部です。今回は HTTP/2 の目玉機能の 1 つであった Server Push の事実上の終焉と、現在 Chrome チームや Fastly 社が実験中の 103 Early Hints について、日経電子版 Web での取り組みを紹介させていただきます。 HTTP/2 Server Push HTTP/2 Server Pushは HTTP/2 で策定された、一言で言ってしまうと「必要なリソースがリクエストされる前にサーバーからクライアントに送ってしまおう」という技術です。 これによりクライアントがリクエストするリソースを先回りしてサーバーが送ることで、必要なリソースが揃うまでにかかる時間を短縮できるため、パフォーマンスの向上が期待されていました。 Server

    ChromeとFastlyのEarly Hintsの効果計測に貢献する — HACK The Nikkei
    tkawa
    tkawa 2020/12/21
  • POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog

    はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする

    POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
    tkawa
    tkawa 2020/11/19
    冪等が目的なら現状でも条件付きPUTで実装できることが多いので、まずそれを検討したほうが良い。リクエストIDなら標準化しても良いと思う
  • Service worker caching and HTTP caching  |  Articles  |  web.dev

    While service workers and PWAs are becoming standards of modern web applications, resource caching has become more complex than ever. This article covers the big picture of browser caching, including: The use cases of and differences between service worker caching and HTTP caching. The pros and cons of different service worker caching expiry strategies compared to regular HTTP caching strategies.

    tkawa
    tkawa 2020/08/24
  • fetch() upload streaming は WebSocket の代替になるのか。Fetch を使ってカメラから取得した映像をストリーミングで送信する - 別にしんどくないブログ

    Fetch Upload Streaming が Chrome 85 から Origin Trial で使えるようになりました。 何ができるかというと ReadableStream を fetch() の body に渡すことができるようになります。 getUserMedia でカメラから取得した映像をブラウザからストリーミング送信したいときに使えそうと考えたので、今回試してみました。 blog.chromium.org TL;DR fetch() で Stream のデータを送れるようになった WebSocket を使わずに映像などのデータをストリーミング送信できる 以下のコードがこの記事の内容 https://github.com/shisama/sample-streaming-video-with-fetch/blob/master/public/script.js Readabl

    fetch() upload streaming は WebSocket の代替になるのか。Fetch を使ってカメラから取得した映像をストリーミングで送信する - 別にしんどくないブログ
    tkawa
    tkawa 2020/07/29
    HTTP/2限定
  • Real World HTTP 第2版はなぜ1.5倍になったのか | フューチャー技術ブログ

    Real World HTTP 第2版が2020/04/20出版されました。第2版が出版されるというのは、初版をみなさまが買ってくださったおかげです。どうもありがとうございます。紙媒体は先行入荷する書店さんではすでに入っているようです。オライリーのウェブサイトから電子版を購入することもできます。 4/17新刊『Real World HTTP 第2版 歴史とコードに学ぶインターネットとウェブ技術』オライリー(978-4-87311-903-8)渋川よしき 著◆「オライリー」棚にて展開中!Webテクノロジーの基礎となるHTTPの仕様を網羅的に学べる学習書が内容を充実させて改訂! pic.twitter.com/k86zXGaHe9 — 書泉ブックタワーコンピュータ書 (@shosen_bt_pc) April 17, 2020 Real World HTTPの初版の執筆時にも、ネットで見かける

    Real World HTTP 第2版はなぜ1.5倍になったのか | フューチャー技術ブログ
  • Status 425 HTTP/Tokyo

    2. @flano_yuki - プロトコルの人 (@flano_yuki) - 標準化とかに興味がある - HTTP, HTTP/3, QUIC, TLS WebTransport, Masque, WebPackaging… - Blog: ASnoKaze - https://asnokaze.hatenablog.com/

    Status 425 HTTP/Tokyo
    tkawa
    tkawa 2020/01/18
  • Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs

    January 02, 2020 Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs When building web services, a common wisdom is to try to reduce the number of HTTP requests to improve performance. There are a variety of benefits to this, including less total bytes being sent, but the predominant reason is that traditionally browsers will only make 6 HTTP requests in parallel for a sin

    Performance testing HTTP/1.1 vs HTTP/2 vs HTTP/2 + Server Push for REST APIs
    tkawa
    tkawa 2020/01/12
  • 責任ある開発者のためのHTTPヘッダー | Yakst

    安全で、誰にも手頃でアクセスしやすく、ユーザーを尊重したWebを作るためのHTTPヘッダーのプラクティス [UI/UX]原文 HTTP headers for the responsible developer - Twilio (English) 原文著者 Stefan Judis 原文公開日 2019-04-23 翻訳依頼者 翻訳者 meiq 翻訳レビュアー doublemarket msh5 原著者への翻訳報告 1950日前 メールで報告済み 編集 This article was originally published on twilio.com, and translated with the permission of Twilio and the author. 当記事の原文はtwilio.comにて公開されたものであり、Twilio社および原著者の許可を得て翻訳しています

    tkawa
    tkawa 2019/06/14
  • HTTP3Study に行ってきたメモ #http3study - console.lealog();

    HTTP3Study (new) - connpass まったく詳しくない分野で脳内補完が効かないのと英語なのとで、まったく自信のないメモに仕上がりました。 間違ってたらむしろ教えてほしいです! HTTP/3 (英語セッション) from Mark Nottingham はじめに ここは最初にWGのMtgをした部屋なので不思議な感じ 仕様の解説というより、経緯とか周辺について話すよ 仕様について議論してるけど、全ての実装・ユースケースを把握してるわけではない いままで HTTP/0.9 今でも使われてるかも `GET /`だけみたいにシンプル HTTP/1.0 いくつかヘッダがついたりした まだシンプルだったあの頃 1993年とかそのへんからユースケースが混んできた なのでみんな拡張をはじめた UAとかHostとか HTTP/1.1 Transfer-Encoding: chunk gzi

    HTTP3Study に行ってきたメモ #http3study - console.lealog();
    tkawa
    tkawa 2019/02/02
  • QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記

    OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って

    QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
    tkawa
    tkawa 2019/02/01
  • 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 においては、リクエストが来る前にレスポンスを返しキャッシュに入れ

    Cache Digest と HTTP2 Server Push の現状 | blog.jxck.io
    tkawa
    tkawa 2019/01/20
  • 日本語 | HTTP/3 explained

    このの試みは2018年3月に始まりました。HTTP/3 と、その根幹のプロトコルである QUIC を文書化することがその目的です (なぜ、どのようにして動作するのか、プロトコルの詳細、その実装など)。 このは完全に無償で提供され、援助したいと考えるすべての人を巻き込んだ共同作品です。

    日本語 | HTTP/3 explained
    tkawa
    tkawa 2018/12/10
  • 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 圧縮アルゴリズムは、簡単に言えば頻出する一致部分

    Brotli を用いた静的コンテンツ配信最適化と Accept-Encoding: br について | blog.jxck.io
    tkawa
    tkawa 2018/05/29
  • The headers we don't want

    Let’s look at the unnecessary headers and see why we don’t need them, and what we can do about it. Vanity (server, x-powered-by, via) You may be very proud of your choice of server software, but most people couldn’t care less. At worst, these headers might be divulging sensitive data that makes your site easier to attack. Server: apache X-Powered-By: PHP/5.1.1 Via: 1.1 varnish, 1.1 squid RFC7231 a

    The headers we don't want
    tkawa
    tkawa 2018/05/16
  • Railsのルーティングで多数のHTTP OPTIONSをうまく扱う方法(翻訳)|TechRacho by BPS株式会社

    概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Clean HTTP OPTIONS handling in Rails | by Filippos Vasilakis | Kollegorna 原文公開日: 2017/11/20 著者: Filippos Vasilakis 画像は元記事からの引用です。 初版公開: 2017/12/25 更新: 2023/06/20 編集部注 記事のようにルーティングでアスタリスク*を使うと、rails routesの出力ですべてのURLの網羅が保証されなくなります(*の部分は展開なしで出力されます)。大規模案件などでルーティングの見落としなどにつながる可能性もあるため、採用の際は今後の改修上のリスクなどの考慮が必要と考えられます。 RailsAPIセットアップ周りがいかに強力であっても、OPTIONSやHEADといった他のHTTPメソッ

    Railsのルーティングで多数のHTTP OPTIONSをうまく扱う方法(翻訳)|TechRacho by BPS株式会社
    tkawa
    tkawa 2018/01/16
    発想は面白いのだけれど、OPTIONSはキャッシュ不可などの問題があるため代わりにLinkヘッダなどを使ったほうが良い→ https://www.mnot.net/blog/2012/10/29/NO_OPTIONS