Ogni richiesta HTTP riuscita restituisce sempre il codice di stato 200?

Question

In Delphi, sto usando Indy TIdHTTPWebBrokerBridge accoppiato con TIdHTTP per inviare/ricevere dati via HTTP. Sul server non ho alcuna gestione elaborata, rispondo sempre con un semplice flusso di contenuti. In caso di problemi, restituisco solo le informazioni su tale problema nel contenuto della risposta (come l'autenticazione non riuscita, la richiesta non valida, ecc.). Quindi, dal punto di vista del cliente, posso presumere che ogni richiesta riuscita effettuata su questo server avrà sempre un codice di risposta di 200 (OK)?

Mi chiedo perché sul client, le richieste sono racchiuse all'interno di funzioni che restituiscono solo un valore booleano per il successo della richiesta.

All'interno di questa funzione:

IdHTTP.Get(SomeURL, AStream); 
Result:= IdHTTP.ResponseCode = 200; 

Questa funzione gestisce ogni e qualsiasi richiesta che potrebbe recuperare i dati. Se ci sono stati problemi nella richiesta, questa funzione dovrebbe restituire False. Nel mio scenario, dal momento che restituisco sempre una sorta di contenuto sul server, il client riceverà sempre un codice di risposta di 200 in questa funzione?

Immagino che la vera domanda sia, se restituisco sempre una sorta di contenuto e gestisco tutte le eccezioni sul server, allora il server restituirà sempre il codice di stato di 200 per ogni richiesta?

Answer 1

Per rispondere alla tua domanda specifica:

posso supporre che ogni richiesta di successo faccio a questo server avrà sempre un codice di risposta 200 (OK)?

La risposta è Sì, perché TIdHTTPWebBrokerBridge avvolge TIdHTTPServer, che definisce sempre il codice di risposta di default a 200 per ogni richiesta, a meno che non sovrascrivere con un valore diverso da soli, o di avere il server fare qualcosa che risponde implicitamente con un codice di risposta diverso (ad esempio Redirect() che utilizza 302 o SmartServeFile() che utilizza 304) oppure si verifica un errore che causa l'assegnazione di un codice di risposta di errore 4xx o 5xx a TIdHTTPServer.

Tuttavia, in generale, ciò che altri hanno detto è vero. Sul lato client, dovresti gestire qualsiasi codice di risposta di successo HTTP, non solo 200 di per sé. Non fare ipotesi sull'implementazione del server.

Infatti, lo TIdHTTP lo gestisce già per te. Se TIdHTTP rileva un codice di risposta che considera un codice di errore, genererà un'eccezione EIdHTTPProtocolException nel codice. Quindi, se non si ottiene un'eccezione, si supponga che la risposta abbia esito positivo. Non è necessario controllare manualmente il codice di risposta.

Se esiste un particolare codice di risposta che solleva normalmente un'eccezione ma non la si desidera, è possibile specificare tale valore nel parametro AIgnoreReplies facoltativo di TIdHTTP.Get() o TIdHTTP.DoRequest(). Oppure, se si sta utilizzando una revisione SVN di Indy 10 aggiornata, un nuovo flag hoNoProtocolErrorException è stato aggiunto di recente alla proprietà TIdHTTP.HTTPOptions in modo che l'eccezione EIdHTTPProtocolException non venga sollevata per alcun codice di risposta.

Answer 2

resposes successo sono 2xx List_of_HTTP_status_codes

Answer 3

"fa ogni richiesta HTTP successo restituisce sempre il codice di stato 200?"

Vedi w3.org: HTTP/1.1 Status Code Definitions (RFC 2616)

La risposta è No . Tutti i 2xx sono considerati di successo. Ciò può dipendere dal HTTP method utilizzato.

Se l'applicazione web-server restituisce sempre 200 in caso di successo? Ciò può anche dipendere dal metodo di richiesta e dal segnale che intende per il cliente. per esempio.

per PUT metodo (corsivo è mio):

Se una risorsa esistente viene modificata, o il (OK) o (No Content) codici di risposta DOVREBBE essere inviato per indicare il completamento con successo della richiesta.

per POST metodo:

L'azione svolta dal metodo POST potrebbe non tradursi in una risorsa che può essere identificato da un URI.In questo caso, sia 200 o (Nessun contenuto) è lo stato di risposta appropriato, a seconda che o meno la risposta includa un'entità che descrive il risultato.

Se una risorsa è stata creata sul server di origine, la risposta DOVREBBE essere (Creato) e contengono un'entità che descrive lo stato della richiesta e si riferisce alla nuova risorsa, e una posizione intestazione (vedere la sezione 14.30). Le risposte a questo metodo non sono memorizzabili nella cache , a meno che la risposta non includa i campi di intestazione Cache-Control o Scadenza appropriati. Tuttavia, la risposta (Vedi Altro) può essere utilizzata per indirizzare l'agente utente a recuperare una risorsa memorizzabile nella cache.

Come si può imparare dal RCF, ogni metodo DEVONO disponga di un proprio codici di stato di successo, a seconda della realizzazione.

tua altra domanda:

"Posso supporre che ogni richiesta di successo che faccio a questo server avrà sempre un codice di risposta 200 (OK)?"

È possibile sempre aspettare il codice di stato 200, se il vostro server web sempre risponde con Status 200. I controlli applicativi web server quale risposta si restituisce al client.

Detto questo, il codice di stato 200 è lo Standard risposta per le richieste HTTP di successo (La risposta reale dipenderà dal metodo di richiesta utilizzato), e nel mondo reale di server web, deve essere impostato come predefinita su richiesta riuscita, salvo diversa indicazione (Come spiegato in Remy's answer).

Answer 4

ho fatto quanto segue. Elabora direttamente tutte le 200 e le eccezioni LOG. ha funzionato, non un singolo non 200 - tranne che non autorizzati e timeout (password o server a volte non disponibile). ma molte/tutte le risposte saranno prese in considerazione per una vasta gamma di app tradizionali.

 while (iRedo < 3) do begin 
     s := Self.HTTPComponent.Get(sUrl); 

     if self.HTTPComponent.ResponseCode = 200 then begin 
      break; 
     end; 

     // IDEIA - log what happend if not 200 
     logWhatHappend(s, HTTPComponent); // then log content, headers, etc 
     inc(iRedo); sleep(5); 
     end;