Question

我遵循了本教程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

我没有想法......我真的需要一个json版本的错误让我的API工作......

Answer 1

我遇到了同样的问题，虽然你的问题已经很老了，但是symfony从那时起就碰到了几个版本，问题仍然存在，所以即使你不再需要知道它，也许是其他人将

您原来的问题可能是由here描述的错误导致的，但是在初始发布后没有太多关于它的问题。从那时起，整个代码库都得到了更新，所以当相同的症状再次出现时，错误就无关紧要了。我在这里发帖是因为这些天寻找答案的人可能会发现这个问题（正如我所做的那样:)。

即使直接从JsonResponse形成内核异常处理程序，它仍然会有Content-Type: text/html; charset=UTF-8。这让我非常难过，以至于我使用netcat来制作手动请求，而中间没有任何智能软件，事实证明在这种情况下，响应实际上有两个不同的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

现在，双重内容类型标题不是您每天看到的内容。似乎这是在Symfony\Component\Debug\ExceptionHandler类中实现的，该类仅用于调试模式。为了尽可能健壮，它首先呈现描述抛出异常的标准Symfony错误页面。渲染内容不会直接发回，而是利用PHP的输出缓冲功能来缓冲和存储生成的输出。然后它尝试从框架生成自定义错误页面。如果失败，则发送先前准备的消息。

然而，输出缓冲仅适用于消息内容，而不适用于标头 - 这些始终直接发送。此问题仅出现在调试环境中，并且出现错误的异常内容类型仅在WebAPI中很常见，其中调试模式可能很少使用。这使曝光表面相对较小，但如果需要测试同时提供WebAPI和最终用户界面的应用程序，则可能会出现问题。

在不修改内部Symfony文件的情况下解决此问题似乎不可行。输出控件位于symfony内核的深处，不提供任何配置。无论如何，我不相信这种解决方案的好处。如果有人能够向我解释在自定义异常处理程序中会发生什么情况会导致默认处理程序失败时无效？也许用户代码搞乱了ob_ *函数？

错误页面不遵循内容类型/格式

1 个答案: