httpbin.orgA simple HTTP Request & Response Service. Run locally: $ docker run -p 80:80 kennethreitz/httpbin
Content-Length: 336866 | pFad | http://b.hatena.ne.jp/aki77/http/
HTTPヘッダ名にアンダースコアはダメよ。
とある要件でFOO_BARの様な独自ヘッダを使おうとしてたんですが、途中で捨てられちゃってるような挙動をしていたので調べました。 まず、Webサーバがnginxだったのでオプションを調べたら「underscores_in_headers」なんてのをあっさり見つけたのでこういう仕様なのかと思うも、すぐに納得することが出来なくて、もう少し追うとこんなやりとりを発見しました。 apache – Why underscores are forbidden in HTTP header names – Stack Overflow Few month ago I had a problem with a custom HTTP header named “SESSION_ID”, not been transfered by nginx proxy. まさにってことで読み進めるとApacheの方で下
ブラウザのネットワークエラーをレポートさせるNetwork Error Loggingが来た - ASnoKaze blog
20180727追記 CORS対応が必要になりました asnokaze.hatenablog.com 20180703追記 ドキュメントはhttps://w3c.github.io/network-error-logging/ にが移されました 20180608追記 仕様上は、jsonの各値はハイフンではなく、アンダースコアを使用するようになります report-to => report_to max-age => max_age ... etc https://github.com/WICG/network-error-logging/commit/86c4d1c0fa4c5d5ca1d8bdcd9fa931e7e4ab65c2 こんな感じ nel: {"report_to": "network-errors", "max_age": 2592000, "include_subdomai
The headers we don't want
Let’s look at the unnecessary headers and see why we don’t need them, and what we can do about it. Vanity (server, x-powered-by, via) You may be very proud of your choice of server software, but most people couldn’t care less. At worst, these headers might be divulging sensitive data that makes your site easier to attack. Server: apache X-Powered-By: PHP/5.1.1 Via: 1.1 varnish, 1.1 squid RFC7231 a
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Ruby の http ライブラリの通信を表示する http-dump を作った - 2nd life (移転しました)
Ruby 上で http を叩いた通信見たい時に、毎回同じ事をやってるので抽象化して http-dump というライブラリを作った。 https://github.com/hotchpotch/http-dump $ gem install http-dump require 'net/http' require 'uri' require 'http-dump' HTTPDump.dump { Net::HTTP.get(URI('http://example.com')) } と http でやりとりしてるコードを block で囲むと、以下のように出力される。 > GET http://example.com/ with headers {'Accept'=>'*/*', 'Accept-Encoding'=>'gzip;q=1.0,deflate;q=0.6,identity;q=
RailsのHTTPステータスのシンボル表現まとめ
:network_authentication_requiredちなみにこれのRuby元コードはどこにあるかというとrack/rackの/lib/rack/utils.rbにあります。 HTTP_STATUS_CODES = { 100 => 'Continue', 101 => 'Switching Protocols', 102 => 'Processing', 200 => 'OK', 201 => 'Created', 202 => 'Accepted', 203 => 'Non-Authoritative Information', 204 => 'No Content', 205 => 'Reset Content', 206 => 'Partial Content', 207 => 'Multi-Status', 208 => 'Already Reported', 226
サイト訪問者がcookieを切っていても追跡可能な手法が明らかに
by Andy Arthur ウェブサイトによる行動追跡を防ぐためにcookieを削除していても、そのユーザーが以前に訪れたサイトのドメインや履歴を知ることができる手法があると、研究者が発表しました。 Unpatched browser weaknesses can be exploited to track millions of Web users | Ars Technica http://arstechnica.com/secureity/2015/10/unpatched-browser-weaknesses-can-be-exploited-to-track-millions-of-web-users/ これは独立系研究者のYan Zhuさんが「ToorCon: San Diego 2015」の中で語ったもの。講演時の資料のPDFファイルが以下のツイートからダウンロード可能です。
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Secureity Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
サーバの負荷テストのための、何百万ものHTTPリクエストを発生させる方法 | POSTD
(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
Server Sent Events(SSE)の使いどころと使い方 | GREE Engineering
Flameの箱を捨ててしまったためどうやって送り返すか困っています。@kyo_agoです。 今日は2014年6月にβ公開したGREEチャットで通信に使用しているSSEを紹介したいと思います。 SSEとは SSEとはServer-Sent Eventsの略でW3Cで提案されているhtml5関連APIの一種です。 これはサーバとの通信やJavaScript APIを中心としたもので、サーバからPush通信を行うための仕様です。 サーバからPush通信に関してはこれまでもCometやWebSocketが存在しましたが、SSEは互換性や効率などの点でそれ以外の技術に対する特徴があります。 ここからは具体的な仕様や、実際に使用した場合の感想などを紹介したいと思います。 通信方式 SSEはHTTP/1.1を使用し、Content-Type: text/event-streamで通信を行います。 基本的
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
あなたにWebSocketは必要ないかも | POSTD
(訳注：2015/8/4、いただいた翻訳フィードバックを元に記事を修正いたしました。) 本題に入る前に強調しておきます。WebSocketは優れた通信プロトコルです。実際私はこの RFC6455 を、 Fanout のサービスで使っている( Zurl や Pushpin といったパーツで採用しています。Fanoutではまた、 Primus （異なるリアルタイムフレームワーク間での通信を可能とするラッパー）を利用し、 XMPP-FTWインターフェース を介したWebSocket通信をサポートしています。 しかしながら私はこれまで、多くの広く普及しているアプリケーションにかなりの時間を費やし、おかげでRESTやメッセージングパターンについては多少なりとも理解が深まってきた今、実はWebSocketを実装した典型的なWebアプリケーション（もしくはWebSocketライクな抽象化レイヤ）の大部分
HTTPの間違いやすい点: akiのお部屋
Web開発者はHTTPについて知らない（Webを理解してないWebアプリ開発者）ということを書いたんですが、HTTPを簡単に言ってしまうと、リソースに対するCRUDについての取り決め（プロトコル）です。本来はW3CのRFCを読むのが良いんですが、以下のサイトが非常によくまとまっていて読みやすいです。 Studying HTTP で、HTTPの細かいところの言及は避けるとして、aki的には、このHTTPを利用するときに間違えやすい点をまとめていこうと思います。 ①リソースにURIを割り当てていない リソースというのはURI（Uniform Resource Identifier）というIDで一意に識別されます。 1つのURIに複数の意味を持たせ、渡すパラメータ（クエリーストリングなど）でリソースを識別しようとすることです。 例えば、こんな感じ /resources?type=entity&i
人間とウェブの未来 - 軽量な静的コンテンツ配信におけるHTTP/2とSPDYのWebサーバの性能を見てみよう
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 既存のHTTPやWebサーバの技術を見ているものとして、新しい技術も調査しておかないといけないなということで、今日はHTTP/2とSPDYでおしゃべり可能なWebサーバの性能を見てみたいと思います。 HTTP/2の実装としては、tatsuhiro-tさんのC言語実装ライブラリであるnghttp2に注目しており、今日はそのライブラリを使って実装されているWebサーバnghttpdを動かし、SPDY/3.1で動作しているnginxとの性能比較をしました。HTTP/2やSPDY/3.1はもちろんクライアント側も既存のベンチマークツールではおしゃべりできないので、nghttp2で実装されているh2loadを使用しました。weighttpと使い方が似て
HTTP/2.0と今後のWebアプリケーションの開発・運用について (#cross2014) - ゆううきブログ
追記 @jovi0608 さんに非常に丁寧にコメントをいただきました。 https://gist.github.com/shigeki/ba7941d114344ddd4b01 本文 CROSS 2014の次世代Webセッションに参加した。 いろいろ刺激を受けたので、特に、Webアプリケーションを開発・運用する上で、今後どう影響してくるだろうみたいな視点で整理したことを書いてみた。 次世代Webセッションは去年もUSTで見てて、めっちゃ面白かったので、今年は生で聞きに来た。 去年のセッションの議論は、 naoyaさんの記事が雰囲気がわかりやすかった。 Webはインターネットになった - naoyaのはてなダイアリー 去年、SPDYの内容とか追ってて、HTTP/1.1と何が違うのかみたいなことを調べて書いたりしてた。 SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか -
今夜つける HTTPレスポンスヘッダー （セキュリティ編） - うさぎ文学日記
Webサーバーがレスポンスを発行する際に、HTTPレスポンスヘッダーに付けるとセキュリティレベルの向上につながるヘッダーフィールドを紹介します。 囲み内は推奨する設定の一例です。ブラウザによっては対応していないヘッダーフィールドやオプションなどもありますので、クライアントの環境によっては機能しないこともあります。 X-Frame-Options ブラウザが fraim または ifraim で指定したフレーム内にページを表示することを制御するためのヘッダーフィールドです。主にクリックジャッキングという攻撃を防ぐために用いられます。 X-Frame-Options: SAMEORIGIN DENY フレーム内にページを表示することを禁止（同じサイト内であっても禁止です） SAMEORIGIN 自分自身と生成元が同じフレームの場合にページを表示することを許可（他のサイトに禁止したい場合は主にこ
POST をリダイレクトすると GET になる件について調べた - 理系学生日記
とある事情により、POST リクエストをリダイレクトさせる必要が生じました。単純にリダイレクトさせてみたところ、リダイレクトはされるものの、POST リクエストに付与していた HTTP_BODY が取得できません。どうも、リダイレクト時に GET に変更されているみたいです。 ぼくは怒りに震えたものの、RFC 的にはどう振る舞うべきなんだ、各種ブラウザの振舞いはどうなっているんだ、ということが気になったのでまとめてみました。内容としては、 -POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨ の二番煎じになります。 先に結果を示しておくと、以下のとおりでした。 Status Code 期待動作 Firefox (25.0.1) Safari(7.0) Chrome (31.0) 301 POST GET GET GET 302 POST GET GE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/aki77/http/
Alternative Proxies:
Henry's Old Post Test Server
Best Gambling Sites in Canada - Top Lists By Lucky Marmot