POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
HTTPメッセージに署名をするSignatureヘッダの標準化 - ASnoKaze blog
HTTPメッセージに署名をするSignatureヘッダを定義する「Signing HTTP Messages」という仕様が提案されています。 HTTPメッセージへの署名は、様々なところで行われていますが、それぞれ独自の方式で行われています。例えば、AWS APIを叩く際に利用する「Signature Version 4 Signing」や、OAuth2.0 DPoPなどでHTTPメッセージへの署名が行われています。 その他にも、WebPackagingで使用される「Signed HTTP Exchanges」といったところでも署名が行われています。 一方でTLSではだめなのかという話もありますが、TLSを用いることでHTTPメッセージの機密性および完全性は保護されますが、TLS終端プロキシなどを経由するとそれ移行の部分で通信の完全性は担保されません。クライアントとサーバ間でHTTPメッセー
ウェブを支えるHTTP通信はどのように進化しているのか
HTTPはハイパーテキスト・トランスファー・プロトコルの略称で、ウェブサイトを閲覧する際のサーバーとの通信にて使用されています。CloudflareがHTTPの新バージョン「HTTP/3」に対応するにあたり、これまでのHTTP通信の問題点がHTTP/3でどのように解決されているのかをブログにまとめています。 HTTP/3: the past, the present, and the future https://blog.cloudflare.com/http3-the-past-present-and-future/ 1990年末に世界初のウェブページが登場し、その翌年の1991年にHTTPの初めての仕様書が書かれました。これはHTTP/0.9と呼ばれており、単にサーバーから特定のドキュメントをダウンロードするだけの簡易なものとなっていました。 1996年にはアップロードに対応するなど
【php】送信したリクエストの内容を見る方法（2） at softelメモ
問題 APIを利用したプログラムを書いているとき、 APIに対してphpが送っているリクエスト内容を確認したいことがあります。 どうやるとよいでしょうか。 答え プログラムが動いているサーバーにログイン可能であれば、tcpdumpで観察することが可能。 状況に応じてオプションは調整されたし。 # tcpdump -A host 相手先APIのIPアドレス APIにリクエストを送る側 client.php <?php $url= 'APIのURL'; $xml='<?xml version="1.0" encoding="UTF-8" ?> <books> <book> <title>APIの本</title> <price>1111</price> </book> <book> <title>PHPの本</title> <price>2222</price> </book> </books
HTTP over マルチキャストQUIC とは - ASnoKaze blog
2022/05/16 動きがあったため、記事を新しく書きました asnokaze.hatenablog.com 「Hypertext Transfer Protocol (HTTP) over multicast QUIC」で、マルチキャストのQUIC上でHTTP通信を行う仕様が提案されている。マルチキャストQUICは単方向通信であり、その上でサーバプッシュを行う感じである。 現状QUICの仕様ではIPマルチキャストの利用は想定されていない(もちろん双方向通信)ため、この仕様ではQUICのトランスポートレイヤ、HTTPレイヤを利用しつつも、IPマルチキャストを利用できるように一部の変更(制限)を加えている。 BBC Researchの方が書かれているので、主に動画像配信での利用を考えているんだと思う。 ざっと仕様を読んだのでかいつまんで特徴を紹介する。 また、QUICの仕様はまだ変わる可能
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
remote_addrとかx-forwarded-forとかx-real-ipとか - Carpe Diem
背景 ECSでNginxのコンテナをプロキシとして立てたところ、APIサーバのアクセスログのクライアントIPがNginxのコンテナIPになっていたのでその修正をしたのがきっかけです。 環境 Nginx 1.10.2 Docker1.12.1 構成 Client -> ELB -> Nginx -> API という構成とします。 ネットでよく見る情報 set_real_ip_from 172.31.0.0/16; real_ip_header X-Forwarded-For; を追加する、とか proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; を追加する、とかどれがどれだか分かりにくいので１つ１つ説明していきます。 用語説明 remote_
「HTTP」の仕組みをおさらいしよう（その3）
「HTTP」の仕組みをおさらいしよう（その3）：リトライ！ 触って学ぶTCP/IP（4）（1/4 ページ） ネットワークの基礎を支えるTCP/IPを基本から学び直す本連載。第4回では、HTTPのリクエストやレスポンスのヘッダについて、さらに詳しく解説していきます。実際の通信内容を見ながら、理解を深めましょう。 連載目次 新サンプルサイトを用意しました！ HTTPでのやりとりを見るサンプルとして、前回までは＠ITのWebサイトを取り上げてきましたが、より細かいやりとりを確認できるように、筆者が独自に新たなサンプルサイトを用意しました。今回からは、このサンプルサイトも使いながらHTTPの動作確認を進めましょう。 新しいサンプルサイトのサーバ名は「ait-sample.list.jp」です。また、GETする対象の位置は「/rtcp/p00/」などに変わります。Webサーバに対するリクエストの方式
【HTML】HTTPSからHTTPへの移動でもリファラを送信できるメタタグが存在する。 – 和洋風KAI
えー写真に意味はありません。ただ一つ言えることは、可愛いは正義です。 さて先日、当ブログをHTTPS化しました。 非常にセキュアになったのは嬉しいのですが、HTTPSページからHTTPページにリンクで飛んだ場合、HTTPページはリファラを受け取ることができません。 これだと、リンクしたことをお伝えできないのでちょっとアレですよね。 なんとかならないもんかと思ったら、HTMLにあるmetaタグを挿入することで、リファラを制御できるようです。 HTTPSページでもリファラを制御できるメタタグ。 HTMLを策定している、W3Cにそのメタタグが紹介されています。 2016年4月19日現在、以下の5種類が用意されています。 no-referrerは、リファラを全く送らない仕様ですね。HTTPS→HTTPSでもリファラを送りません。↓↓ <meta name="referrer" content="n
検索結果は 200 OK を返す - tokuhirom's blog
検索結果が0件なときに｢存在しない｣のだから404を返そうとするコードをたまに見るんだけど､これは 200 OK でやったほうが良い｡ 処理自体が成功したかどうかを返すのに HTTP status code を使った方がよろしい｡
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
same-site/cross-site, same-origin/cross-originをちゃんと理解する
ブログ（Wireless・のおと）｜サイレックス・テクノロジー株式会社