エラーページがあっても、私はこのチュートリアル、<a href="http://symfony.com/doc/current/cookbook/controller/error_pages.html" rel="nofollow">http://symfony.com/doc/current/cookbook/controller/error_pages.html</a>に続くコンテンツタイプ/フォーマット

Question

を以下、アプリ/リソース/ TwigBundle /ビュー/例外/

内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バージョンが本当に必要です...

Answer 1

私は同じ問題にぶつかりました。あなたの質問はかなり古く、symfonyはそれ以来いくつかのバージョンを打ちましたが、問題はまだ関連しています。それをもう知る必要がなくても、他の誰かがそうするでしょう。

元の問題は、hereと記載されているエラーによって引き起こされる可能性がありますが、最初の投稿後にはそれほど進んでいませんでした。それ以来、コードベース全体が更新されたため、同じ現象が再現されますが、エラーは関連しません。私はここにそれを掲示しています。なぜなら、最近誰かが答えを探しているので、おそらくこの質問を見つけるでしょう（私が行ったように:)。

JsonResponseを退却させても、直接カーネル例外ハンドラを形成しても、まだContent-Type: text/html; charset=UTF-8になります。

今

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 

、ダブル：これは私がそれらの間の任意のスマートソフトウェアなしで手動で要求を行うためのnetcatを使用し、そしてそれは、このような場合の応答は、実際には2つの異なるのContent-Typeヘッダを持っていることが判明したことをそんなに困惑しましたContent-Typeヘッダーは、あなたが毎日見るものではありません。これはデバッグモードでのみ使用されるSymfony\Component\Debug\ExceptionHandlerクラスで実装されているようです。できるだけ頑強にするために、最初にスローされた例外を記述する標準のSymfonyエラーページを表示します。レンダリングされたコンテンツは直接返送されるのではなく、代わりにPHPの出力バッファリング機能を利用して、生成された出力をバッファして格納します。次に、フレームワークからカスタムエラーページを生成しようとします。これが失敗した場合は、事前に準備されたメッセージが送信されます。

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

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