Tengo un archivo de procesamiento que maneja los datos enviados por el usuario; antes de eso, sin embargo, compara la entrada del cliente con los valores esperados para garantizar que no haya cambios en los datos del lado del cliente.
Puedo decir que no sé mucho sobre los códigos de estado HTTP, pero investigué un poco al respecto y elegí cuál es el mejor para el manejo de entradas inesperadas. Entonces se me ocurrió:
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
Ahora, no puedo estar realmente seguro de cuál usar, he visto que se usa mucho 400 Bad Request, sin embargo, lo que entiendo de la explicación es que el error se debe a una solicitud inexistente en lugar de una entrada ilegal.
Por otro lado, 417 Expectation Failed parece adecuado para mi uso; sin embargo, nunca antes había visto ni experimentado este estado de encabezado.
Necesito vuestra experiencia y opiniones, muchas gracias!
Para obtener información detallada completa sobre los borradores de las páginas de formulario/proceso y mis experimentos, sigaeste enlace.
Además: otra razón por la que quiero esto es para evitar la manipulación de Google. Esto no solo se usará en el backend, sino también en el frontend, donde se mostrará la interacción del invitado/usuario y se presentará el contenido de la página.
Creo* que los códigos de estado 200 OK o 403 Prohibido son válidos para páginas que existen o cuya existencia está permitida.
*Adición dos: He examinado 417 y 100 ahora y descubrí que son similares a lo que intento hacer (al menos solo para el caso de procesamiento de carga), aquí: http://benramsey.com/blog/2008/04/http-status-100-continue/
- es decir:*Una página web que enlaza al sitio X conhttp://www.example.com/page.php?query=lol&query2=failGoogle lo indexaría ya que el encabezado HTTP se indica como correcto.
SOLUCIÓN A LA QUE LLEGÉ:
De hecho, 404 es con lo que podría terminar nuevamente. Solo quería una solución diferente a esa, si HTTP la proporcionaba, pero hasta ahora parece que 404 sigue siendo la mejor solución utilizable para esto, gracias a todos, mi pregunta ha encontrado su respuesta.
Respuesta1
Si los parámetros para una solicitud GET son incorrectos, lo canónico es devolver un 404 (no encontrado) o 200 (OK).
La forma RESTful de utilizar solicitudes GET es consultar un recurso (obtener algo). Por lo tanto, si los parámetros requeridos no corresponden a un recurso existente (porque están incompletos), puede decir con precisión que el recurso consultado en el URI no se encuentra.
En la práctica, si desea evitar cosas como que los navegadores ignoren su página 404 y la sustituyan por la suya (estoy viendo IE 9 y 10), es posible que desee utilizar 200. Si considera que su aplicación es el recurso, 200 es apropiado; consultó la aplicación y arrojó un resultado (que resultó ser un error, pero no en el nivel HTTP). Sin embargo, este uso no es muy RESTful.
Respuesta2
El 417error sólo debería ocurrir cuando el cliente envió un Expectencabezado HTTP que el servidor no pudo cumplir, lo que no se relaciona de ninguna manera con las "entradas esperadas" de la aplicación en la solicitud. No lo uses.
Por otro lado, 400se debe enviar un error sólo cuando hay una sintaxis incorrecta en la solicitud HTTP que el servidor no comprende.
Ninguno de estos es realmente apropiado para una falla de validación en la lógica de la aplicación, aunque supongo que 400es un poco más apropiado.
En mi opinión, el 403error que estaba contemplando utilizar en su pregunta sobre Stack Overflow es la mejor opción.
Solo usé el encabezado 403 Forbidden cuando los valores esperados no se encontraron en $_GET, pero, cuando lo pensé, en realidad no es una acción que requiera iniciar sesión (no para esto, por supuesto, un usuario debe iniciar sesión para ver el administrador). panel en primer lugar), es más bien una entrada de valor inesperada.
Estás pensando en 401, que es el código de respuesta que se utiliza cuando se necesita autenticación. 403es una denegación genérica de la solicitud, que parece exactamente lo que desea.
Todo esto supone que desea devolver un 4xxcódigo de respuesta... lo cual tiene sentido para una API... pero para una página HTML orientada al usuario, lo más probable es que desee enviar un mensaje 200con la información de error en el cuerpo.
Respuesta3
No puedo entender qué estás haciendo, sin embargo, hay una opción adicional que quizás no hayas considerado: 200 - OK. La razón es que recibió los datos correctamente, el problema es que no son válidos para su aplicación, lo cual en realidad no es un problema con el protocolo HTTP.
El rfc relevante aquí esrfc2616. Podría usar 400 pero luego deberá brindarle al cliente la capacidad de modificar los datos, desde el rfc
10.4.1 400 Solicitud incorrecta
El servidor no pudo entender la solicitud debido a una sintaxis incorrecta. El cliente NO DEBE repetir la solicitud sin modificaciones.
Respecto al 417 dice el rfc
10.4.18 417 Expectativa fallida
Este servidor no pudo cumplir la expectativa dada en un campo de encabezado de solicitud Expect (consulte la sección 14.20) o, si el servidor es un proxy, el servidor tiene evidencia inequívoca de que el servidor del siguiente salto no pudo cumplir la solicitud. .
entonces, si no estás usando el encabezado de espera, probablemente no deberías usar esta respuesta.