“application/*+json”是 HTTP 中的有效 Accept 标头吗

Posted

技术标签:

【中文标题】“application/*+json”是 HTTP 中的有效 Accept 标头吗【英文标题】:Is "application/*+json" a valid Accept header in HTTP 【发布时间】:2018-06-24 22:55:43 【问题描述】:

java spring 框架的 http 客户端似乎默认发送这个 Accept 头:

Accept: text/plain, application/json, application/*+json, */*

我对“application/*+json”部分很好奇。我相信这样做的目的是匹配任何以 application/ 开头并以 +json 结尾的 mime 类型 - 例如。 application/vnd.api+json.

但是看着RFC 7231 section 5.3.2 它说:

media-range    = ( "*/*"
                      / ( type "/" "*" )
                      / ( type "/" subtype )
                      ) *( OWS ";" OWS parameter )

这似乎只允许使用 * 而不是子类型,而不是它的一部分 - 暗示“application/*+json”应该只匹配名称中实际上是 * 的 mime 类型。

mime 类型的“+”语法通常在 https://www.rfc-editor.org/rfc/rfc6839 中定义 - 但是其中似乎没有任何内容允许将其应用于 HTTP RFC 定义的通配符。

是否有其他一些 RFC 扩大了定义或正在发送错误的 Accept: 标头?

【问题讨论】:

【参考方案1】:

我相信答案是“不”。 HTTP 的允许值在https://www.greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.2 中定义,“*+json”不是有效的子类型(即使是,它也只会匹配子类型“*+json”,并非所有以“+json”结尾的子类型")。

【讨论】:

我倾向于同意:子类型的语法是tokens,没有办法表达层次结构。话虽如此,*+json 在语法上是正确的,但未注册为子类型。无论如何,application/*+json 将匹配该文字字符串,并且不会像 OP 预期的那样引发任何 globbing。

以上是关于“application/*+json”是 HTTP 中的有效 Accept 标头吗的主要内容,如果未能解决你的问题,请参考以下文章

“application/*+json”是 HTTP 中的有效 Accept 标头吗

content-type: text/json 和 application/json 之间的确切区别是啥?

什么是 axios.defaults.headers.post 'content-type' = 'application/json'

[转] $.ajax中contentType: “application/json” 的用法

无法使用 HTTP API 创建 Grafana 用户

使用请求正文从Microsoft Computer Vision调用Face API是“application / json”