Quale codice di stato HTTP da utilizzare per i parametri richiesti non fornito?

Question

Ho diverse pagine progettate per essere chiamate con AJAX - Ho loro restituire un codice di stato anormale se non possono essere visualizzati, e il mio javascript mostrerà una casella di errore di conseguenza.

Ad esempio, se l'utente non è autenticato o la sua sessione è scaduta e tenta di chiamare una delle pagine AJAX, restituirà 401 Unathorized.

Ho anche qualche ritorno 500 Internal Server Error se succede qualcosa di strano sul lato server.

Quale codice di stato devo restituire se una di queste pagine è stata chiamata senza parametri richiesti? (e quindi non può restituire alcun contenuto).

ho avuto uno sguardo al wikipedia article on HTTP status codes, ma il più vicino sono riuscito a trovare il codice che sto cercando è stato questo:

422 Unprocessable Entity
The request was well-formed but was unable to be followed due to semantic errors.

Edit: Il codice di cui sopra è WebDAV specifico e quindi improbabile che essere appropriato in questo caso

Qualcuno può pensare a un codice appropriato da restituire?

Answer 1

What status code should I return if one of these pages was called without required parameters? (and therefore can't return any content).

potessi scegliere 404 Not Found:

The server has not found anything matching the Request-URI [assuming your required parameters are part of the URI, i.e. $_GET ]. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

(highlight da me)

404 Not Found è un sottoinsieme di 400 Bad Request che potrebbe essere preso come bene perché è molto chiaro su ciò che questo è:

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

Non posso in realtà suggerire che si foto ka codice di risposta WEBDAV che non esiste per i client HTTP che utilizzano l'ipertesto, ma potresti, è totalmente valido, sei il codificatore del server, puoi effettivamente prendere qualsiasi codice di stato di risposta HTTP che ritieni adatto al tuo client HTTP di cui sei il designer pure:

11.2. 422 Unprocessable Entity

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

L'entità di richiesta IIRC è l'ente della richiesta. Quindi, se stai operando con i corpi delle richieste, potrebbe essere appropriato come ha scritto Julian.

---

commentato:

IMHO, the text for 400 speaks of malformed syntax. I would assume the syntax here relates to the syntax of HTTP string that the client sends across to the server.

Questo potrebbe essere, ma può essere qualsiasi cosa sintatticamente espresso, l'intera richiesta, solo alcune intestazioni di richiesta, o un'intestazione specifica richiesta, l'URI della richiesta, ecc .. 400 non è specificamente di "sintassi della stringa HTTP", è infatti la risposta generale ad un errore di client:

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

la parte importante è qui che si deve dire al cliente che cosa è andato storto. Il codice di stato sta solo dicendo che qualcosa è andato storto (nella classe 4xx), ma HTTP non è stato specificamente progettato per rendere notabile un parametro della parte di informazione query mancante come condizione di errore.Di fatto, l'URI sa solo che esiste una parte di informazioni di query e non ciò che significa.

Se si pensa che 400 sia troppo ampio, suggerisco di scegliere 404 se il problema è relativo all'URI, ad es. $_GET variabili.

Answer 2

Non so le intenzioni degli scrittori di RFC, ma il codice di stato che ho visto utilizzato in natura per quel caso è 400 Richiesta non valida.

Answer 3

Leggere attentamente:

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

422 è una cosa specifica, WebDAV, e io non l'ho visto usato per altri scopi.

400, anche se non destinato a questo particolare scopo, sembra essere una scelta comune.

404 è anche una scelta praticabile se la vostra API è RESTful o simile (utilizzando la parte percorso dell'URI per indicare parametri di ricerca)

Answer 4

Descrizione come citato contro 400

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

(sottolineatura mia)

Che parla di sintassi non valida, che non è il caso quando il browser invia una richiesta al server. È solo il caso dei parametri mancanti (mentre non c'è sintassi malformata).

Vorrei suggerire bastone con 404 :)

(Esperti correggetemi se sbaglio ovunque :))

Answer 5

422 è un codice di stato HTTP regolare; ed è è utilizzato all'esterno di WebDAV. Contrariamente a quanto dicono gli altri, non c'è problema con questo; HTTP ha un registro del codice di stato per un motivo.

Vedi http://www.iana.org/assignments/http-status-codes