发送“415不支持的媒体类型”时指定支持的媒体类型

发布于 2024-09-11 13:24:09 字数 215 浏览 3 评论 0 原文

如果客户端将不支持的媒体类型的数据发送到 HTTP 服务器,服务器会返回状态“415 不支持的媒体类型"。但如何告诉客户端支持哪些媒体类型呢?是否有一个标准或至少是一个推荐的方法?或者只是将其作为文本写入响应正文?

If a clients sends data in an unsupported media type to a HTTP server, the server answers with status "415 unsupported media type". But how to tell the client what media types are supported? Is there a standard or at least a recommended way to do so? Or would it just be written to the response body as text?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

感性不性感 2024-09-18 13:24:10

Chris Shiflett 在他的书《HTTP 开发人员手册》第 81 页中解释了 415 的含义,然后他说:“HTTP 响应内容中使用的媒体类型应在 Content-Type 实体标头中指示。”

1)那么 Content-Type 是一个可能的答案吗?它可能是接受的内容类型的逗号分隔列表。这种可能性的明显问题是 Content-Type 是实体标头而不是响应标头。

2)或者这是书中的拼写错误?他真的想说“HTTP 请求”吗?

In his book "HTTP Developer's Handbook" on page 81 Chris Shiflett explains what a 415 means, and then he says, "The media type used in the content of the HTTP response should be indicated in the Content-Type entity header."

1) So is Content-Type a possible answer? It would presumably be a comma-separated list of accepted content types. The obvious problem with this possibility is that Content-Type is an entity header not a response header.

2) Or is this a typo in the book? Did he really mean to say "the HTTP request"?

長街聽風 2024-09-18 13:24:09

对于在这种情况下要做什么根本没有任何规范,因此期望实现无处不在。 (如果服务器的响应包含类似 Accept: 标头之类的内容,那么明智的做法是,因为即使当前方向错误,它也具有几乎正确的语义。)

There is no specification at all for what to do in this case, so expect implementations to be all over the place. (What would be sensible would be if the server's response included something like an Accept: header since that has pretty much the right semantics, if currently in the wrong direction.)

两仪 2024-09-18 13:24:09

我相信您可以使用 OPTIONS Http 动词来做到这一点。

如果您的场景适合特定用例,也可以使用状态代码 300 Multiple Choices。如果他们发送带有 application/xmlAccept 标头的请求,并且您只支持 text/plain 并且该表示存在于不同的 URL 中,那么您可以使用 300 进行响应,并在 Location 标头中提供该表示形式的 URL。我意识到这可能不完全适合您的问题,但这是另一种可能的选择。

根据 HTTP 规范:

10.4.7 406 Not Acceptable

请求标识的资源只能生成根据请求中发送的接受标头具有不可接受的内容特征的响应实体。

除非它是一个 HEAD 请求,否则响应应该包括一个包含可用实体特征和位置列表的实体,用户或用户代理可以从中选择最合适的一个。实体格式由 Content-Type 标头字段中给出的媒体类型指定。根据用户代理的格式和功能,可以自动执行最合适的选择。然而,本规范没有为这种自动选择定义任何标准。

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

I believe you can do this with the OPTIONS Http verb.

Also the status code of 300 Multiple Choices could be used if your scenario fits a certain use case. If they send a request with an Accept header of application/xml and you only support text/plain and that representation lives at a distinct URL then you can respond with a 300 and in the Location header the URL of that representation. I realize this might not exactly fit your question, but it's another possible option.

And from the HTTP Spec:

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.
暖阳 2024-09-18 13:24:09

太长;博士;
编辑生成的代理类以从 Microsoft.Web.Services3.WebServicesClientProtocol** 继承。

我在解决此错误时遇到了这个问题,所以我想我会帮助下一个可能会遇到这里的人,尽管不确定它是否回答了所述问题。当我不得不接管使用 WSE 和 MTOM 编码的现有解决方案时,我遇到了此错误。这是一个调用 Web 服务的 Windows 客户端。

到目前为止,客户端调用 Web 服务时会抛出该错误。
对我来说有助于解决该错误的方法是检查默认生成的 Web 服务代理类,该类显然是从 System.Web.Services.Protocols.SoapHttpClientProtocol 继承的。
本质上这意味着它实际上并没有使用 WSE3。

无论如何,我手动编辑了代理并将其更改为从 Microsoft.Web.Services3.WebServicesClientProtocol 继承。

顺便说一句,要在 VS 中查看生成的代理类,请单击 Web 参考,然后单击“显示所有文件”工具栏按钮。 Reference.cs 是一个快乐的地方!

希望有帮助。

tl;dr;
Edited the generated proxy class to inherit from Microsoft.Web.Services3.WebServicesClientProtocol**.

I came across this question when troubleshooting this error, so I thought I would help the next person who might come through here, although not sure if it answers the question as stated. I ran into this error when at some point I had to take over an existing solution which was utilizing WSE and MTOM encoding. It was a windows client calling a web service.

To the point, the client was calling the web service where it would throw that error.
Something that contributed to resolving that error for me was to check the web service proxy class that apparently is generated by default to inherit from System.Web.Services.Protocols.SoapHttpClientProtocol.
Essentially that meant that it didn't actually use WSE3.

Anyhow I manually edited the proxy and changed it to inherit from Microsoft.Web.Services3.WebServicesClientProtocol.

BTW, to see the generated proxy class in VS click on the web reference and then click the 'Show All Files' toolbar button. The reference.cs is da place of joy!

Hope it helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文