なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio
IETFによるHTTP/3の標準化プロセスが完了、「RFC 9114」に
IETFのQUICワーキンググループはHTTP/3の標準化プロセスを完了し、「RFC 9114」として発表しました。 HTTP/3 has been published as an RFC. https://t.co/jdsUHy9FKD — IETF QUIC WG (@quicwg) June 6, 2022 HTTPはWorld Wide Webを開発したティム・バーナーズ＝リーによって1990年に最初のバージョンが作られました。 その後、1996年にHTTP/1.0がIETFによってRFC化され、1999年にHTTP/1.1へアップデート。2015年2月には初めてのメジャーバージョンアップとなるHTTP/2がRFCとなりました。HTTP/3は7年ぶりのメジャーアップデートと言えます。 HTTP/3では高速な通信を実現するために、HTTPのトランスポート層を従来のTCPからQUICに
強いキャッシュ 弱いキャッシュとはなにか – cat /dev/random > /dev/null &
先日とらのあなラボ様の勉強会に参加していたところ「強いキャッシュ」「弱いキャッシュ」とキーワードが出てきました。 初めて聞く表現だったので質問したところやはり知らない定義だったため、少し調べてまとめてみたものです。 なお、強いキャッシュ・弱いキャッシュという説明を否定するものではなく、補完したいと考えています。 強いキャッシュ・弱いキャッシュの定義 ネット上を調べると日本語・中国語・英語で説明が出てきますが、調べた限りでは強いキャッシュ・弱いキャッシュの初出はWebフロントエンド ハイパフォーマンスで、定義は以下の通りです。 ExpiresヘッダーとCache-Controlヘッダーでは強いキャッシュを設定できます。 ETagヘッダーとLast-Modifiedヘッダーでは弱いキャッシュを設定できます。 Webフロントエンド ハイパフォーマンス p124 こちらの文書の前後に詳しい定義があ
ソースが空の謎のサイト「therickroll.com」 - Qiita
というサイトがあります。アクセスすると… 4/22追記： ChromeやEdgeだと何も表示されないようです。Firefoxを使用して下さい。 RickrollされてYouTubeにリダイレクトされるだけのサイトですが、実はこのサイト… なぜかレスポンスが空っぽです。 どうやらこのサイトは謎の力によってRickrollされているようです。 いかがだったでしょうか？謎の力、すごいですね。ありがとうございました。 種明かし ごめんなさい。 というわけでまともに書いていきたいと思います。 とりあえずhttps://therickroll.com/をもっと調べてみます。 （repl.itでホストされているのか…） 怪しいヘッダがいくつかありますね。 HTTP/1.1 200 OK CF-Cache-Status: DYNAMIC CF-RAY: 6ff556570fa88391-KIX Conne
max-age=0って何のメリットがあるの？
こんにちは。株式会社プラハCEOの松原です。 先日プラハチャレンジの参加者に「Cache-Control: max-age=0って何の意味があるの？毎回サーバーに問い合わせてたらキャッシュのメリットがないのでは？」と聞かれたので、それについて思ったことをまとめてみます TL:DR; どでかいレスポンスを毎回取得しなくて済む 内容が更新されたらすぐ知りたいけどめっちゃ重いから毎回受け取りたくないリソースに向いてる 説明 例えば、内容が変わったらすぐに反映させたいどでかい画像を返してくるサーバーに複数回アクセスするケースを考えてみます レスポンスにmax-age=0が指定されている場合、2回目以降も毎回サーバーまでは問い合わせるけど変更がなければレスポンスのボディにはどでかい画像は含まれていない状態で返ってきます。空っぽです。1回目のレスポンス（どでかい画像）をクライアントがキャッシュしている
新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
HTTPステータスコード百人一首 - 揚げピーナッツ - BOOTH
40種類のHTTPステータスコードが記載された取り札、読み札で構成されています。 遊び方は百人一首と同じです。 取り札には下の句として「404 Not Found」というように、HTTPステータスコードと英語名が書かれています。 読み札には上の句としてそのHTTPステータスコードの説明文、そして下の句が記載されます。 ----- リクエストされたリソースが見つかりませんでした。 存在しないページを表示しようとした時などに返されます。 Not Found 404 ----- このような感じです。 読み手は上から読んでいき、取り手はどのHTTPステータスコードか判った時点で該当する取り札を探し取ります。 説明文のところは似ている出だしが多く、慣れてくるとちょっとした差異が発生した時点で判断できるようになります。 百人一首は名の通り札が100種類ですが、このゲームは40種類なので数回やると個人差
こんばんは、X-Forwarded-For警察です - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチームの三浦 (@yuba)です。普段はサービス開発やバッチ処理開発をメインにやっておりますが、チームSREに参加してからはこれに加えて担当サービスのインフラ管理、そしてクラウド移行に携わっています。 今回はそのクラウド移行の話そのものではないのですが、それと必ず絡んでくるインフラ設定に関してです。 アクセス元IPアドレスを知りたい Webアプリケーションがアクセス元IPアドレスを知りたいシーンというのは、大まかに二つかと思います。ログ記録用と、アクセス制限ですね。どちらもアプリケーションそのものではなく手前のWebサーバの責務のようにも思えますが、そうとも言い切れません。動作ログ、特に異常リクエストをはじいた記録なんかにセットでIPアドレスを付けたいとなるとアプリケーション要件ですし、アクセス制限についてもマルチテナントサービ
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
HTTP/2が速いという幻想 - Webパフォーマンスについて
難しい話じゃないです。 皆さん、ご自分でChrome Developer Toolで簡単に確認できますから、やってみて下さい。 このブログでも、過去に統計分析をした結果は掲載したんですが、「盲信」はそうそう簡単には消えないようでして… takehora.hatenadiary.jp takehora.hatenadiary.jp 以下の図は、Chrome 63.0.3239.108での結果です。 CDNにFastlyでもAWS CloudFrontでも、どのCDNを使って実験して頂いても結構です。 CDNを使わずに、Webサーバ単体でも結構です。 同様の結果になります。 どちらもHTTPS通信です。 どちらも同じオリジン、同じファイル構成です。 HTTP/1.1は、Keep-Alive設定が入っています。 HTTP/1.1での配信 … Load Event 70ms HTTP/2での配信
HTTP/0.9は今でも使われている? - Qiita
※本稿はピクシブ株式会社 Advent Calendar 2017 の9日目の記事です。 さる技術書典で書く原稿のためにHTTPについて調べていたら、こんな記述を見つけた。 HTTP/0.9 は、1991年以来使われている HTTP の最初の版です。 極めて単純ですが、あまりに低機能なので、現在ではほとんど使われなくなっています。 それでも HTTP プロトコルの一部として依然として広く実装されています。 ― HTTP/0.9 - SuikaWiki (強調引用者) 本当だろうか。 HTTP/0.9といえば、HTTP/1.0やHTTP/1.1に上書きされて悠久の昔に忘れ去られた、古のプロトコルであるという認識である。NetScapeもバージョン2.0からHTTP/1.1を実装している。 HTTP/0.9とは GETリクエストしか存在しない HTTPヘッダなんてない HTTPステータスコード
HTTPヘッダに構造定義を与える Structured Headers の提案仕様 (draft-00) - ASnoKaze blog
2019/12/17追記 draft-14ベースで記事を書き直しました。 (また、最新仕様では 名称が "Structured Field Values for HTTP" に変更されました) asnokaze.hatenablog.com 以下は古い記事です。 HTTPヘッダには、リストや辞書といった構造を表現するのに決まったやり方はありません。 HTTPヘッダ毎にシンタックスや構造が定義されており、そのためパーサーが再利用出来ません。 mnot氏とphk氏の共著で提出された「Structured Headers for HTTP」仕様では、HTTPヘッダに下記の構造を定義しパーサを再利用できるようします。また、新しいHTTPヘッダを標準化する際も個々別のシンタックス定義を不要にしています。 Numbers Strings Labels Parameterised Labels Bina
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて
PHPにおけるHTTPヘッダインジェクションはまだしぶとく生き残る
この記事はPHPアドベントカレンダー2015の3日目の記事です 。 MBSD寺田さんの記事「LWSとHTTPヘッダインジェクション」では、PHPのheader関数に関連して、PHP側のHTTPヘッダインジェクション対策を回避する手法と、それに対するPHP側の対応について書かれています。この記事では、寺田さんの記事を受けて、現在でもHTTPヘッダインジェクション攻撃が可能なPHP環境が残っているかを検証します。 HTTPヘッダインジェクションとは 以下の様なスクリプトがあるとします。 <?php header('Location: ' . $_GET['url']); オープンリダイレクタ脆弱性がありますが、それは気にしないとして、PHP5.1.1までのバージョンでは、以下の様な攻撃が可能でした。 http://example.jp/header.php?url=http://example
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
検索結果は 200 OK を返す - tokuhirom's blog
検索結果が0件なときに｢存在しない｣のだから404を返そうとするコードをたまに見るんだけど､これは 200 OK でやったほうが良い｡ 処理自体が成功したかどうかを返すのに HTTP status code を使った方がよろしい｡
HAR Viewer | Software is hard
HAR Viewer (HTTP Archive Viewer) is an online tool visualizing HTTP Archive (HAR) files produced by HTTP tracking tools. These files contain a log of HTTP client/server conversation and can be used for an additional analysis of e.g. page load performance. Check out online Report issues or suggestions here User interface of this tool is composed from the following tabs (*): Home - Paste content of
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「418 I'm a teapot」が永久欠番（？）に ～25年前の発行されたジョークRFCの後始末／【やじうまの杜】
