Rails Developers Meetup 2018: Day 1 発表資料 https://techplay.jp/event/639872
さっき Cache-Control ヘッダの話を書いたんですが、もちろんキャッシュ制御に関しては Cache-Control ヘッダだけで収まる話ではなく、他にも多々のヘッダが影響を与えます。 その一つに、Vary ヘッダがあるので、今日はその話でも。 Vary ヘッダ Vary ヘッダは、RFC7231 で定義されているヘッダです。 vary というと「変わる」という意味を持つ動詞ですが、Vary ヘッダはその名の通り、「どのヘッダによってコンテンツが変わったのか」を示すレスポンスヘッダです。 例えば、よくあるタイプのスマートフォン対応の 1 つとして、User-Agent ヘッダを見て、PC 用 HTML を返却するか、スマフォ用 HTML を返却するかを切り替える実装を良く見ます。 この場合、レスポンスヘッダに Vary: User-Agent ヘッダを付けるのが常套手段です。ちなみ
スマホ向け表示を分けているときはVary HTTPヘッダーを使うこと ★★★★☆ グーグルが理解できるように (Google Webmaster Help on YouTube)グーグルが推奨するモバイルサイト構成には3つ種類がある。「レスポンシブWebデザイン」「同一URLで端末によって出し分け」「スマホ向けを別URLで作り、リダイレクトする」の3つだ。 このうちレスポンシブWebデザイン以外の2つの構成では、アクセスしてきた端末の「User-Agent(UA、ユーザーエージェント)」の情報に基づいてPCとスマートフォンで異なるHTML(やCSS)を返す。 これら2つの構成を採用する際には、Vary HTTPヘッダーを使用することをグーグルは強く勧めている。 Vary HTTPヘッダーとは、サーバーにアクセスがあったときに、データと一緒にサーバーから返すHTTPヘッダーの1つで「Vary
[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の規約。URLはリソースであり、CRUDはHTTP動詞にマップされる。 RESTの規約に1つ問題があるとすれば、規約が十分でないということでしょう。上記で”通常”、”多くの場合”、”時に”という表現を使ったのは、これらのやり方は仕様で推奨されているものの守られるとは限らないためです。実世界では、大抵のAPIはRESTishがせいぜいです。例えばStripeでは、リソース更新に PUT ではなく PATCH を使うべきですが、歴史的理由でそうはなっておらず、おそらく現時点では変更に値しないでしょう。いずれにしても開発者はドキュメントを読む必要があり、その時、 POST メソッドのユビキタスな使い方があることに気づくのです。 RESTには他の問題もあります。必要なものだけでなく全てが返ってくるため、リソースのペイロードが非常に大きくなることがあるのです。そして多くの場合、クライアントが
HTTPヘッダ・インジェクション(HTTP header injection)とは、HTTPを使って通信するシステムにおいて、動的にHTTPヘッダを生成する機能の不備を突いてヘッダ行を挿入することで不正な動作を行なわせる攻撃手法のこと。また、その攻撃を可能とする脆弱性のこと。 原理[編集] SQLインジェクションなどと同様に、入力値を出力に用いている箇所において、文法上特殊な意味を持つ文字をエスケープせずに展開することで発生する。 HTTPヘッダにおける特殊文字とは、改行コードである。各HTTPヘッダ行は改行で終了し、それ以降は新たなヘッダ行として処理される。この結果、HTTPヘッダの値として改行コードを挿入することができれば、本来の通信内容には含まれないヘッダを挿入することができる。 また、HTTPは空行によってヘッダとボディを区切っている。連続する改行を挿入すればHTTPヘッダの終了を
Webアプリケーションの開発・展開を行っている人々にとって、セキュリティ確保は大きな関心事の1つだといえます。そのためのベストプラクティスやフレームワーク、ガイドラインを提供しているのがOWASP(Open Web Application Security Project)です。OWASPのWikiサイト(OWASP.org)には、Webアプリケーションのセキュリティ確保のための様々な情報がありますが、それらの中でも即効性の高いのが「便利なHTTPヘッダのリスト(List of useful HTTP headers)」だといえるでしょう。 このページには、アプリケーションのHTTPレスポンスに追加することで、事実上無料でセキュリティを強化できるHTTPヘッダが7種類掲載されています。 これらの中でまず活用したいのが、以下の2つのHTTPヘッダです。 X-XSS-Protection 最近
歴史[13] RFC 2046 4.5.1. Octet-Stream SubtypeThe "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is: "octet-stream" 亜型は本文が任意のバイナリ・データであることを 示すのに使います。現在定義されているパラメーターの集合は、 次の通りです。 (1) TYPE -- the general type or category of binary data. This is intended as information for the human recipient rather than for any automatic pr
◆ XFF( X-Forwarded-For )とは X-Forwarded-Forとは、HTTPヘッダフィールドの1つであり、ロードバランサなどの機器を経由して Webサーバに接続するクライアントの送信元IPアドレスを特定する際のデファクトスタンダードです。 クライアントの送信元IPアドレスの特定は、ロードバランサなどでクライアントの送信元IPアドレスが 変換された場合でも、HTTPヘッダに元のクライアントIPアドレスの情報を付加することで実現します。 ◆ XFF( X-Forwarded-For )を使用しない場合 例えば、下図のようにワンアーム構成において「行き」と「戻り」のパケットが同じ経路を通るように クライアントの送信元IPアドレスを、ロードバランサのI/FのIPアドレスに変換して送信するとします。 通信自体は正常に行われますが、リアルサーバに着信したパケットの送信元IPは、ロ
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた?よし、それなら 200 を返しましょう。ページが存在しない?それなら 404 です。他のページにユーザをリダイレクトしたい? 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳:HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
Servlet による WEB アプリケーションでは画面遷移の方法に redirect(リダイレクト) と forward(フォワード) があります。それぞれの動作の違いとメリット、デメリットについてまとめておきます。 redirect forward ソース
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
旧EMOBILE LTEの回線でアプリのテストをしているときに謎の不具合として発見しました。 スピードテストや、普通のブラウジングは快適に行えているのに何故かzipファイルの転送時のみものすごく遅くなり、最初は自分のアプリの不具合を疑いましたがHTTP通信全般で発生するようです。 。 契約回線は旧EMOBILE LTEで、「当月のご利用通信量が10GB以上」で帯域制限を行うと公表されています。 テストした日までの通信量は10.588GBで、目安の通信量を超過している状態です。 この状態でHTTPによるリクエストを出すと、ファイル種類によって挙動が変わります。 月初めはどのような挙動になるか不明なので来月になったらやってみます。 以下実験結果です。 以下コマンドで1MBのダミーファイルを生成。 % dd if=/dev/zero of=test.zip bs=1M count=1 ファイルの
2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く