ポストサイズの制限超過に遭遇してしまいました。PHP、おまえだったのか。さきほどの制限超過エラーは、php.iniで設定したpost_max_sizeを超えていたためです。sapi_activate。このリクエストの初期化処理にてpost_max_sizeなどの最大サイズのチェックが働いているというわけです。受け取ったデータをどのように変換しているかポイントを確認します。ディレクティブなどがあります。POSTメソッドの場合の$_POSTへの変換があります。しているんだなってことが見て取れるかと思います。$_SERVER変数とリクエストヘッダーについて振り返ってみましょう。ヘッダーが"HTTP_”プリフィクスなどをつけているのは、これはPHPに限らないのですがCGIの環境変数由来です。つねに$_SERVERというグローバル変数を参照されるとして作成されるのは非効率でしょう。timeに作成されるようになりました。プロトコル上我々は知っっているはずですが、いわゆる手続き型のプログラムコードにて条件分岐が複雑化していった結果、億劫な場面に遭遇します。ほかにもPHPで用意されているAPI利用時には、つらいなあという所があると思います。スーパーグローバルを直に触るのはつらいheader()を先に呼ばなきゃいけないのがつらいファイル配列操作がつらいリクエストURIの操作がつらいといった所です。リクエストオブジェクトを受け取りレスポンスを織り込むということからプロジェクトの起動ポイントでは、このようにディスパッチのシグネチャが用意されています。とりくめるようになった訳です。sizeの問題に出くわした方はいるんじゃないでしょうか。いわゆる手続き型にて、echoをつなげていく問題では表出されなかったことですが、多く広まっていたHTTPメッセージコンポーネントやテンプレートエンジンでは今度は出力バッファについてさいなまれるようになりました。多くの実装で見られたHTTPレスポンスでのボディの取得は、スカラー、のstringをとる形でした。・メモリを制限なく消費する可能性という点があります。Apacheの場合、LimitRequestBodyにて許可バイト数設定しています。すると、getContent()にてコールバックを許容すればいいじゃないかと思う方もいるかも知れませんが、そうすると戻り値の方が一致しません。・そして次に、これはStreamリソースを利用するという発想が抜けていることを意味します。これはHTTPクライアントライブラリの実装を確認すればstream_copy_to_streamの利用を確認もできるわけです。file_get_contents()をわけもわからず使っている可能性があります。PHPのレスポンスの出力はどう行われてるか、ざっくりとですが確認してみましょう。さきほどまででの流れの図ではリクエスト取得の箇所としてrequest_startupを見ていただきました。outputの際には、request_shut_downにて出力バッファリングのスタックから出力が行われいます。出力バッファリング、ここで改めて基本的なところを振り返ってみましょう。標準の設定では、echoがあれば直ちに送信や文字列すべてを出力をしません。引数、またはphp.iniでのoutput_handlerの指定により、出力バッファの内容を操作できます。Viewレンダラーでの応用です。ob_get_contents()を行っているライブラリが多く見られます。利用により、メモリ利用量を抑えレスポンス出力時に処理を実行することは可能でしょう。レスポンスボディ作成時の例外(DBコネクションエラーなど)などを考慮すると一度テンポラリーに書き出しておき、そのストリームリソースを再度渡すなどの対応も考慮すべきではないでしょうか。PHPにてレスポンスを返却するのではなく、apacheのx-senm-fileなどを利用するという戦略の持ち方もあるでしょう。PHP開発者はHTTPメッセージコンポーネントを使いたいという場合に、頭を抱えてしまうことになります。いくつかあげますと、このようなHTTPコンポーネントがあげられます。シンドロームとかと何が違うんでしょうか。その観点から、このミドルウェアとして最近PHP界隈にて取沙汰されているアプローチがあります。このようにHTTPメッセージを受け取り、かつ処理をパイプできるようにするということです。いったミドルウェア構成ということです。ここでは、メッセージボディにはストリームを使っているということも着目してください。PSR-7とミドルウェアについてポイントを見ましょう。これは、もしかたら不純物なものを求めるひとには邪悪に見えるかもしれません。今は、php-figという場で新しいPSRとしてミドルウェアシグネチャの要望があがっていますが、ミドルウェアシグネチャでの議論・検討の余地があります。いう所が考えられます。今までストリーム利用という点で、PSR-7に触れましたが、こんな意見もあります。PSR-7では、主にエラー処理などの対応のためにもメッセージをStreamInterfaceとして定義しているのですが、ミスリーディングな名前でもあります。個人的には内部はstreamリソースでも名前はbufferなになになインターふぇぃす名にしとけばよかったのかな、とは思ったりしてます。HTTPリクエストに対し、どうHTTPレスポンスを返すか?データの流れはどのような工夫が必要だったか?PHP内部と周辺プロジェクトの状況を簡単に俯瞰してみました。普段のコーディングでは内部の動作についてはあまり意識していないかも知れません。現実的な問題(アプリケーションロジック)に専念するためにも、再度振り返っていただければと思います。え、気合の入ってないもの発表してどうするの?。言ってもカンファレンス福岡・勉強会@東京では、難しいとの反応いただいておりましたのですが、発表の分かりやすさに私なりの苦心の結果ということでご理解いただければと思います。カンファレンス福岡の話となりますが、特にスタッフの方には私の「OpenOfficeのノートってどうすればいいか分からないナリー」な所をサポートしていただいたところなど再度お礼申し上げます。mod_request_dumperも拝見していたので松本亮介さんの発表を聴けたので良かったです。FrameworkでのHydratorやSymfonyでのSerializerなど、ハイドレーションについて思う所はあるのですが、この話はまた今度。PHP勉強会@東京では、カンファレンスでのスライドにちょっと手を入れつつでの発表をいたしました。sasezakiカンファレンス福岡での質問については末に捕捉もしておりますので、カンファレンス福岡にて話を聴かれた方も確認いただければとおもいます。uzullaさんの質問の箇所の追記は勉強会@東京の方々には余計頭混乱させたかと思います。察して頂くような感じですみません。伝わるか自信ないのですが、ちょっと長文なのでエントリでおこしました。――Rubyの実例から学ぶ。読んだこともあってかHTTPメッセージについてのAPIについての考察・主張をしております。(勉強会などでの発表に講師としての説明を求める人もいるかも知れませんが、私は基本的に主張をしに行ってます。)今回の発表では、HTTPメッセージでのデータの流れでのAPIを主軸にしていましたので、ちょっとスコープ外でした。2016ところで、スライドの画像について、質問頂いたのですがイラストわんパグぴよたそのものを主に利用させてもらいました。ありがとうございます。(有名となりすぎた「いらすとや」の画像はラクダだけ使っています。Meetupで話をしてきました。利用はてなブログをはじめよう!sasezakiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。