php frameworks
1.0.0
ミドルウェアは、別々の、しばしば複雑で既に既存のプログラムを「接着」するのに役立つソフトウェアの一般的な用語です。ミドルウェアに頻繁に接続されているソフトウェアコンポーネントには、エンタープライズアプリケーションとWebサービスが含まれます。
参照：
* http://searchsoa.techtarget.com/definition/middleware
* http://www.webopedia.com/TERM/M/middleware.html
* http://www.softwareag.com/blog/reality_check/index.php/integration-insights/middleware-for-my-mom-or-kids-guide-to-what-i-do/
* http://www.networkcomputing.com/netdesign/cdmwdef.htm
* https://en.wikipedia.org/wiki/Middleware
ミドルウェアとは何ですか？
ミドルウェアは、リクエストと応答の間に存在するコードであり、着信要求を実行し、それに基づいてアクションを実行し、応答を完了するか、キューの次のミドルウェアに委任されます。
https://github.com/zendframework/zend-stratigility/blob/master/doc/book/middleware.md
HTTPミドルウェアは、アプリケーションを入力するHTTP要求をフィルタリングするための便利なメカニズムを提供します。たとえば、Laravelには、アプリケーションのユーザーが認証されていることを検証するミドルウェアが含まれています。ユーザーが認証されていない場合、ミドルウェアはユーザーをログイン画面にリダイレクトします。ただし、ユーザーが認証されている場合、ミドルウェアはリクエストをアプリケーションにさらに進めることができます。
http://laravel.com/docs/master/middleware
Silexを使用すると、コードを実行できます。これにより、MiddleWaresを介したリクエストの処理中に異なる段階でデフォルトのSilex動作が変更されます。
http://silex.sensiolabs.org/doc/middlewares.html
ミドルウェアの目的は、スリムアプリケーションが呼び出される前および/または後にアプリケーション環境、要求、および応答を検査、分析、または変更することです。
http://docs.slimframework.com/middleware/overview/
すべてのHTTPメッセージは、使用されているHTTPプロトコルバージョン、ヘッダー、およびメッセージ本文で構成されています。リクエストは、リクエストを作成するために使用されるHTTPメソッドと、リクエストが行われるURIを含めるようにメッセージに基づいています。応答には、HTTPステータスコードと理由フレーズが含まれます。
...
あなたがプログラマーであるかどうかにかかわらず、あなたはそれをウェブ上のどこでも見ました。この瞬間、ブラウザのアドレスバーは、「http：//」で始まるものを示しています。あなたの最初のHello Worldスクリプトでさえ、あなたがそれを認識せずにHTTPヘッダーを送信しました。この記事では、HTTPヘッダーの基本と、Webアプリケーションでそれらをどのように使用できるかについて学びます。
サーバーがクライアントに送り返すHTTP応答には、応答の本体のコンテンツのタイプ、応答を送信したサーバー、応答が送信されたときにボディ内のバイトの数などを識別するヘッダーが含まれています。ほとんどのWebアプリケーションは、ヘッダー自体を設定する必要はありません。ただし、HTMLではないものを送り返したり、ページの有効期限を設定したり、クライアントのブラウザをリダイレクトしたり、特定のHTTPエラーを生成したりする場合は、Header（）関数を使用する必要があります。
*How to See HTTP Headers*
* Firebug extensions to analyze HTTP headers.
1. Turn in Firebug
2. Click Net
3. Click Headers
Ref:
* http://docstore.mik.ua/orelly/webprog/php/ch07_05.htm
* http://code.tutsplus.com/tutorials/http-headers-for-dummies--net-8039
*Headers already sent: Why does it happen?*
To understand why headers must be sent before output it's necessary to look at a typical HTTP response. PHP scripts mainly generate HTML content, but also pass a set of HTTP/CGI headers to the webserver:
HTTP/1.1 200 OK
Powered-By: PHP/5.3.7
Vary: Accept-Encoding
Content-Type: text/html; charset=utf-8
<html><head><title>PHP page output page</title></head>
<body><h1>Content</h1> <p>Some more output follows...</p>
and <a href="/"> <img src=internal-icon-delayed> </a>
The page/output always follows the headers. PHP has to pass the headers to the webserver first. It can only do that once. After the double linebreak it can nevermore amend them.
When PHP receives the first output (print, echo, <html>) it will flush all collected headers. Afterwards it can send all the output it wants. But sending further HTTP headers is impossible then.
PHPには、HTTPメッセージのサポートが組み込まれていません。
...
PHPストリームは、HTTPリクエストを送信するための最も便利でユビキタスな方法ですが、SSLサポートの適切な構成に関して多くの制限をもたらし、ヘッダーなどの設定に関する面倒なインターフェイスを提供します。 Curlは完全で拡張された機能セットを提供しますが、デフォルトの拡張機能ではないため、多くの場合存在しません。 HTTP拡張は、Curlと同じ問題と、従来の使用例がはるかに少ないという事実に苦しんでいます。
最新のHTTPクライアントライブラリのほとんどは、実装を抽象化する傾向があり、上記のレイヤーのいずれかで実行されている環境で作業できるようにします。
注：
cURL allows you to connect and communicate to many different types of servers with many different types of protocols.
(http://php.net/manual/en/intro.curl.php)
PHPは、サーバーAPI（SAPI）を使用して、着信HTTPリクエスト、元sの入力を解釈し、スクリプトへの処理を渡します。元のSAPIデザインには、リクエストデータをマーシャリングして環境変数に押し込んでからスクリプトに渡す前に、それを環境変数にプッシュするCommon Gatewayインターフェイスをミラーリングします。その後、スクリプトは、リクエストを処理して応答を返すために、環境変数から引き出されます。
PHPのSAPIデザインは、Cookie、クエリ文字列引数、SuperGlobals（それぞれ$ _Cookie、$ _GET、$ _POST）を介したURLエンコードの投稿コンテンツなどの一般的な入力ソースを要約し、Web開発者に便利な層を提供します。
...
スーパーグロバルの直接使用には多くの懸念があります。第一に、これらは可変であるため、ライブラリとコードが値を変更し、アプリケーションの状態を変更することが可能になります。さらに、SuperGlobalsはユニットと統合テストを困難で脆くし、コードの品質劣化につながります。
...
最後に、サーバー側の応答に関しては、PHPは独自の方法で取得されます。Header（）への呼び出しの前に放出されるコンテンツは、その呼び出しがNO-OPになります。エラー報告設定に応じて、これは多くの場合、ヘッダーや応答ステータスが正しく送信されないことを意味します。これを回避する1つの方法は、PHPの出力バッファリング機能を使用することですが、出力バッファーのネストは問題があり、デバッグが困難になる可能性があります。したがって、フレームワークとアプリケーションは、一度に放出できるヘッダーとコンテンツを集約するための応答抽象化を作成する傾向があります - これらの抽象化はしばしば互換性がありません。
Ref: http://www.php-fig.org/psr/psr-7/meta/
SuperGlobals変数（$ _GETおよび$ _POST）を使用できますが、それらはグローバルな可変状態です。このユニットとコードの統合テストに加えて、困難になります。
これらの理由により、多くのPHPフレームワークは、HTTPメッセージを表すために棄権を実装することを決定しました（たとえば、symfony httpfoundationまたはzend httpを参照）。
これにより、アプリケーションがHTTPメッセージの特定の実装に基づいている状況につながり、他のフレームワークを使用して構築されたプロジェクトではほとんど使用できませんでした。
これが、共通のインターフェイスのセットが、HTTPメッセージを抽象化し、フレームワークの不可知論的な方法で連携するのに役立つ理由です。
Ref: http://stackoverflow.com/questions/32805681/php-why-http-message-implementations
HTTPは、ファイルだけでなく、リソースを送信するために使用されます。リソースとは、URLで識別できる情報の一部です（URLのRです）。最も一般的な種類のリソースはファイルですが、リソースは動的に生成されたクエリ結果、CGIスクリプトの出力、いくつかの言語で利用可能なドキュメント、または他の何かである場合もあります。
参照：
* http://www.w3schools.com/tags/ref_httpmessages.asp
* https://www.jmarshall.com/easy/http/
