Укажите поддерживаемые типы мультимедиа при отправке 415 неподдерживаемого типа мультимедиа

В этом случае нет никакой спецификации того, что делать, поэтому ожидайте, что реализации будут повсюду. (Было бы разумно, если бы ответ сервера включал что-то вроде заголовка Accept:, поскольку он имеет в значительной степени правильную семантику, если в настоящее время в неправильном направлении.)

Я считаю, что вы можете сделать это с помощью глагола OPTIONS Http.

Также можно использовать код состояния 300 Multiple Choices, если ваш сценарий соответствует определенному варианту использования. Если они отправляют запрос с заголовком Accept из application/xml, а вы поддерживаете только text/plain и это представление живет по отдельному URL-адресу, вы можете ответить 300 и в заголовке Location URL-адрес этого представления. Я понимаю, что это может не совсем соответствовать вашему вопросу, но это еще один возможный вариант.

И из спецификации HTTP:

10.4.7 406 Неприемлемо

Ресурс, идентифицированный запросом, способен генерировать только объекты ответа, характеристики контента которых неприемлемы в соответствии с заголовками принятия, отправленными в запросе.

Если это не был запрос 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.

тл;др; Отредактирован сгенерированный класс прокси, чтобы он наследовался от Microsoft.Web.Services3.WebServicesClientProtocol**.

Я столкнулся с этим вопросом при устранении этой ошибки, поэтому я подумал, что помогу следующему человеку, который может прийти сюда, хотя и не уверен, что он отвечает на поставленный вопрос. Я столкнулся с этой ошибкой, когда в какой-то момент мне пришлось взять на себя существующее решение, в котором использовалось кодирование WSE и MTOM. Это был клиент Windows, вызывающий веб-службу.

К слову, клиент вызывал веб-службу, где он выдавал эту ошибку. Что-то, что способствовало устранению этой ошибки для меня, заключалось в проверке прокси-класса веб-службы, который, по-видимому, создается по умолчанию, чтобы наследоваться от System.Web.Services.Protocols.SoapHttpClientProtocol. По сути, это означало, что на самом деле он не использовал WSE3.

В любом случае я вручную отредактировал прокси-сервер и изменил его, чтобы он наследовался от Microsoft.Web.Services3.WebServicesClientProtocol.

Кстати, чтобы увидеть сгенерированный прокси-класс в VS, щелкните веб-ссылку, а затем нажмите кнопку «Показать все файлы» на панели инструментов. Reference.cs — это место радости!

Надеюсь, поможет.

В своей книге «Руководство разработчика HTTP» на странице 81 Крис Шифлетт объясняет, что означает ошибка 415, а затем добавляет: «Тип носителя, используемый в содержимом ответа HTTP, должен быть указан в заголовке объекта Content-Type».

1) Так возможен ли ответ Content-Type? Предположительно, это будет список допустимых типов контента, разделенных запятыми. Очевидная проблема с этой возможностью заключается в том, что Content-Type является заголовком сущности, а не заголовком ответа.

2) Или это опечатка в книге? Он действительно хотел сказать «HTTP-запрос»?