2

私はこのチュートリアルhttp://symfony.com/doc/current/cookbook/controller/error_pages.htmlに従い、 app/Resources/TwigBundle/views/Exception/ 内に error.html.twig と error.json.twig を持っています

リクエストのコンテンツ タイプが application/json に設定されていても、すべてのエラーはデフォルトでエラー ページの html バージョンになります。

ルートのフォーマットも定義されています: http://symfonyinstall/api/v1/users.json

リクエストヘッダー:

Accept: application/json
Content-Type: application/json
Connection: keep-alive
Origin: chrome-extension: //rest-console-id
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko)           Chrome/18.0.1025.162 Safari/535.19

応答ヘッダー:

Status Code: 404
date: Sun, 29 Apr 2012 06:54:35 GMT
Content-Encoding: gzip
X-Powered-By: PHP/5.3.10
Transfer-Encoding: chunked
Connection: keep-alive
Server: nginx
Content-Type: text/html; charset=UTF-8
cache-control: no-cache

私はアイデアがありません...そして、APIが機能するにはエラーのjsonバージョンが本当に必要です...

4

1 に答える 1

0

私はちょうど同じ問題にぶつかりました.あなたの質問はかなり古く、symfony はそれ以来いくつかのバージョンを上げましたが、問題はまだ関連しています.

あなたの元の問題はおそらくここで説明されているエラーが原因でしたが、最初の投稿の後、それについてはあまり進んでいませんでした. その後、コードベース全体が更新されたため、同じ症状が再発しましたが、エラーは関係ありません。最近答えを探している人はおそらくこの質問を見つけるので、ここに投稿しています（私がしたように:)。

JsonResponseカーネル例外ハンドラから直接返す場合でも、 Content-Type: text/html; charset=UTF-8. これに非常に困惑したので、間にスマートなソフトウェアを介さずに netcat を使用して手動でリクエストを作成しました。そのような場合のレスポンスには、実際には 2 つの異なる Content-Type ヘッダーがあることがわかりました。

HTTP/1.0 500 Internal Server Error
Connection: close
X-Powered-By: PHP/5.5.9-1ubuntu4.17
Content-Type: text/html; charset=UTF-8
Cache-Control: private, must-revalidate
Content-Type: application/json
pragma: no-cache
expires: -1
X-Debug-Token: 775c55
X-Debug-Token-Link: http://127.0.0.1:8000/_profiler/775c55
Date: Thu, 27 Oct 2016 23:08:31 GMT

現在、二重の Content-Type ヘッダーは日常的に目にするものではありません。これはSymfony\Component\Debug\ExceptionHandler、デバッグモードでのみ使用されるクラスに実装されているようです。可能な限り堅牢にするために、最初に、スローされた例外を説明する標準の Symfony エラー ページをレンダリングします。レンダリングされたコンテンツは直接送り返されません。代わりに、PHP の出力バッファリング機能を利用して、生成された出力をバッファリングおよび保存します。次に、フレームワークからカスタム エラー ページを生成しようとします。これが失敗した場合、以前に準備されたメッセージが送信されます。

ただし、出力バッファリングはメッセージ コンテンツに対してのみ機能し、ヘッダーに対しては機能しません。これらは常に直接送信されます。この問題はデバッグ環境でのみ発生し、エラー時の異常なコンテンツ タイプは WebAPI でのみ一般的であり、デバッグ モードはほぼ間違いなくほとんど使用されません。これにより、露出面が比較的小さくなりますが、WebAPI とエンドユーザー インターフェイスの両方を提供するアプリケーションをテストする必要がある場合、これが問題になる可能性があります。

内部 Symfony ファイルを変更せずにこの問題を解決することは不可能のようです。出力制御は symfony カーネルの奥深くに位置し、設定を提供しません。とにかく、そのようなソリューションの利点については確信が持てません。失敗した場合にデフォルトのハンドラーを役に立たなくするカスタム例外ハンドラー中に何が起こったのか、誰かが私に説明できたら? ユーザーコードが ob_* 関数をいじっているのではないでしょうか?

于 2016-10-28T00:07:22.590 に答える