Content-Length: 376912 | pFad | http://b.hatena.ne.jp/m_shige1979/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宛にリクエストを
RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
HTTP/2を実際に使用するためのサーバー設定 | さくらのナレッジ
今日では主要なWebブラウザのほとんどがHTTP/2をサポートしており、Webサーバーさえ対応すればHTTP/2が利用できる状況となっている。本記事ではApache HTTP ServerおよびNGINXでHTTP/2を使うための設定について紹介する。 なお、HTTP/2の詳細については前編で紹介しているので、そちらを参照して欲しい。 WebサーバーのHTTP/2対応状況 今日では多くのWebサーバーがHTTP/2をサポートしており、広く使われているApache HTTP ServerやNGINXでも比較的容易にHTTP/2が利用できる状況となっている。また、WindowsやWindows Serverなどで提供されているWebサーバーであるInternet Information Services（IIS）についても、Windows 10およびWindows Server 2016でHT
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という仕様が提案されて
フロントエンドエンジニアのための動画ストリーミング技術基礎
動画はデータ容量が大きい 画像と違い、動画コンテンツはデータ容量がとても大きいため、データをダウンロードして再生するまでに待ち時間が発生します。 動画のデータ容量が大きい理由はとても単純で、動画は画像データが集合したものだからです。静止画像を人間の目が滑らかに感じられる速さで切り替えて表示することで絵を動かすという表現を実現しています（よくパラパラマンガに例えられますが、そんな感じです）。この人間の目が滑らかに感じる速さというのが 1 秒間に 30 枚だったり 24 枚を切り替えることになります。29.97 (≒30) fps とか 24 fps とかの数字を耳にしたことがあるかと思いますが、24 fps の場合は 1 秒間（s）の間（p）に 24 フレーム（f）を切り替えることを意味します。 データを全て自分の端末にダウンロードしてから再生しようとすると、かなり長い待ち時間が発生してしま
PHPにおけるhttpoxyの対応 - Shin x Blog
HTTP リクエストに任意の値をセットすることで、Web アプリケーションからの HTTP 通信を傍受したり、中間者攻撃（Man-in-the-Middle）を可能にする脆弱性が見つかっています。 専用サイト httpoxyという名前が付けられ、専用サイトが立ち上がっています。詳細は、このサイトが詳しいです。 httpoxy.org 攻撃内容 アプリケーションからHTTP通信を行う際に、環境変数HTTP_PROXYの値を、HTTPプロキシとして見るライブラリがある。 HTTPリクエストにProxyヘッダを付けられると、環境変数HTTP_PROXYにその値がセットされる。（これは、CGIの仕様） つまり、任意のプロキシを外部から指定できてしまうので、通信内容の傍受や偽装ができてしまう。 対象となる PHP アプリケーション HTTP リクエストを受けて動作する PHP アプリケーション アプ
PHP、おまえだったのか。 いつもHTTPメッセージを 運んでくれたのは。
5. use CGI qw(:standard); print header; print start_html('Form Example'), h1('My Example Form'), start_form, "Name:", textfield('name'), p, "Age:", textfield('age'), p, submit, end_form; if (param()) { print "Hi ", em(param('name')), "You are ", em(param('age')), "years old "; } print end_html; HTMLフォーム （Perl CGI.pm利用） 『例解PHP』(2001年) 序文より (Rasmus Lerdorf) 7. <HTML><header><title>Form Example</titl
GlideのバックエンドをOkHttp3にしてカスタムインスタンスを与える - Islands in the byte stream
github.com GlideのバックエンドをOkHttp3にするには、 okhttp3-integration を使います。 dependencies { compile 'com.github.bumptech.glide:okhttp3-integration:1.4.0@aar' } これだけで、GlideのバックエンドHTTPクライアントがOkHttp3になります。 しかし、カスタムOkHttp3インスタンスを与えるにはさらに一工夫必要で、具体的には、アプリケーション用のGlideModuleを実装してAndroidManifestで宣言する必要があります。 まず、GlideModuleを実装したクラスを定義します。 public class OkHttp3GlideModule implements GlideModule { OkHttpClient client = ..
Jettyサーバを使ってみる
始めに Jettyとは、TomcatのようなServletコンテナを搭載したアプリケーションサーバのひとつです。オープンソースでフリーなあたりは、Tomcatと似ていますが次のような点でTomcatと違うようです。 # Tomcatよりも軽量で軽快（数100KBのJARファイル） # HTTPサーバとしての機能が十分にある 通常、Tomcatを使うとなるとApacheなどのHTTPサーバと連携して動作させると思います。これはきちんと役割分担されていて悪い事ではないのですが、Apache+Tomcatでは少しオーバースペックである場合には面倒なことです。 Tomcat自身にもHTTPサーバとしての機能はありますが、これは本当に開発者用としての機能であり、サーバとしては向いていません。 JettyはHTTPサーバとしての機能を十分にもっているので、連携せずに簡単にWebアプリケーションサーバを
AWS EC2でのHTTP/2 or SPDY導入方法 - Hatena Developer Blog
東京でウェブオペレーションエンジニアをしている id:dekokun です。 ここ数年、HTTP/2 or SPDYが話題ですよね。nginxが1.9.5からSPDY対応を切ってHTTP/2の設定ができるようになったり、はてなでも以下ブログにも記載されているように、SPDY or HTTP/2も積極的に導入していっています。 developer.hatenastaff.com 先日、AWSの環境にてSPDYを導入したのですが、導入していくまでにはやはり若干の苦労がありました。そこで、SPDY or HTTP/2をどのように導入していったか及びそこで起きた問題点の解決策等をまとめようと思います。 なお、この記事では"HTTP/2 or SPDY"と書いていますが、SPDYはHTTP/2にその座を譲ろうとしている立場となっています。具体的には、今年の5月にChromeがSPDYのサポートを切る
CentOS 6.5 で HAProxy を試してみる
次に HAProxy の設定を用意する。 概ねサンプルのコンフィグに近くなっている。 *:80 への HTTP リクエストを 192.168.33.{101,102} に振り分ける。 $ sudo cp /etc/haproxy/haproxy.cfg{,.orig} $ cat << EOS | sudo tee /etc/haproxy/haproxy.cfg > /dev/null $ cat /etc/haproxy/haproxy.cfg global chroot /var/lib/haproxy daemon log 127.0.0.1 daemon pidfile /var/run/haproxy.pid maxconn 4192 user haproxy group haproxy quiet defaults mode http log global option ht
H2O the optimized HTTP/1.x, HTTP/2 server
H2O is a new generation HTTP server that provides quicker response to users with less CPU, memory bandwidth utilization when compared to older generation of web servers. Designed from ground-up, the server implements of HTTP/2 and HTTP/3 taking the advantages of features including new and old content prioritization schemes, server push, 103 Early Hints, promising outstanding experience to the visi
Apache、Nginx、H2Oでベンチマークしてみた - ぽんこつエンジニアのブログ
すいません！！！ この記事を書いた後いろいろ調べてたら、wrkはhttp2に対応していませんでした！ ということで、今回のベンチマークはApache、Nginx、H2OのHTTP1.1でのベンチマークとなります！ ちゃんとHTTP2でベンチマーク取ったものを後日公開します！ 最近HTTP2が色々盛り上がってるのは知ってたんですが、YAPC:ASIA 2015に行ったらH2Oが気になり始めたんで普段使ってるApacheよりきっとH2Oが早いぜって言ったら「いやH2Oとか知らんから、とりあえずNginxやろうよ」って言われたのでNginXも一緒にベンチマークしてみました。 環境 さくらサーバのVPS メモリ1G CPU ２コア 表示させるもの 表示させるのはなんでも良かったんですがとりあえず普通のページっぽいのが良かったんでここの無料テンプレートを使ってみました。 《無料》ホームページテンプレ
wgetコマンドで覚えておきたい使い方16個(+1個) | 俺的備忘録 〜なんかいろいろ〜
wgetコマンドといえば、webからファイルをダウンロードしたりする際によく利用するコマンドだ。 今回は、このwgetコマンドについて覚えておきたい使い方をまとめてみる事にする。 1.基本の使い方 基本的には、以下のようにオプション無しでコマンドを実行することで、Web上のファイルをダウンロードする。 ダウンロードしたファイルはカレントディレクトリに同じ名前で保存される。 wget http://ファイルのURL [root@test-node work]# ls -la 合計 4 drwxr-xr-x. 2 root root 6 3月 19 00:39 . dr-xr-x---. 19 root root 4096 3月 19 00:39 .. [root@test-node work]# wget http://diffc.googlecode.com/svn/trunk/bin/p
Raspberry Pi 2 Model BでLet's Encrypt! - 干し風呂
2015年12月3日からLet's EncryptがPublic Betaとなったので早速ラズベリーパイで試してみました。 細かい説明は色々な方々がされているので、細かい説明は省いて発行までの流れをサラッと書きます。 目次 Let's Encryptとは 前準備 letsencryptをclone virtual envの準備 証明書発行 発行確認 更新時 失効 終わりに・感想 Let's Encryptとは Let's Encrypt letsencrypt.org SSLサーバ証明書を無料で手軽に発行できるようにし、世の中の通信のSSL/TLS化を促進させるためのプロジェクト 従来は発行自体の作業が面倒くさい、お金がかかるという問題があった（有料・数分〜数十分、色々な操作） CSR作成、証明書発行、サーバへの設置などの手間を省き全てコマンドベースで作業が完了する（無料・数秒） コモンネ
GitをProxy環境下で使うときにハマった件 - ごずろぐ
Gitを社内(Proxy環境下)で使うときは気をつけましょう Atlassian Stashのサーバ構築も終わり、試しに使いながらSubversionから移行をしていたら早速ハマった。 いきなりClone出来ない Stashでリポジトリを作成し、画面からCloneするとSourceTreeが上がるのだが、エラーでClone出来ない。 以下のようなエラーが出る。 fatal: unable to access 'http://git.example.com/scm/test/test/': The requested URL returned error: 503 デバッグしてみた SourceTreeはGitコマンドを呼んでるだけのようなので分かりやすくコマンドを叩いてデバッグしてみた。 $ git clone http://git.example.com/scm/test/test Cl
QUICの技術要素分解
この投稿はHTTP2 Advent Calendar 2014の18日目の記事です。 前日は HTTP2におけるProxyに関する議論 でした。 (あらすじ・前略) もっこすにはHTTPがわからぬ。もっこすは、ただのゲーマーである。ヴァナディールで市場価格操作に命を懸け、艦娘と遊んで暮らしてきた。けれどもトランスポート層のプロトコルについては、人一倍に敏感であった。 HTTP2とは直接関係ないので、念のため概要を説明してから進みます。HTTP2勉強会 #hｔtp2studyシリーズに参加されている方だと、もうご存知の方が多そうな気はしますが、とりあえず。 QUICとは、Googleが開発しChromiumに実装中のトランスポート層、すなわちTCPと同じ層のプロトコルです。Internet上で運用される独自実装トランスポートの常として、UDPで包んだ中に独自実装が入っています。 QUICの主
HTTP/2, QUIC入門
2. 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ • プロダクト本部 アプリケーション開発部サービス開発2課 • NodeJS Technical Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当） • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。 • ブログ： http://d.hatena.ne.jp/jovi0608/ 3. はじめに • HTTP/2とQUICの概要を学んでいただきます。 • HTTP/2はTLSと異なり必要となる要素技術の数は少ないです。 ですがヘッダ圧縮仕様HPACKを完全に理解しないと概要以上の レベルの技術は見につきません。 • QUICは、TCP/TLSの技術要素の集まりです。これをきちんと理 解するには相当の努力が必要です。 • 残念ながら2時間の
Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注： 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/m_shige1979/http/
Alternative Proxies:
Developing the fastest HTTP/2 server
