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?
相关问题
- Angular RxJS mergeMap types
- Design RESTful service with multiple ids
- Axios OPTIONS instead of POST Request. Express Res
- Plain (non-HTML) error pages in REST api
- Google Apps Script: testing doPost() with cURL
相关文章
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
- send redirect and setting cookie, using laravel 5
- Is a unicode user agent legal inside an HTTP heade
- Got ActiveRecord::AssociationTypeMismatch on model
- Multiple parameters in AngularJS $resource GET
- git: retry if http request failed
- Flutter - http.get fails on macos build target: Co
- Global Exception Handling in Jersey & Spring?
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 anAccept
header ofapplication/xml
and you only supporttext/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.
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.
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.)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"?