Eu tenho um arquivo de processamento que trata dos dados enviados pelo usuário, antes disso, porém, ele compara a entrada do cliente com os valores esperados para garantir que não haja alteração nos dados do lado do cliente.
Posso dizer que não sei muito sobre códigos de status HTTP, mas fiz algumas pesquisas sobre isso e para escolher qual é o melhor para tratamento de entradas inesperadas. Então eu pensei:
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
Agora, não posso ter certeza de qual usar, já vi 400 Bad Request sendo muito usado, no entanto, o que recebo da explicação é que o erro se deve a uma solicitação inexistente e não a uma entrada ilegal.
Por outro lado, 417 Expectation Failed parece adequado para meu uso, no entanto, nunca vi ou experimentei esse status de cabeçalho antes.
Preciso de sua experiência e opiniões, muito obrigado!
Para obter detalhes completos dos rascunhos de páginas de formulário/processo e meus experimentos, sigaesse link.
Adição: outra razão pela qual desejo isso é evitar a manipulação do Google. Isto não será usado apenas no backend, mas também no frontend onde será mostrada a interação convidado/usuário e o conteúdo da página será apresentado.
Eu acredito*, os códigos de status Dando 200 OK ou 403 Proibido são válidos para páginas que existem ou podem existir.
*Adição dois: examinei 417 e 100 agora e descobri que eles são semelhantes ao que tento fazer (apenas para casos de processamento de upload, pelo menos), aqui: http://benramsey.com/blog/2008/04/http-status-100-continue/
- ou seja:*Uma página da web com link para o site X comhttp://www.example.com/page.php?query=lol&query2=failseria indexado pelo Google, pois o cabeçalho HTTP é fornecido como OK.
SOLUÇÃO QUE CHEGUEI:
Na verdade, 404 é o que posso acabar novamente. Eu só queria uma solução diferente dessa, se o HTTP fornecesse, mas até agora parece que 404 ainda é a melhor solução utilizável para isso, obrigado a todos, minha pergunta encontrou a resposta.
Responder1
Se os parâmetros de uma solicitação GET estiverem incorretos, a coisa canônica a fazer é enviar de volta um 404 (não encontrado) ou 200 (OK).
A maneira RESTful de usar solicitações GET é consultar um recurso (obter algo). Portanto, se os parâmetros necessários não corresponderem a um recurso existente (porque estão incompletos), você poderá dizer com precisão que o recurso consultado no URI não foi encontrado.
Praticamente, se você quiser evitar coisas como navegadores ignorando sua página 404 e substituindo a sua própria (estou olhando para o IE 9 e 10), você pode querer usar 200. Se você considera que seu aplicativo é o recurso, 200 é apropriado; você consultou o aplicativo e ele retornou um resultado (que foi um erro, mas não no nível HTTP). Porém, esse uso não é muito RESTful.
Responder2
O 417erro só deve ocorrer quando o cliente enviou um Expectcabeçalho HTTP que o servidor não conseguiu cumprir, o que não se relaciona de forma alguma com as "entradas esperadas" do aplicativo na solicitação. Não use isso.
Por outro lado, um 400erro deve ser enviado somente quando houver uma sintaxe incorreta na solicitação HTTP que o servidor não entenda.
Nenhum deles é realmente apropriado para uma falha de validação na lógica do aplicativo, embora eu suponha que 400seja um pouco mais apropriado.
O 403erro que você estava pensando em usar na sua pergunta no Stack Overflow é a melhor opção na minha opinião.
Acabei de usar o cabeçalho 403 Forbidden quando os valores esperados não foram encontrados em $ _GET, mas, quando pensado, não é realmente uma ação que requer login (não para isso, é claro que um usuário precisa fazer login para visualizar o administrador painel em primeiro lugar), é mais como uma entrada de valor inesperada.
Você está pensando em 401, que é o código de resposta utilizado quando a autenticação é necessária. 403é uma negação genérica da solicitação, que parece exatamente o que você deseja.
Tudo isso pressupõe que você deseja retornar um 4xxcódigo de resposta.. o que faz sentido para uma API.. mas para uma página HTML voltada para o usuário, é mais provável que você queira enviar um 200com as informações de erro no corpo.
Responder3
Não consigo entender o que você está fazendo, mas há uma opção adicional que você pode não ter considerado - 200 - OK. O motivo é que você recebeu os dados corretamente, o problema é que eles não são válidos para o seu aplicativo, o que não é realmente um problema com o protocolo HTTP.
O rfc relevante aqui érfc2616. Você poderia usar 400, mas precisará fornecer ao cliente a capacidade de modificar os dados, a partir do rfc
10.4.1 400 Solicitação incorreta
A solicitação não pôde ser compreendida pelo servidor devido à sintaxe malformada. O cliente NÃO DEVE repetir a solicitação sem modificações.
Em relação ao 417, a RFC diz
10.4.18 417 Expectativa Falha
A expectativa fornecida em um campo de cabeçalho de solicitação Expect (consulte a seção 14.20) não pôde ser atendida por este servidor ou, se o servidor for um proxy, o servidor possui evidências inequívocas de que a solicitação não pôde ser atendida pelo servidor do próximo salto .
portanto, se você não estiver usando o cabeçalho expect, provavelmente não deveria usar esta resposta.