HTTP / 1.1 Os códigos de status 400 e 417, não podem escolher qual

Question

Fui referido aqui que pode ser de melhor ajuda, eu tenho um arquivo de processamento que lida com os dados enviados pelo usuário, antes disso, no entanto, ele compara a entrada do cliente com os valores esperados para garantir que nenhum cliente alteração de dados ao lado.

Eu posso dizer que não sei muito sobre os códigos de status HTTP, mas fiz algumas pesquisas sobre ele e escolho qual é o melhor para manuseio de entrada inesperado. Então eu inventei:

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 Solicitação incorreta sendo usada muito, no entanto, o que recebo da explicação é que o erro é devido a uma solicitação inexistente em vez de uma entrada ilegal.

Por outro lado, 417 Expectation Failed parece servir apenas para o meu uso, no entanto, eu nunca vi ou experimentei esse status de cabeçalho antes.

Preciso da sua experiência e opiniões, muito obrigado!

Para ver detalhadamente os rascunhos das páginas de formulário / processo e minhas experiências, siga este link.

Adição: Um outro motivo, porque eu quero isso é para evitar a manipulação do Google. Isso não só será usado no backend, mas também no frontend, onde a interação entre o convidado e o usuário será mostrada e o conteúdo da página será apresentado.

Acredito que *, Dar 200 OK ou 403 Códigos de status proibidos são válidos para páginas que existem ou que podem existir.

* Adição dois: Eu olhei em 417 e 100 agora, descobri que eles são parecidos com o que eu tento fazer (apenas pelo caso de processamento de upload, pelo menos), aqui: link

• ie: * Uma página da web com link para o site X com link seria indexado pelo Google desde cabeçalho HTTP é dado como OK.

SOLUÇÃO VIM A:

Na verdade, 404 é o que eu poderia estar acabando de novo. Eu só queria uma solução diferente que, se HTTP, desde, mas até agora parece 404 ainda é a melhor solução utilizável para isso, obrigado, tudo, minha pergunta encontrou a resposta.

    

Answer 1

Se os parâmetros para uma solicitação GET estiverem incorretos, a coisa canônica a ser feita é enviar um erro 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 conforme consultado no URI não foi encontrado.

Praticamente, se você quiser evitar coisas como navegadores ignorando sua página 404 e substituindo as suas próprias (eu estou olhando para o IE 9 e 10), você pode querer usar 200. Se você considera seu aplicativo como o recurso, 200 é apropriado; você consultou o aplicativo e ele retornou um resultado (que por acaso era um erro, mas não no nível HTTP). No entanto, esse uso não é muito RESTful.

    

Answer 2

O erro 417 deve ocorrer apenas quando o cliente enviou um cabeçalho HTTP Expect que o servidor não pôde atender, 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 erro 400 deve ser enviado apenas quando houver uma sintaxe incorreta na solicitação HTTP que o servidor não entende.

Nenhum desses é realmente apropriado para uma falha de validação na lógica do aplicativo, embora eu suponha que 400 seja um pouco mais apropriado.

O erro 403 que você estava pensando em usar em sua pergunta no Stack Overflow é a melhor opção na minha opinião.

I just used 403 Forbidden header when the expected values weren't found in the $_GET, but, when thought for, it isn't really an action that requires login(not for this, ofcourse a user have to login to view the admin panel in the first place), it's more like an unexpected value input.

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 soa exatamente como você deseja.

Isso tudo supõe que você deseja retornar um código de resposta 4xx ... 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 200 com o informações de erro no corpo.

    

Answer 3

Eu não consigo descobrir o que você está fazendo, no entanto, há uma opção adicional que você pode não ter considerado - 200 - OK. A razão é que você recebeu os dados corretamente, o problema é que ele não é válido para seu aplicativo, o que não é realmente um problema com o protocolo HTTP.

A rfc relevante aqui é rfc2616 . Você poderia usar 400, mas você precisa fornecer ao cliente a capacidade de modificar os dados, a partir do rfc

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

Em relação ao 417 o rfc diz

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

Se você não está usando o cabeçalho "Esperar", provavelmente não deve usar essa resposta.