Compression Dictionary Transport によるコンテンツ圧縮の最適化 | blog.jxck.io
Intro Compression Dictionary Transport は、圧縮に用いる辞書を HTTP 上で共有するプロトコルであり、2025 年 9 月に RFC 9842 として標準化された。 本サイトの対応を行ったので、方式の概要とデプロイ方法について解説する。 圧縮 圧縮は、基本的に「同じ値が出てきたら、前の値への参照に置き換える」という方式が中心となる。 例えば以下のような HTML を考えよう。 <link rel="author" href="https://jxck.io"> <link rel="canonical" href="https://blog.jxck.io"> 参照する位置とその長さを [n:m] と表すと以下のように置き換えられる。 <link rel="author" href="https://jxck.io"> [0:11]canonical
「阿部寛のホームページ」ついにHTTPS化 今はHTTPでも利用できるが……
同サイトはHTTPかつデータ量が軽いため、HTTPS非対応のレトロPCやゲーム機などの接続確認によく使われていた。HTTPS化でセキュリティは高まるが、レトロ機の接続確認に使えなくなることを残念がる声が出ている。 HTTPS化は、サイトをホスティングしているニフティサービス「LaCoocan」（ラクーカン）が、10月1日からHTTPSに対応したことに伴うもの。httpとhttpsのどちらでもアクセス可能な併用期間（2026年6月末まで）の後、従来の「http://」へのアクセスは、自動的に「https://」のページにリダイレクトする予定だ。 関連記事 「阿部寛のホームページ」ついにHTTPS化へ ニフティ「LaCoocan」HTTPS対応、「阿部寛でレトロPCの接続確認できなくなる」の声 「阿部寛のホームページ」をホスティングしている「LaCoocan」がHTTPS化。ということは……。
HTTP/1.1 must die: the desync endgame
Published: 06 August 2025 at 22:20 UTC Updated: 17 October 2025 at 10:13 UTC Abstract Upstream HTTP/1.1 is inherently insecure and regularly exposes millions of websites to hostile takeover. Six years of attempted mitigations have hidden the issue, but failed to fix it. This paper introduces several novel classes of HTTP desync attack capable of mass compromise of user credentials. These technique
Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
Intro IETF の httpbis で、Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛らわ
3PCA 8 日目: P3P | blog.jxck.io
Intro このエントリは、3rd Party Cookie Advent Calendar の 8 日目である。 3rd Party Cookie のカレンダー | Advent Calendar 2023 - Qiita https://qiita.com/advent-calendar/2023/3rd-party-cookie 今回は、Cookie2 が失敗した後に、別のアプローチでこの課題に挑んだ P3P を解説する。 P3P (Platform for Privacy Preferences) P3P は W3C では 1997 年頃から作業が始まり、2002 年に 1.0 が Recommendation になっている。 The Platform for Privacy Preferences 1.0 (P3P1.0) Specification (w3.org) https
Fetch APIは「PATCH」だけ大文字と小文字の挙動が異なる
const url = "https://fetch-api-normalization.deno.dev"; await fetch(url, { method: "PATCH" }); await fetch(url, { method: "patch" }); 実行すると、次のようなエラーを得るはずです。 PATCH を小文字で書いた際のエラーの一例 さて、どのような条件でこのエラーが発生するのでしょうか？これが意図されたものなのだとしたら、 GET や POST は大文字・小文字を無視してよくて PATCH は無視できない理由がなにかあるのでしょうか？以下でその理由を探ってみましょう。 いつエラーが発生するか このエラーは、 Fetch API を利用して外部の HTTP サーバーに対してリクエストを行う時に、 PATCH と書くべきところを patch と書いていると発生します。
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知
Multipart/form-dataの仕様メモ - Qiita
--hogehoge Content-Disposition: form-data; name="user_name" Content-Type: text/plain test --hogehoge Content-Disposition: form-data; name="email" sample@mail.com --hogehoge Content-Disposition: form-data; name="gender" male --hogehoge Content-Disposition: form-data; name="user_profile" filename="image.jpeg" Content-Type: image/jpeg \xff\xd8\.... --hogehoge-- リクエストヘッダ部 Content-Type: multipart/form-
Node.js fetch の内部の話 - from scratch
前置き この記事は リクルートエンジニアアドベントカレンダーの3日目の記事です。 Recruit Engineers Advent Calendar 2022 - Adventar ちなみにココで書いたやつを一部抜粋させていただいております（ネタ切れにより過去投稿を利用してしまっております。。。すいません。。。） www.codegrid.net fetch が Node v18 から試験的にサポートされた ブラウザでは数年前から採用されていた HTTP リクエストを行う関数の fetch が global 空間に関数として作成されました。使うだけなら特に何のフラグもいりません、その代わり使うと Experimental であることを知らせる Warnings が出ます。 // fetch.mjs const response = await fetch('https://api.gith
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
Application-Layer Protocol Negotiation - Wikipedia
Application-Layer Protocol Negotiation (ALPN) は、Transport Layer Security (TLS) の拡張の一つである。アプリケーション層でのプロトコルネゴシエーションに関する拡張であり、セキュア通信においてアプリケーション層がどの通信プロトコルを使用するのかを決定する際に、余分なラウンドトリップタイムの発生を避け、アプリケーション層のプロトコルに依らずにネゴシエーションを行うことを可能とする。ALPNは主にSPDYおよびHTTP/2で利用されている。 2021年現在では、ALPACAと命名されたTLSにおけるクロスプロトコル攻撃の対策の1つとして、それ以外のアプリケーションプロトコルでもALPNの利用が推奨されている[1]。
Cache-Control: must-understand ディレクティブとは何か | blog.jxck.io
Intro IETF が策定する HTTP の仕様が更新されようとしている。 ここには、Cache の仕様も含まれており、そのなかで must-understand という Cache-Control のディレクティブが追加されている。 このディレクティブが追加された経緯と仕様について解説する。 Cache と Status Code RFC 7234 では、新しいステータスコードを策定する際に、キャッシュに関して以下のように書かれている。 The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached if the response they occur in has explicit freshnes
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Connect
GitHub - Orange-OpenSource/hurl: Hurl, run and test HTTP requests with plain text.
GitHub - ttuegel/HttpServer.lean: A simple HTTP server in Lean
GitHub - WICG/compression-dictionary-transport
GitHub - xnbox/DeepfakeHTTP: DeepfakeHTTP is a web server that uses HTTP dumps as a source for responses.
GitHub - nodejs/llhttp: Port of http_parser to llparse
https://prestigemad.com/