请求JSON文件携带Accept: application/json报资源无法展示错误原因咨询

问题原因详解 #

1. 所谓“头顺序影响结果”是curl参数使用错误导致的假象 #

curl 的 --header/-H 参数每次仅支持定义单个HTTP请求头。你测试时把两个头用分号拼接放在同一个 --header 参数中，本质不是传递了两个独立的头：

• 当你写 --header "Content-Type: application/json;Accept: application/json" 时，实际仅传递了一个 Content-Type 头，值为 application/json;Accept: application/json
• 当你把Accept放前面时，实际仅传递了一个 Accept 头，值为 application/json;Content-Type: application/json
  两种情况传递的请求头完全不同，自然返回结果不同，和IIS对请求头的排序处理没有任何关系。

2. 仅携带Accept: application/json报错的原因 #

json.schemastore.org 站点运行在IIS 10服务器上，存在配置缺陷：站点的请求筛选模块配置了错误的拦截规则，当请求的Accept头仅明确指定application/json时，规则会误判客户端不支持接收.json后缀的资源，因此返回你看到的错误提示。
而默认不带自定义Accept头时，curl 会自动携带Accept: */*，这个通配符会绕过该错误拦截规则，因此可以正常拿到JSON内容，同时响应头会正确返回Content-Type: application/json。

3. 无请求体时Content-Type头生效的原因 #

该IIS站点的拦截规则存在逻辑漏洞：只要请求中存在Content-Type头，就会优先根据该头的内容走对应的处理逻辑，跳过针对Accept头的错误校验。所以哪怕是GET请求没有请求体，携带Content-Type头也会刚好绕开拦截规则，属于站点配置缺陷导致的非预期表现。

解决方案 #

如果你使用@actions/http-client调用该接口，任选一种方案即可：

• 不主动设置Accept头，使用客户端默认的Accept: */*配置，站点会正常返回JSON内容
• 如果业务要求必须显式设置Accept: application/json，额外添加一个Content-Type: application/json头即可绕过拦截

内容的提问来源于stack exchange，提问作者webstackdev