Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog
Cookieの改訂版仕様 rfc6265bis について、その変更点をざっと眺めていく はじめに SameSite属性 Cookie名プレフィックス (Cookie Name Prefixes) __Secureプレフィックス __Hostプレフィックス 非セキュアなオリジンからの Secure属性の上書きを禁止 nameless cookieの許容 Cookie名、Cookie値の上限長の指定 Expires属性の年が2桁の場合の処理の指定 Max-Age/Expires の上限 その他 今回入らなかった機能 はじめに Cookieの仕様は『RFC 6265: HTTP State Management Mechanism』として標準化されています。 そのCookieの仕様の改訂版が『rfc6265bis』と呼ばれているもので、現在標準化作業が進められいています。"SameSite属性"
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont
Content-Disposition の filename という地雷。 (1個の観点で17個の脆弱性を見つけた話) - ぶるーたるごぶりん
English ver: https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714#file-lack_escape_content-disposition_filename-md TL;DR 1つのブラウザ、1つのプログラミング言語、15個の { Web Framework, HTTP Client ライブラリ, Email ライブラリ / Web Service 等} で脆弱性を見つけました。 見つけた脆弱性は、全て 1つの観点で発見した (多分 50-80 くらいのプロダクトの調査をした)。 RFC の記載では、（かなりわかりにくく）この問題に対する要件が記載されており、WHATWG > HTML Spec の方はしっかりと書かれているといった状況にある。 この問題は、 Content-Dispo
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
2021年 HTTPやQUICの最新動向振り返り - ASnoKaze blog
2021年について、プロトコル周りの動向を振り返っていきたいと思います。 今年は、個人的には次の2点がホットトピックと挙げられると思います。 QUICやHTTP/3を活用した応用系プロトコルの作業が進む プライバシー系の取り組みが活発化 それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...） HTTP関連 まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。 書いた記事はここらへん HTTPのバージョンについて、現在のまとめ HTTPセマンティクス仕様の改訂版 まとめ HTTP/2の改定版仕様の変更
QUICをゆっくり解説(1)：QUICが標準化されました | IIJ Engineers Blog
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
HTTPのバージョンについて、現在のまとめ - Qiita
はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。 バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。 意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。 バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H
HTTP 418ステータスコードが予約される - ASnoKaze blog
「418 I’m a tea pot」としてよく知られる 418 ステータスコードについて、IETF HTTPbis WGで議論になっていました。 「418 I’m a tea pot」はジョークRFCである「RFC2324 Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)」で定義されているステータスコードです。 ここで注意するのは、418はHTCPCPで定義されているステータスコードであり、HTTPで定義されているステータスコードではないという点です。 この議論については以前 Qiita で書いたとおりです。 qiita.com HTTPで418ステータスコードを予約 以前このブログで書いたとおり、HTTPセマンティクスに関して仕様の再改定が行われております asnokaze.hatenablog.com その後、3つの仕様に分割され
103 EarlyHints (RFC 8297) を送信するNginxモジュール書いた - ASnoKaze blog
これは、nginx Advent Calendar 2016の8日目の記事です。 103 Early Hints 先日の「Apache mod_http2 で 103 EarlyHints を試す」という記事でも書きましたが。軽くおさらい。 103 Early Hintsは、@kazuho氏によって提案されている仕様です。すでに Individual-Draftが提出されています。 https://tools.ietf.org/html/draft-kazuho-early-hints-status-code-00 IETF97でも仕様についての議論が行われており、その際のスライドを見ると分かりやすいかと思います。 https://www.ietf.org/proceedings/97/slides/slides-97-httpbis-sessb-early-hints-00.pdf ステ
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
URIに使ってよい文字の話 - RFC2396 と RFC3986 - 本当は怖いHPC
POSTするデータを、（プレビューのために）javascriptでGETアクセスするような処理を書いていてハマった話。 発端は、textareaに'（シングルクオートまたはアポストロフィー）が入ると、Railsがそこから先のパラメーターを無視しちゃうっていうこと。いろいろ調べた結果、以下のことがわかった（Railsのバージョンは2.0.2）。 URIを定義する２つのRFC URIの構文はRFCで定義されている。これには2つあって、従来のRFC2396（1998年発行）と、RFC3986（2005年発行）だ。 RFC3986によれば、 This document obsoletes [RFC2396], which merged "Uniform Resource Locators" [RFC1738] and "Relative Uniform Resource Locators" [RF
リアルタイム通信で利用されるプロトコルと手法 - tech.guitarrapc.cóm
NOTE: 本記事はすでに内容が古く、今読んでも役に立つ度合いはほぼないです。 本記事は、先日社内勉強会のために準備した、Webサービスのリアルタイム通信周りのまとめシリーズ の1つを転載して公開するものです。 まだまだわかっていないことが多いので、ぜひぜひ間違っている点などにご指摘いただければと思い公開します。 ぜひぜひ優しくマサカリをいただけると泣いて喜びます！ 目次 目次 はじめに プロトコルと手法 前世代のやり方であるComet について Polling 系 Streaming 系 過渡期といわれてる手法 将来有望といわれてる手法 Polling メリット デメリット 向いているシーン Long Polling (Comet) Polling の発展版 メリット デメリット LongPolling 自体は双方向通信ではない 接続が閉じられるケース 向いているシーン Server S
HTTP2 の RFC7540 が公開されました - Block Rockin’ Codes
Intro 今朝、ついにずっと策定作業が行われていた HTTP/1.1 の後継仕様である HTTP2 と、 関連仕様である HPACK が、 RFC として公開されました。 ついに HTTP2 RFC 7540 出た！！ #http2study / “rfc7540.txt” http://t.co/CuaVul98l3— Jxck (@Jxck_) 2015, 5月 14 それぞれ番号は 7540 と 7541 になります。 RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2) RFC7541 - HPACK: Header Compression for HTTP/2 ちなみに HTTP/2.0 ではなく HTTP/2 が正式名称です。(マイナーバージョンアップでの HTTP/2.1 などはありません) 二年半 HTTP2 の
RFC6265 によれば複数の Set-Cookie ヘッダーは推奨されない
session_regenerate_id() not replacing Set-Cookie headerSession Cookies faulty in IE8RFC6265 のかんたんな解説setcookiesession_regenerate_id() 関数を実行すると Set-Cookie ヘッダーが複数発行されるが、このことによって IE8 において Cookie が壊れたり、セッションのデータが消えたりする可能性があるそうだ。 Studing HTTP のサイトの「クッキーのためのHTTPヘッダ」の項目を見ると、Netscape 社の仕様では複数の Set-Cookie ヘッダーは許可されているが、2011年4月に発行された RFC6265 によれば、1つのサーバーで複数の Set-Cookie ヘッダーを発行すべきではないとされている。setcookie 関数のマニュア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Status 425 HTTP/Tokyo
HTTP (httpbis)
DNS privacy of transport layer
%u-encoding
https://www.rfc-editor.org/rfc/rfc7540.txt