You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
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 という「相対的な役割」で話をすると、紛らわ
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
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 と書いていると発生します。
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知
はじめに MIME-TYPEの中でも複雑かつ、あまり普段は意識しないのが、multipart/form-data。HTMLでformを作り、formタグの属性でenctype="multipart/form-data"を指定することで送ることができる。プリミティブなHTTPクライアントを使って、自前でmultipart/form-dataを投げようとして、いくつかハマったので、改めてRFCの仕様を読んだのでメモ。 サンプル リクエストヘッダ --hogehoge Content-Disposition: form-data; name="user_name" Content-Type: text/plain test --hogehoge Content-Disposition: form-data; name="email" sample@mail.com --hogehoge Cont
前置き この記事は リクルートエンジニアアドベントカレンダーの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
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 (ALPN) は、Transport Layer Security (TLS) の拡張の一つである。アプリケーション層でのプロトコルネゴシエーションに関する拡張であり、セキュア通信においてアプリケーション層がどの通信プロトコルを使用するのかを決定する際に、余分なラウンドトリップタイムの発生を避け、アプリケーション層のプロトコルに依らずにネゴシエーションを行うことを可能とする。ALPNは主にSPDYおよびHTTP/2で利用されている。 2021年現在では、ALPACAと命名されたTLSにおけるクロスプロトコル攻撃の対策の1つとして、それ以外のアプリケーションプロトコルでもALPNの利用が推奨されている[1]。
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
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
HTTPガイドHTTP の概要HTTP の進化典型的な HTTP セッションHTTP メッセージMIME タイプ(IANA メディア種別)HTTP の圧縮Compression Dictionary Transport Experimental HTTP キャッシュHTTP 認証HTTP Cookie の使用HTTP のリダイレクトHTTP 条件付きリクエストHTTP 範囲リクエストコンテンツネゴシエーションHTTP/1.x のコネクション管理プロトコルのアップグレードの仕組みプロキシーサーバーとトンネリングHTTP クライアントヒントHTTP セキュリティ実践的なセキュリティ実装ガイドHTTP ObservatoryPermissions Policy Experimental コンテンツセキュリティポリシー (CSP)Cross-Origin Resource Policy (CORP
Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く