Não consegui encontrar nenhuma documentação nas especificações HTTP que determinam se é aceitável gerar uma resposta HTTP incluir uma mensagem de erro legível (por exemplo, tipo de conteúdo: text / plain) se um cliente HTTP tiver feito uma solicitação HTTP inválida, e especificou um cabeçalho de solicitação que limita os tipos de conteúdo de resposta aceitáveis ​​usando um cabeçalho de aceitação.

Imagine um cliente de serviço da web REST emitindo uma solicitação GET inválida para "http: // myhost / validpath? IllegalRequestParameter = rubbish" e incluindo um cabeçalho de solicitação "Accept: application / xml" ou "Accept: application / vnd.ms-excel" .

O servidor responderia com um código de status HTTP na série 4XX ("400 Bad Request", neste caso). Mas como o serviço seria capaz de transmitir informações ao cliente sobre a causa do erro?

Eu vejo as seguintes opções:

Crie uma mensagem de erro em texto simples no conteúdo da resposta HTTP. Defina o cabeçalho de resposta "Content-type: text / plain" e inclua uma mensagem de erro descritiva no conteúdo da resposta. Isso, no entanto, quebraria a restrição "Aceitar" do cliente HTTP.

Não inclua um conteúdo de resposta HTTP. Isso é claramente válido, mas não é muito útil para o cliente que apenas sabe que ocorreu um "Erro do cliente", mas não tem como saber o motivo (e relatar o motivo em um arquivo de log do cliente).

Tente forçar uma mensagem de erro em um tipo MIME "Aceitável". Isso raramente é possível. Mesmo que a mensagem de erro possa ser construída como um tipo de aplicativo / xml válido, ela provavelmente quebraria um contrato de serviço da Web (por exemplo, conformidade com o XML Schema).

Minha pergunta é: a situação acima é governada por especificações / padrões HTTP existentes?

Referências:

Definições de Código de Status HTTP:http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlDefinições de campo de cabeçalho HTTPhttp://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html