錯誤頁面不下列內容類型/格式

我跟着這個教程，http://symfony.com/doc/current/cookbook/controller/error_pages.html，並且有應用程序/資源/ 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

我出出主意......我真的需要一個JSON版本的錯誤爲我的API工作...

來源

2012-04-29 Otto Yiu

看起來我們需要更多信息才能找到問題的根源。如果您的模板具有正確的命名，則在正確的文件中，Symfony應自動找到它。你應該檢查以確保你的error.json。樹枝模板沒有任何錯誤，它確實是正確命名（尾隨或前導空格是對一些文件系統有效，可能很難看到）。爲了使事情更容易調試，你可能想直接擴展默認ExceptionController，看看請求的輸出:: getRequestFormat（），看看你的請求被顯示爲JSON。 – 2016-05-16 17:59:23

我剛剛遇到同樣的問題，雖然你的問題已經很老了，並且自那時以來symfony碰到了一些版本，但問題仍然相關，所以即使你不再需要了解它，也許別人會這樣做。

您的原始問題很可能是由錯誤描述here引起的，但是在初始發佈後沒有多少內容出現。從那時起，整個代碼庫都進行了更新，所以當相同的症狀再次出現時，錯誤就沒有關係。我在這裏發佈它，因爲任何人今天都在尋找答案，可能會發現這個問題（正如我所做的:)。

即使直接形成JsonResponse形成內核異常處理程序，它仍然會有Content-Type: text/html; charset=UTF-8。這難倒了我這麼多，我用netcat來使兩者之間沒有任何智能軟件的手動請求，而且事實證明，在這種情況下，響應有實際上是兩個不同的內容類型標頭：

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

現在，雙內容類型標題不是你每天都看到的。看起來這是在僅用於調試模式的Symfony\Component\Debug\ExceptionHandler類中實現的。爲了儘可能健壯，它首先呈現描述拋出的異常的標準Symfony錯誤頁面。渲染的內容不會直接發回，而是利用PHP的輸出緩衝功能緩衝並存儲生成的輸出。然後它嘗試從框架生成自定義錯誤頁面。如果失敗，則發送先前準備好的消息。

然而，輸出緩衝僅適用於消息內容，而不適用於頭部 - 這些總是直接發送。此問題僅出現在調試環境中，並且出現異常的錯誤內容類型僅在WebAPI中很常見，其中調試模式可能無用。這使得曝光表面相對較小，但如果提供WebAPI和最終用戶界面的應用程序需要測試，這可能會成爲一個問題。

解決此問題而不修改內部Symfony文件似乎不可能。輸出控制位於symfony內核的深處，不提供任何配置。無論如何，我不相信這種解決方案的好處。如果任何人都可以向我解釋在自定義異常處理程序中會發生什麼情況，使默認處理程序無用以防萬一失敗？也許用戶代碼搞亂了ob_ *函數？

來源

2016-10-28 00:07:22

錯誤頁面不下列內容類型/格式

回答

相關問題