nombre de caractères recus par recv

Bonjour,
Dans le cadre d'un projet j'ai été amener à programmer en c quelques fonctions ayant pour but de récuperer le contenu d'une page d'un serveur http. Mais un dernier problème s'oppose à moi : l'envoie de la requette s'effectue bien mais quand je veux récuperer la réponse et que j'effectue :

Code:

---

sock_err = recv(sock, reponse, REP_MAX, 0);//REP_MAX = 60000

---

je n'obtient que le début de la réponse. Mais si j'effectue :

Code:

---

1 2 3 4 5

sock_err = recv(sock, reponse, REP_MAX, 0); sock_err = recv(sock, reponse, REP_MAX, 0); sock_err = recv(sock, reponse, REP_MAX, 0); sock_err = recv(sock, reponse, REP_MAX, 0); sock_err = recv(sock, reponse, REP_MAX, 0);

---

j'obtient toute la réponse.:?

j'ai regardé la taille successive de chaque réponse elle varie : 11617 - 8713 - 8713 - 13069 - 779. :aie: Et quand je change de page seul le dernier chiffre change.

Je me suis renseigné et je n'ai pas trouvé alors si quelqu'un peut m'aider ... :calim2: merci

En TCP, rien ne garantit que 1 send = 1 recv

tu peux avoir :

• 1 send et 5 recv(ton cas)
• 1 send, 1 recv
• 2 send, 1 recv
• et toute autre variation

Donc dans ton cas, pour t'en sortie, il faut lire le début de la réponse HTTP et dedans, tu obtiens le nombre d'octets à lire. Ensuite, il faut lire jusqu'à avoir obtenu ce nombre d'octets.

Ok merci beaucoup ram-0000:ccool: mais il y a un problème, tous les sites ne donnent pas la taille du corps (le contenu du site) de la requete. Je peux toujours dire qu'un site se finit lorsque la balise "</html>" apparait mais cette solution n'est pas optimale. Y a-t-il un autre moyen de connaitre le nombre de recv a effectuer ?

Citation:

---

Envoyé par brastir

mais il y a un problème, tous les sites ne donnent pas la taille du corps (le contenu du site) de la requete.

---

Alors ils ne respectent pas le protocole HTTP.

Citation:

---

Envoyé par Lu dans le RFC 1945

7.2.2 Longueur
Lorsqu'un corps d'entité est présent dans un message, la longueur de ce corps doit être explicitée par l'un des deux moyens suivants. Si un champ Content-Length est présent, sa valeur associée représente la longueur en octets du corps d'entité. Autrement, c'est la déconnexion par le serveur qui marque la fin du corps d'entité.
Cette dernière méthode ne peut être utilisée pour marquer la fin d'une requête, car la possibilité doit être laissée au serveur d'envoyer une réponse. C'est pourquoi le protocole HTTP/1.0 précise que toute requête contenant un corps d'entité doit mentionner sa longueur dans un champ d'en-tête Content-Length valide. Si tet est le cas, et que ce champ n'existe pas dans le message, et dans la mesure où le serveur ne peut calculer ou déterminer la longueur de ce corps, ce dernier répondra par un message de code 400 (erreur client).

Note: Certains anciens serveurs spécifient un champ Content-Length erroné lorsque la réponse contient des données dynamiquement générées par le serveur. Il est signalé ici que cet état de fait ne sera plus tolérable dans les nouvelles versions d'HTTP.

---

Il y a bien un champs longueur dans la requête HTTP, c'est le champs Content-Length. Il faut lire cette valeur et ainsi tu sauras combien il faut recevoir de données.

ok d'accord ça ma rassure. Merci de ton aide précieuse et rapide.8-)

brastir

Citation:

---

Envoyé par ram-0000

Alors ils ne respectent pas le protocole HTTP.

---

Je ne suis pas d'accord avec toi, et tu en donnes l'argument:

Citation:

---

Envoyé par RFC 1945

7.2.2 Longueur
Lorsqu'un corps d'entité est présent dans un message, la longueur de ce corps doit être explicitée par l'un des deux moyens suivants. Si un champ Content-Length est présent, sa valeur associée représente la longueur en octets du corps d'entité. Autrement, c'est la déconnexion par le serveur qui marque la fin du corps d'entité.
Cette dernière méthode ne peut être utilisée pour marquer la fin d'une requête, car la possibilité doit être laissée au serveur d'envoyer une réponse. C'est pourquoi le protocole HTTP/1.0 précise que toute requête contenant un corps d'entité doit mentionner sa longueur dans un champ d'en-tête Content-Length valide. Si tet est le cas, et que ce champ n'existe pas dans le message, et dans la mesure où le serveur ne peut calculer ou déterminer la longueur de ce corps, ce dernier répondra par un message de code 400 (erreur client).

Note: Certains anciens serveurs spécifient un champ Content-Length erroné lorsque la réponse contient des données dynamiquement générées par le serveur. Il est signalé ici que cet état de fait ne sera plus tolérable dans les nouvelles versions d'HTTP.

---

Le client n'a pas le droit, mais le serveur lui peut omettre ce champ et fermer la connexion pour indiquer la fin de la réponse.

Citation:

---

Envoyé par nicolas.sitbon

Le client n'a pas le droit, mais le serveur lui peut omettre ce champ et fermer la connexion pour indiquer la fin de la réponse.

---

Effectivement mais je ne l'avais pas mentionné car c'est du HTTP 1.0 (le serveur ferme la connexion à chaque couple requête/réponse) et je ne suis pas sûr que cela soit très courant maintenant. Mais c'est vrai, il y a aussi cette possibilité

Le comportement est à peu prêt identique en HTTP 1.1:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

4.4 Message Length The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence): 1.Any response message which "MUST NOT" include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. 2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection. 3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored. 4.If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self- delimiting media type defines the transfer-length. This media type MUST NOT be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple byte- range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses. A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section. 5.By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length. All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored. When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.

---

A noter que je ne suis pas en train d'encourager ce genre de comportement, bien au contraire, mais je dis juste qu'il ne viole pas la norme.

cordialement.

OK, je ne savais pas que cela valait aussi pour HTTP 1.1

Donc pour résumer

• Soi tu as un Content-Length dans ta réponse et tu connais le nombre de caractères à recevoir
• Soi il n'y en a pas et tu sais que la fin de la réponse, c'est la coupure de la socket par le serveur
• Soi le serveur ne respecte pas le protocole HTTTP et tu as un problème :P

Citation:

---

Envoyé par ram-0000

• Soi il n'y en a pas et tu sais que la fin de la réponse, c'est la coupure de la socket par le serveur

---

Encore deux questions : :D

1°)Et si dans la requete on utilise "Keep-Alive:300"et"Connection:keep-alive".

2°)Dans l'autre cas (Connection:close), comment verifier que le serveur c'est déconecté

En HTTP 1.0 oui, en HTTP 1.1, content-length est un cas particulier de transfer-length, c'est donc un peu plus compliqué, voir le passage que j'ai cité pour les règles précises.

Citation:

---

Envoyé par brastir

1°)Et si dans la requete on utilise "Keep-Alive:300"et"Connection:keep-alive".

---

Soit le serveur ne supporte pas les connexions persistentes auquel cas il doit l'indiquer avec un Connection: close, et peut se contenter de fermer la connexion pour indiquer la fin du corps de message, soit il poursuit en connexion persistente et doit obligatoirement inclure un entête précisant la longueur du message (transfer-length, content-length, ...).

Citation:

---

Envoyé par brastir

2°)Dans l'autre cas (Connection:close), comment verifier que le serveur c'est déconecté

---

Une déconnexion TCP, entraîne l'envoi d'un segment avec le flag FIN activé, il y a donc une donnée à lire, un read() ou un recv() te renverront 0 pour te dire que la connexion est fini.

OK merci à vous deux. J'ai plus qu'à aller coder :mrgreen: