A volte (quando la risorsa viene richiesta troppo spesso) Sto intercettando la presentazione di una risorsa (HTML) con un captcha. L'intercettazione non produce alcun reindirizzamento. Succede tutto nello stesso URI.Codice di stato HTTP per Captcha
Mi chiedo ora quale codice di stato HTTP si adatterebbe più per queste esigenze:
dovrebbe andare bene semanticamente.
Google dovrebbe capire che questa intercettazione è una condizione temporanea che non dovrebbe influire sulla risorsa esistente nel suo indice.
Un browser Web visualizzerà il corpo della risposta con il captcha.
Questi sono i miei candidati che ho individuati finora:
409 Conflict
La richiesta non può essere completata a causa di un conflitto con lo stato attuale della risorsa. Questo codice è consentito solo in situazioni in cui è previsto che l'utente possa risolvere il conflitto e inviare nuovamente la richiesta. Il corpo della risposta DOVREBBE includere informazioni sufficienti per l'utente a riconoscere l'origine del conflitto.
Sembra perfetto. Lo stato di conflitto deriva da quei clienti che richiedono la risorsa troppo spesso. La risposta include anche informazioni sufficienti per identificare l'origine del conflitto e risolverlo.
503 Service Unavailable
Il server è attualmente in grado di gestire la richiesta a causa di un sovraccarico temporaneo [...] del server. L'implicazione è che questa è una condizione temporanea [...]. Se noto, la lunghezza del ritardo può essere indicata in un'intestazione Riprova dopo.
Questo suona moderatamente appropriato. Potrei anche sapere la durata del ritardo e fornire tale intestazione. Ma mi manca il punto che l'utente può risolvere il problema. Inoltre, l'ambito è troppo ampio (server sovraccarico e risorsa sovraccaricata).
Stavo pensando che 401 sarebbe stata una risposta appropriata. Captcha è una forma di autenticazione con l'intento di autenticare l'umanità del controller dell'utente-agente. Sto esaminando cosa fornire nell'intestazione dell'autenticazione WWW, ma inizierò con Autenticazione WWW: X-Captcha – John
Bene, 401 implica la presenza di uno schema di autenticazione definito. Non creare uno schema solo per essere in grado di utilizzare 401. –
La RFC richiede che venga presentata una richiesta, ma non richiede che tutti gli user-agent capiscano la sfida. L'esempio è una sfida per uno schema che non è presente negli standard, quindi questo mi porta a credere che se l'applicazione è in grado di utilizzare lo schema, è ragionevole introdurlo. Quando leggo le specifiche per 429, sembra che il client debba smettere di fare richieste. Questo non è il comportamento desiderato: vogliamo che il client invii nuovamente la richiesta dopo l'autenticazione. Youtube usa 402 quando ci sono troppe richieste, ma questo stato è ora riservato per un uso futuro. – John