La risposta "NoContent" di Jersey restituisce 200 anziché 204

Question

Sto utilizzando Jersey (1.18) per creare un'API REST per la mia WebApplication. In una parte del mio codice ho il seguente snippet.

return Response.status(Status.NO_CONTENT).entity(err_message).build(); 

dove Status è un'istanza di com.sun.jersey.api.client.ClientResponse.Status;

Secondo Jersey Documentation NO_CONTENT dovrebbe restituire un codice , invece di questo, la risposta http ha un'intestazione con codice.

no_content
public static finale ClientResponse.Status no_content
204 No Content, vedere HTTP/1.1 documentazione.

Ho provato a modificare il codice di cui sopra agli

return Response.noContent().entity(err_message).build(); 

Ma il problema esiste ancora. Come nota a margine, utilizzando NOT_FOUND anziché NO_CONTENT, restituire un'intestazione come previsto.

Qualsiasi suggerimento su "Come posso restituire il codice 204?", È un errore o sto facendo qualcosa di sbagliato.

Nota: Non è un duplicato di Returning 200 response code instead of 204

Answer 1

Vedere this SO answer che dice,

... 204 significa "No Contenuto", il che significa che la risposta non contiene entità, ma si mette uno in esso. È probabile che Jersey lo stia passando da a 200 per te, che è praticamente identico a un 204 tranne che è che contiene un'entità di risposta.

Infine, è possibile ottenere 204 risposte semplicemente con un paio di comportamenti incorporati : i metodi void e i valori di ritorno nulli si associano entrambi a una risposta 204 . In caso contrario, è sufficiente restituire Response.status(204).build().

In altre parole, se si desidera "NO_CONTENT", non includere il contenuto nella risposta.

Answer 2

Dopo aver scavato un po 'di più ho trovato il problema. Il W3c Documentation dà un suggerimento.

sto citando

10.2.5 204 No Content

Il server ha soddisfatto la richiesta, ma non ha bisogno di restituire un'entità-corpo, e potrebbe desiderare di tornare metainformazione aggiornato. La risposta MAGGIO include la metainformazione nuova o aggiornata sotto forma di intestazioni di entità, che se presente DOVREBBE essere associata alla variante richiesta.

Se il client è un agente utente, NON DEVE cambiare la vista del documento da quella che ha causato l'invio della richiesta.Questa risposta è intesa principalmente a consentire l'input per le azioni da eseguire senza causare una modifica alla vista del documento attivo dell'agente utente, sebbene qualsiasi metainformation nuova o aggiornata DOVREBBE essere applicata al documento attualmente nella vista attiva dell'agente utente.

La risposta 204 NON DEVE includere un corpo del messaggio e pertanto viene sempre terminata dalla prima riga vuota dopo i campi dell'intestazione.

Nel mio codice ho entity(err_message) che causa il problema. Rimuovendolo il viene restituito correttamente. Penso che in qualche modo il Jersey o 'qualcuno' lancia la risposta a dal momento che ha contenuto.

Aggiornamento (02/05/2015)

Questo blog post collegamento (pubblicato in data odierna come una risposta e poi cancellato), dà ulteriori spunti di riflessione sulla situazione. In base al contenuto del post del blog, ogni volta che c'è un contenuto nella risposta HTTP viene richiamato il metodo seguente. Questo metodo imposta il codice di stato di nuovo a 200.

private void commitWrite() throws IOException { 
    if (!isCommitted) { 
     if (getStatus() == 204) 
      setStatus(200); 
       isCommitted = true; 
       o = responseWriter.writeStatusAndHeaders(size, ContainerResponse.this); 
    } 
} 

Possiamo dire che Jersey rileva che poiché non v'è un contenuto nella risposta, il codice di stato è stato erroneamente impostato su 204 e cambia al appropriata 200.