Если клиенты отправляют данные на неподдерживаемом носителе на HTTP-сервер, сервер отвечает со статусом «415 unsupported media type». Но как сообщить клиенту, какие типы носителей поддерживаются? Есть ли стандарт или, по крайней мере, рекомендуемый способ сделать это? Или это просто будет написано в орган ответа как текст?Укажите типы поддерживаемых носителей при отправке «415 неподдерживаемого типа носителя»
В этом случае нет никакой спецификации для того, что делать, поэтому ожидайте, что реализации будут повсюду. (Было бы разумно, если бы ответ сервера включал что-то вроде заголовка Accept:, поскольку он имеет почти правильную семантику, если в настоящее время находится в неправильном направлении.)
'Accept' заголовки от сервера к клиенту будут то, что я ищу. Я с нетерпением жду HTTP 1.2 ;-) – deamon
Я считаю, что вы можете сделать это с помощью глагола Http OPTIONS.
Также может использоваться код состояния 300 Multiple Choices, если ваш сценарий подходит для определенного варианта использования. Если они отправляют запрос с заголовком Accept с номером application/xml, и вы поддерживаете только text/plain, и это представление живет с отдельным URL-адресом, тогда вы можете ответить 300 и в заголовке местоположения URL-адресом этого представления. Я понимаю, что это может не соответствовать вашему вопросу, но это еще один возможный вариант.
И с HTTP Spec:
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.
Это сработало бы, за исключением того, что там нет спецификации содержания ответа. Это может быть вам сказать, но как вы узнали? –
Но какой заголовок следует использовать, чтобы сказать, какие типы носителей поддерживаются? Затем этот заголовок можно использовать в ответе '415'. Обычно 'ОПЦИИ 'используется только для определения того, какие методы поддерживаются. – deamon
'406' не имеет значения, так как это связано с несоответствием типа для * response *. '415' - это то, что вы получаете, когда сервер не может обрабатывать тип данных в теле * request *. (Я только что имел дело с этим в контексте веб-службы RESTful, которую я разрабатываю, поэтому я уверен, что это правильная интерпретация.) Проблема в том, что сервер не может обрабатывать сообщение, а клиент - уже отправив его; ошибка - единственная возможность (и нет способа дать правильный машиночитаемый способ сказать, что бы сработало). –
В своей книге «Руководство разработчика HTTP» на странице 81 Chris Шифлетт объясняет, что означает 415, а затем он говорит: «Тип содержимого, используемый в содержании ответа HTTP, должен указываться в заголовке объекта Content-Type».
1) Таким образом, Content-Type - это возможный ответ? Предположительно, это будет список разделяемых типов содержимого, разделенный запятыми. Очевидная проблема с этой возможностью заключается в том, что Content-Type является заголовком объекта, а не заголовком ответа.
2) Или это опечатка в книге? Он действительно хотел сказать «HTTP-запрос»?
Нет, нет. «Content-Type» * always * идентифицирует тип полезной нагрузки сообщения, как для запросов, так и для ответов (за исключением ответов HEAD ...). –
tl; dr; Отредактирован сгенерированный класс прокси для наследования от Microsoft.Web.Services3.WebServicesClientProtocol **.
Я столкнулся с этим вопросом при устранении этой ошибки, поэтому я подумал, что помогу следующему человеку, который может сюда приехать, хотя и не уверен, отвечает ли он на вопрос, как указано. Я столкнулся с этой ошибкой, когда в какой-то момент мне пришлось взять на себя существующее решение, использующее кодировку WSE и MTOM. Это был клиент Windows, вызывающий веб-службу.
К моменту, клиент вызывал веб-службу, где он выдавал бы эту ошибку. Что-то, что способствовало разрешению этой ошибки для меня, было проверить класс прокси-сервера веб-службы, который по-видимому генерируется по умолчанию для наследования с System.Web.Services.Protocols.SoapHttpClientProtocol. По сути, это означало, что на самом деле он не использовал WSE3.
Anyhow Я вручную отредактировал прокси-сервер и поменял его наследовать от Microsoft.Web.Services3.WebServicesClientProtocol.
BTW, чтобы увидеть сгенерированный прокси-класс в VS, щелкните по веб-ссылке, а затем нажмите кнопку «Показать все файлы» на панели инструментов. Ссылка.cs - это место радости!
Надеюсь, это поможет.
Вы ожидаете заголовок ответа Accept, но Accept может использоваться только для запросов. –