“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” 的用法
使用请求正文从Microsoft Computer Vision调用Face API是“application / json”