Est-ce que quelqu'un pourrait me décrire ce qu'est exactement une entité HTTP est?
Je lis la documentation HTTPClient, mais je ne comprends pas vraiment ce que cela signifie?
Une entité HTTP est la majorité d'une requête ou réponse HTTP, composée de certains des en-têtes et du corps, le cas échéant. Il semble que ce soit la demande ou la réponse entière sans la demande ou la ligne d'état (bien que seuls les champs certains en-tête soient considérés comme faisant partie de l'entité ).
Pour illustrer; voici une demande:
POST /foo HTTP/1.1 # Not part of the entity.
Content-Type: text/plain # ┬ The entity is from this line down...
Content-Length: 1234 # │
# │
Hello, World! ... # ┘
Et une réponse:
HTTP/1.1 200 OK # Not part of the entity.
Content-Length: 438 # ┬ The entity is from this line down...
Content-Type: text/plain # │
# │
Response body ... # ┘
Voici 3 cas simples:
Cas 1. Vous téléchargez 3 fichiers en une seule demande. Ces 3 fichiers sont 3 entités. Chacun d'eux a son propre Content-Type
pour indiquer de quel type de fichier il s'agit.
Cas 2. Vous visualisez une page Web. Le navigateur a téléchargé un fichier HTML en tant qu’entité à l’arrière-plan. Étant donné que la page peut être mise à jour continuellement, vous pouvez obtenir ultérieurement une entité totalement différente.
Cas 3. Vous avez un 304 Not Modified
. Aucune entité n'a été transférée.
Dans un mot, Entity est une charge utile facultative dans un message http (demande ou réponse), il s'agit donc d'une relation "partie-entière" entre Entity et Message.
Certains champs d'en-tête s'appliquent à Message
comme Transfer-Encoding
décrivent comment transférer un message entre intermédiaires et PEUVENT donc être ajoutés ou supprimés par toute application de la chaîne de requête/réponse (hop-by-hop headers
). En comparaison, ces champs d’en-tête s’appliquent à Entity
sont des propriétés décrivant la taille, le type, l’algorithme de compression, etc. de l’entité.
Lectures complémentaires, citant les paragraphes 1.4, 4.5 et 4.3 de la RFC 2616:
request chain --------------------------------------> UA -----v----- A -----v----- B -----v----- C -----v----- O <------------------------------------- response chain
La figure ci-dessus montre trois intermédiaires (A, B et C) entre l'agent d'utilisateur et le serveur Origin. Un message de demande ou de réponse qui parcourt toute la chaîne passera par quatre connexions distinctes.
Il existe quelques champs d'en-tête qui ont une applicabilité générale pour les messages de requête et de réponse, mais qui ne s'appliquent pas à l'entité en cours de transfert. Ces champs d’en-tête s’appliquent uniquement à le message en cours de transmission.
Le codage de transfert DOIT être utilisé pour indiquer tout codage de transfert appliqué par une application pour assurer un transfert sûr et correct du message. Transfer-Encoding est une propriété du message, pas de l'entité, et PEUT donc être ajouté ou supprimé par toute application de la chaîne de requête/réponse.
message-body = Transfer-Encoding( Content-Encoding(entity-body) )
où Transfer-Encoding
peut être "chunked", ce qui signifie comment transférer le message, et Content-Encoding
peut être "gzip", qui signifie comment compresser l'entité.
C'est une abstraction représentant une demande ou une réponse payload. Le JavaDoc est clair sur son objectif et ses différents types d’entités.
HTTP est un protocole observé lors de l'accès à des informations depuis une machine distante via un réseau. Généralement, le réseau est Internet et la machine distante est un serveur.
Lorsque vous demandez des informations à une personne A, vous lui transmettez un message. (Demande). La personne B vous répond (Réponse). Request et Response sont des types de message HTTP.
La personne A peut demander à la personne B de faire quelque chose au lieu de demander des informations. Dites, la personne A veut que la personne B stocke un fichier dans un emplacement sécurisé. Ainsi, la personne A transmet ce fichier (entité HTTP) à la personne B et lui demande de faire quelque chose (message HTTP). Dans ce cas, la personne passe une "entité". Dans le contexte de l'entité HTTP, il s'agit d'une charge utile attachée au message.
J'espère que l'analogie a aidé.
Comme indiqué dans un commentaire de @ hawkeye-parker, il semblerait que Entity soit obsolète. Effectuez une recherche dans ce rfc 2014, et vous verrez à propos des entités XML et du corps du message, mais rien sur les entités Http.
Néanmoins, HttpClient, mais aussi le client JaxRS, ont une méthode setEntity()
et getEntity()
.
Compte tenu de la réponse acceptée, les deux bibliothèques ont tort! HttpClient.setEntity()
ne supprimera pas les en-têtes précédemment définis.
Parmi les bonnes réponses que nous avons ici, je pense que cela vaut la peine de mentionner quelque chose qui vient directement de la RFC 2616 (protocole de transfert hypertexte - HTTP/1.1)
Entité
Les messages de demande et de réponse PEUVENT transférer une entité si ce n'est pas le cas restreint par la méthode de requête ou le code d'état de la réponse. Une entité se compose de champs d'en-tête d'entité et d'un corps d'entité, bien que certains les réponses n'incluront que les en-têtes d'entité.
En bref: une entité peut être transférée, et il peut s'agir de l'en-tête + body ou simplement de l'en-tête .
Puisqu'il y a le lien ci-dessus, je me retiens pour faire des commentaires supplémentaires.
Entity est quelque chose qui ressemble à un message, il consiste en un en-tête, où sont des métadonnées telles que location, lang, encoding.
Et éventuellement d'un corps - le contenu est formaté, etc. comme spécifié dans l'en-tête