Rack応用 - HTTP圧縮エンコーディング最適化 - Qiita
はじめに 前回の投稿ではRackの原理的な部分を説明しましたが、今回は応用編としてファイルの圧縮エンコーディングを取り上げます。まず最適化の方法を説明し、その後でgemモジュールを紹介します。 HTTPの圧縮エンコーディング HTTPプロトコルではサーバのデータをgzipやdeflateなどで圧縮して取得(ダウンロード)することができます。 逆の状況としてアップロード時に同様の機能があるかどうかも調べてみましたが、まだそのような仕様は策定されていないようです。 まずプロトコルを確認しておきます。まずブラウザからサーバにデータを要求する際リクエストヘッダに次の一行を設定して圧縮に対応している事をサーバに通知します。現行ブラウザの最も一般的な設定を示します。 これを受信したブラウザは受信したボディを指定された圧縮エンコーディング(この場合はgzip)で解凍して処理します。特にテキストファイルに
RubyのNet::HTTPにおけるHTTP Compressionサポート - Qiita
Net::HTTPには空気を読んで自動的にHTTP compressionを有効にして通信する機能がある。 リクエストのヘッダーにaccept-encodingやrangeを設定しなければ、自動的にaccept-encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3がセットされ、圧縮されたレスポンスは自動的に展開される。Net::HTTPを内部で使っているライブラリ（open-uriや、faradayのNet::HTTPのアダプターなど）もaccept-encodingやrangeをセットしていなければHTTP Compressionに対応している。 ただし、1.9.3でこの機能が有効になるのはNet::HTTP#getを使用するときだけ。Net::HTTP.getやNet::HTTP::Get（open-uriはこれを使っている）などを使う場合
WebP - Wikipedia
WebP画像の例 WebP(ウェッピー[3])は、米Googleが開発しているオープン標準の静止画像フォーマット。ファイルの拡張子は「.webp」。 2010年9月30日に仕様が公表され、オープンソースの各種ツールと共に提供が開始された。 ウェブサイトのトラフィック量軽減と表示速度短縮を目的としており、インターネットのWebページで広く使われている非可逆圧縮のJPEGや可逆圧縮のGIF、PNGの置き換えを意図する規格である。JPEGとは異なり、非可逆圧縮でもアルファチャンネルを扱える。 画像圧縮については動画規格WebMのベースであるVP8ビデオコーデックの技術を利用しており[4]、コンテナ形式としてRIFFを採用している[5]。コンテナの部分を除くと、非可逆のWebPは1フレームのWebMである。 WebPの最大ピクセル数は16383x16383ピクセル[6]。非可逆のサンプリングファク
独自ヘッダをチェックするだけのステートレスなCSRF対策は有効なのか？ — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
「WebAPIのステートレスなCSRF対策」という2011-12-04の記事がありました。 ここで説明されているCSRF対策は、 GET、HEAD、OPTIONSメソッドのHTTPリクエストはCSRF保護の対象外 HTTPリクエストにX-Requested-Byヘッダがなければエラーにする という非常にシンプルなものです。 そして、この対策の原理として以下の説明がありました。 form, iframe, imageなどからのリクエストではHTTPリクエストに独自のヘッダを付与することができません。独自のヘッダをつけるにはXMLHttpRequestを使うしかないわけです。そしてXMLHttpRequestを使う場合にはSame Origin Policyが適用されるため攻撃者のドメインからHTTPリクエストがくることはない、ということのようです。 ここで、 XMLHttpRequestを使
Shibu's Diary: 「Real World HTTP」が出版されます！
昨年から書いていたReal World HTTPがAmazonのページに表示されるようになりました。最初にコミットしたのは昨年の8/1ですが、たぶん、その数ヶ月前から書き始めていたと思うので、ほぼ丸一年です。途中でASCII.jpのシステムプログラミングの連載が始まったり、Software DesignにSphinxについて寄稿したり、もう１つ別の翻訳の企画があったり、三女が7/4に生まれたり、なかなかハードな一年間でした。 なお、表紙は皆さんが知っているものとはちょっと違うのですが、系統的に一番近いのがハシビロコウさんらしく、和名もそれしかないそうです。狙っていたわけではなく、そもそも出版時期にはアニメも終わってしまっているし、話題の動物は辞めたほうが良さそう、という話をしていたのですが、偶然これが選ばれました。 本の内容の紹介 裏表紙の紹介はこんな感じです。 本書はHTTPに関する技術
CORSリクエストでクレデンシャル(≒クッキー)を必要とする場合の注意点 - Qiita
クレデンシャルの送信 クロスオリジンのAJAXリクエストでクレデンシャル（クッキーの送信またはBASIC認証）を必要とする場合は、それを許可するオプションをフロント側Javascriptで付けておく必要があります。デフォルトではCORSリクエストでクッキーは送信されませんし、BASIC認証は送れません。 Fetch API の場合 fetch(url, { mode: 'cors', //クロスオリジンリクエストをするのでCORSモードにする credentials: 'include' //クレデンシャルを含める指定 })
http ヘッダでブラウザをリロードする retry-after と refreshヘッダ - それマグで！
時間のかかる処理のHTTPリクエストへの対応 HTTPリクエストで、時間のかかる処理を受け取った時どうするか。 すぐに思いつくのは websocket や ajax で pollingしたりpush 通知する方法でしょうが、面倒くさいんだよね。 http ヘッダを見なおしてみる ブラウザにリロードを命令する方法が無いのか、ヘッダを見なおしてみた。 retry-after ヘッダ refresh ヘッダ この２つのヘッダが定義されていることがわかる。 retry-after はブラウザ実装が微妙 retry-after はまさにバッチ処理の為に作られたようなHTTPヘッダなのだが、これを見てるのはGoogleBotくらいらしい。 もし使うとしたら、 202 Accepted や 503 Service unavailable などとともに使うことになるだろうがブラウザ側が実装してないので、使
TLS のひみつ : 迷惑メール対策委員会
IIJ 技術研究所 山本和彦 2008年2月 1.SSL 2.TLS 3.ラッパーとしての TLS 4.蛇足 SSL（Secure Socket Layer）はラッパー（トンネル）として実装できるが、TLS（Transport Layer Security）はラッパーとして実装できないと勘違いしているエンジニアが多い。この記事では、（少なくともクライアント側では）TLS がラッパーとして実装でき、アプリケーションプログラムの実装を変更しなくても TLS が利用できることを示す。 1. SSL あるアプリケーションサービスを SSL を用いて保護するときは、別途ポートを用意しなければならない。たとえば、HTTP（80）を SSL で守るために、HTTPS（443）が定義されている。 このポートの分離のおかげで、HTTPS を見張るプログラムは通信がはじめから暗号文であると決め打ちできる。同様
Cookie の仕様とセキュリティ | yunabe.jp
このドキュメントの目的は Cookie とは何かを一から説明することではないので、そもそも Cookie とは何で何に使えるのかといった話はWikipedia の Cookie の記事などを参考にして下さい。 ここでは Cookie がどういうものかは大体理解しているという前提で、仕様の確認をしていきます。 目次 Set-Cookie ヘッダを使って Cookie を保存する Cookie を参照する JavaScript を使って Cookie を保存・参照する Cookie の属性 domain 属性 path 属性 max-age と expire secure httponly その他 クッキーと port 番号 Cookie が絡むセキュリティ関係の問題 通信路上でのクッキーの漏洩 クロスサイトスクリプティング (Cross Site Scripting, XSS) Set-Co
4 Ways to Parse a JSON API with Ruby
Products Communications Messaging Send and receive multichannel text and media messages in 180+ countries
http→httpsリダイレクトで301と設定してるのに307となってしまう問題 - $yuzu->log();
httpサイトをhttpsサイトに変更する機会がありました。 Apacheの設定でhttpでアクセスがあったらhttpsに301ステータスでリダイレクトとしていました。 設定は下記の通りです。 RewriteEngine On RewriteCond %{SERVER_PORT} !^443$ RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L] しかしGoogle Dev Toolで確認してみると307ステータスでリダイレクトしているようでした。 どうやら原因はHSTSでした。 HSTSとは？ WebサーバーがWebブラウザに対して、セキュアなHTTPSのみでサービスを提供したい場合、ユーザーの利便性といった観点から、HTTPで接続した際にHTTPSのURIにリダイレクトする場合がある。そ
Re:golang の http.Client を速くする
先日mattnさんの記事を読みました。 golang の http.Client を速くする nettというパッケージを使って 名前解決の結果をキャッシュすることで、http.Clientを早くするというものです。 この記事に関して、ちょっと疑問に思ったことがあったので、検証してみました。 疑問 疑問に思ったのは以下の点です。 名前解決遅すぎでは？ ベンチマークの結果を見ると5億ns(=500ms)ほど速度が改善しています。 3つのURLに対してリクエストを投げているので、初回を除く2回DNSのキャッシュがヒットし、 名前解決2回分の速度改善になるはずです。 と、いうことは、名前解決1回あたり250msかかっている計算になります。 googleのsearchは302でリダイレクトがかかるので、Client.Getの呼び出し1回あたり2回リクエストが飛ぶ、 ということを計算に入れても100m
jQueryでは、クロスドメインなAjaxを行った際にはリクエストヘッダにX-Requested-Withが付かないようだ。 - Sooey
jQueryでは、クロスドメインなAjaxを行った際にはリクエストヘッダにX-Requested-Withが付かないようだ。 Cross-Domain AJAX doesn't send X-Requested-With header - Stack Overflow サーバー側のRailsで if request.xhr? といった条件で判定しているような場合に条件が真にならずにはまるので、そのようなケースでは以下を参考に CORS in Rails 4 APIs サーバー側がOPTIONSメソッドによるpreflightリクエストに応答できるようにした上で、jQueryのAjaxリクエスト時のsettingsに headers: {'X-Requested-With': 'XMLHttpRequest'} を含めるようにする必要がある。
X-Requested-Withヘッダ - てきとうなメモ
JSON APIのURLをIEで開くと勝手にContent-Typeをtext/htmlと推測してしまうことがある。その場合、XSS攻撃ができてしまう場合がある これの対策として JSONだけども、HTMLのエスケープをする X-Content-Type-Options: nosniffを設定する XHRを利用する時は、X-Requested-Withヘッダを設定し、設定していなければサーバ側でエラーにする などがある。 1,2は知っていたけど、3は初めて知った。 2は楽なのだけども古いIEだと対応していないという問題がある。1は古いIEでも有効なんだけども、本来エスケープしなくていいものをエスケープするのがやな感じがする。 というわけで、2と3の組合せが良さそう。 で、X-Requested-WithヘッダはjQueryやprototype.jsでは自動的に設定してくれる。ただし、クロス
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
Markdown in 2016 - Hack like a rolling stone
Markdown、あなたのすぐとなりに潜む問題 昨日は toc 拡張の話ついでに、現在の Sphinx と markdown を取り巻く環境について愚痴ったわけですが、Markdown 業界は 2016年のこの時期になっても、いまだに共通的な仕様が決まっていません。 2004年、John Gruber によって生み出された Markdown は、12歳を迎えた現在、さまざまな markdown 処理系を持っています。 そして、不幸にも実装によって markdown の処理はそれぞれ異なってしまっています。 これは Markdown の仕様が曖昧であることと、それぞれの処理系で文法の拡張を行っていることから来ています。 Markdown 処理系による違い Markdown の仕様が曖昧であることは、さまざまな混乱を生み出しました。 babelmark2 が示すように、同じマークアップであって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chrome Web Store
Amazon.co.jp: Web API: The Good Parts: 水野貴明: 本
Amazon.co.jp: SSL/TLSを理解する ~共通鍵暗号・公開鍵暗号・ハッシュ関数・電子署名・証明書~: 武内奈々美: Digital Ebook Purchas
GitHub - jnunemaker/httparty: :tada: Makes http fun again!
