XMLHttpRequest とはなんだったのか | blog.jxck.io
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
Nginxで、リクエストを複製するmirrorモジュールが標準搭載された - ASnoKaze blog
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
HTTPステータスコード451(政治的な検閲)が正式に承認される
mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。 このステータスコードは、法律や一般大衆の雰囲気がサーバー
セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita
最近はハンドリングしくてもいいや的な、入力改ざんで発生するバリデーションエラーをそのまま500のHTTPステータスで返すと、攻撃者が「なんか攻撃成功しちゃいそう」って思っちゃうとかなんとかで、監査的なところから「500はやめろ」って言われることがあります。 一理ある ということで、安易に500を返さない方法を考えてみます。 HTTPステータスコードにあまり馴染みのない方は、こちら…ではなく、こちらをまず読んでください。 HTTPステータスコードの使い分け基礎 400 まず、ユーザの入力値、データの状態によってエラーになるケースは 400 Bad Request とします。エラーメッセージを表示して再入力を促すHTMLページを返す、一般的な入力エラー系の遷移は200 OKを返しても、実用上問題はないかと思います。 ユーザの操作が原因で、サーバ処理がエラーになった場合も400で扱うのはおかしい
HTTP/2は流行らないけど広く使われるものだと思う。 - ぼちぼち日記
まずは Disclaimer、 「あくまでも個人の感想であり、HTTP/2の効能を保証するものではありませんw」 1. はじめに、 先日、HTTP/2, HPACKのRFC(7540,7541)が無事発行されました。2年余りHTTP/2の標準化活動に参加してきたのですが、もうすっかり昔の事のような感じがします。 今日、Scutumの開発をされている金床さんの「HTTP/2のRFCを読んだ感想」のエントリーが公開され、読ませて頂きました。今回初めてHTTP/2の仕様書を読まれた感想ということで、長くかかわってきた立場から見ると非常に新鮮な内容でした。 実は「HTTP/2が流行らない」という指摘は、１年半ほど前に私も同じことを書いていました。 HTTP/2.0がもたらす�Webサービスの進化(後半） また、偶然なのかわかりませんが、同じ Proxy製品 vanish varnish *1 の開
HTTP/2時代のバックエンド通信検討メモ - ぼちぼち日記
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
HTTP2 時代のサーバサイドアーキテクチャフィードバック
Shigeki Ohtsu @jovi0608 @Jxck_ なんで DC 内で TLS 使わないの？ GFEもTの Reverse Proxy もTLSほどいて、ふり先ロジック等入れてバックエンドもTLSよ(NSA対策も必要だから）。DC内通信なら自分でCA立ててPKI構築できるのでクライアント側より自由度は高くなるのに。
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY（スピーディ）。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究
ReverseHttp | ReverseHttp
ReverseHttp Introduction Polling for updates is bad. We’ve known this for about as long as computers have existed. So why are so many web-based services (SUP, RSS and Atom feeds, Twitter, etc.) based around polling? The answer lies, first and foremost, in the asymmetry of HTTP. The web is split into two pieces: programs that make requests, and programs that handle them. It’s very rare to see a sin
HTTP における日時処理 - kazuhoのメモ置き場
Expires レスポンスヘッダとか、そのまま使うんじゃなく Date ヘッダの値で減算したデルタ値を使うのが正しい。だってクライアントやサーバの時計があっている保証なんてないから。 ＃タイムゾーンが狂ってるとかよくあるし freshness_lifetime = expires_value - date_value Hypertext Transfer Protocol -- HTTP/1.1 13.2.4 Expiration Calculations Cookie の expires については定義がないと思うけど、実装としては当然同様にすべき。実際、Firefox のソースコードもそうなってる。 http://lxr.mozilla.org/mozilla1.8/source/netwerk/cookie/src/nsCookieService.cpp#1975
負荷をかけるツール - HTTP編 - (ひ)メモ
ApacheCon US 2007の、『Apache Performance Tuning / Part One: Scaling Up』, Sander Temme (PDF) より。 ab おなじみ、Apache付属のあいつ http_load http://www.acme.com/software/http_load/ flood http://httpd.apache.org/test/flood/ JMeter http://jakarta.apache.org/jmeter/ 最近のバージョンは使いやすくなったらしい あと、ほかには httperf http://www.hpl.hp.com/research/linux/httperf/ とか。
L'eclat des jours(2007-11-10)
_ メモ というか、2000年（HTTP誕生約10年＝1decade）にRESTアーキテクチャが示されたということ。 これによって、1997〜98に発生したHTTPを単なるキャリアとみなす考え、XML-RPCやSOAP（これらは、HTTPにデペンドしてなくて、SMTPでもFTPでも良くて、その上にXMLエンコーディングとネームスペースの層を重ねている）は生まれきっていないうちに息の根を止められた、ということ。でも、本当に1998年頃、HTTP＋XMLで分散システムを支配できることがわかった時のエキサイティングな雰囲気は楽しかったな。ただ、その適用範囲を見誤って、分散システムの支配から、世界の支配を目論んだあたりから変な方向へ進んだようにみえる。 ということで、SOAPが死んだとか言われたところで、企業システムでは話は別で、というのは、ファイアウォールから世界を見れば、ポート80はすべての通
MOONGIFT: ? WindowsでHTTPデバッグ「Fiddler2」:オープンソースを毎日紹介
Webサービスの開発を行っていると、HTTPの通信内容を見たくなる事がある。FirefoxであればLiveHTTPHeadersを使ってみられるが、IEではちょうど良さそうなものがなかった。 以前はProxomitronを使っていたが、HTTPSのデバッグも含めて役立ちそうなのがこちらだ。 今回紹介するフリーウェアはFiddler2、Windows向けのHTTPデバッガだ。 Fiddler2はインストールし、起動するとインターネットオプションのプロキシとして動作するようになる。終了すれば下に戻る。そして、ブラウザとサーバ間の通信をキャプチャしてくれる。 複数のセッションもリストアップしてくれる。また、HTTPSに対しても利用できるのが利点だ。Basic認証の内容や、ヘッダ内容等細かく見る事が可能だ。 面白いのは実行結果をVisual Studio Web Testとして保存できる機能だ。こ
Pen
This is Pen, a highly scalable, highly available, robust load balancer for tcp and udp based protocols such as dns, http or smtp. It allows several servers to appear as one to the outside and automatically detects servers that are down and distributes clients among the available servers. This gives high availability and scalable performance. Pen works on Linux, FreeBSD, OpenBSD, NetBSD, Solaris an
fragment込みでリクエストされた場合どうなるもの？ - KoshigoeBLOG
fragmentを付けてGETした場合とか、サーバは環境変数のQUERY_STRINGとかをどう扱うべきなんだろう。 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] ... Request-Line = Method SP Request-URI SP HTTP-Version CRLF ... Request-URI = "*" | absoluteURI | abs_path | authority Hypertext Transfer Protocol -- HTTP/1.1 ↑を見た感じ、fragment付きでリクエストされる事を想定してないように思えるんだけど、どうなんだろう。 とりあえず、実装(挙動)を見ようと言う事でテスト。Apache2で動くPHPプログラムで環境変数をダンプしてみたのが
[セキュリティ]httponlyは普及するのか (2006-12-26 - T.Teradaの日記)
Firefox2でもhttponlyが使えるという話を耳にしました。 httpOnly - Firefox Add-ons*1 httponlyがいよいよ普及するか？ というのでネタにしてみます。 なお、この日記は、WinXP＋IE6SP2環境を前提として書きました。 はじめに httponlyは、XSS脆弱性がある状況においても、cookieを窃取されないようにすることを狙ったIEの独自機能です。 MSDN - Mitigating Cross-site Scripting With HTTP-only Cookies この機能を有効にするためには、発行するcookieにhttponly属性を付けます。 Set-Cookie: key=value; domain=example.com; HttpOnly httponly属性が付けられたcookieは、JavaScriptのdocume
![[セキュリティ]httponlyは普及するのか (2006-12-26 - T.Teradaの日記)](https://cdn-ak-scissors.b.st-hatena.com/image/square/e8a0aea5d375a69b5b38062b6dbabb4cf556055e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711097230%2F1548045809)
404 Blog Not Found:HTTPサーバーのパイプライン対応
2006年12月21日17:30 カテゴリSciTech HTTPサーバーのパイプライン対応 今回は、HTTPのパイプラインの話。 「RFC2616の同時接続数の規定」@水無月ばけらのえび日記 「HTTPの同時接続数はどうあるべきか? (slashdot.jp) 」というお話。誰も原文を引用していないのが悲しかったので、引いておきます。 スラッシュドット ジャパン | HTTPの同時接続数はどうあるべきか?-taka2さんのコメントそれなら、「同時接続」しなくても、結果が返ってくる前に次のリクエストを送出して「リクエスト送信」と「結果受信」を並行して行えるようになれば、スループットの向上は見込める。 それがパイプライン化 [mozilla-japan.org]で、同時接続するよりも効率が良い。パイプライン化の前に、HTTPで何が行われているのかを、実際に見てみよう。telnetコマンドがあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.typemiss.net/blog/kounoike/20060227-75
http://rocketeer.dip.jp/secProg/HttpSecurity001.pdf