Discussion :

[ninnin]

Bonsoir à tous.

J'ai suivi ce tuto:
http://khayyam.developpez.com/articl.../multithreads/

J'ai juste modifié à la fin de serveur.cpp:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
DWORD serveur::ClientThread(SOCKET soc){
	cout << "thread client démarre" << endl;
	string headers = "HTTP/1.0 200 OK\nServer : test 1.0\nContent-Type : text/HTML\nContent-Length : ";
	string strs = "Hellow";
	string retVal = headers + "6" + "\n\n" + strs;
    send(soc, retVal.c_str(), retVal.length(), 0);
    closesocket(soc);
	/*    A mettre ici : code relatif au protocole utilisé    */
 
	return 0;
}

Ceci afin de renvoyer quelque chose vers le navigateur.
Cela fonctionne... mais je dirais que une fois sur quatre environ, le navigateur indique que "La connexion avec le serveur a été réinitialisée pendant le chargement de la page."

Je n'ai aucune idée du problème.... vous voyez; vous ?

[koala01]

Salut,

Avant de répondre, signalons que le tuto en question est ..humm... ancien et qu'il présente certains aspects susceptibles de faire sauter en l'air de nombreux développeurs habitués aux technique modernes:

1. La présence d'une fonction init qui doit être invoquée explicitement, alors que l'idée meme de la POO est de fournir directement des objets totalement initialisés
2. Le recours à l'allocation dynamique de la mémoire lors de la création du serveur (dans main.cpp) alors qu'elle n'a aucune raison d'être
3. Le fait que le serveur n'est jamais détruit (toujours dans main.cpp), même si on peut considérer que le système fera le ménage correctement
4. Une approche particulièrement "plateforme dépendante" (exclusivement windows) qui tend à limiter énormément les possibilités, à une époque où le besoin de portabilité devient de plus en plus important.
5. J'en passe, et peut être de meilleures.

Cela n'en fait pas un "mauvais" tuto! Disons juste que cela en fait peut être un tuto "mal adapté" à la "philosophie actuelle" (ou en tout état de cause à la mienne )

Je te proposerais donc volontiers de t'intéresser au tuto sur boost::asio proposé par Gwenaël Dunand (dit poukill), qui est, en tout état de cause, bien plus récent et très certainement plus représentatif des "bonnes pratiques" actuelles

Ceci dit, le message que tu indiques est un message spécifique à firefox, qui signifie en gros:

Y a quelque chose qui a foiré, mais je ne sais pas quoi, car tout semble fonctionner correctement

Je ne suis plus particulièrement à l'aise avec les en-tête html, mais mon impression est que tu fais quelque chose que tu n'aurais pas du à leur niveau.

En relisant ton code, j'opterais volontiers pour le fait que tu n'as peut etre simplement pas introduit la taille adéquate dans la valeur Content-Lentgh

N'oublie pas que les chaines de caractères sont, classiquement, terminées par un '\0', ce qui pourrait donc signifier que "Hellow" devrait être considérée comme une chaine de taille 7

Maintenant, je peux me tromper très lourdement sur le sujet

[ninnin]

Salut !
Merci pour ta réponse et pour le fait de t'être penché là dessus ^^
En fait, les sockets en C et C++ sont assez obscurs pour moi

J'ai essayé de faire un length de la chaine avec un +1, le 6 est mis pour l'exemple bien entendu ^^, mais même en mettant donc le content length +1 ça ne fonctionne pas aléatoirement...

Je vais jeter un oeil à ton lien; même si j'aimerai comprendre pourquoi cela provoque ce souci, j'aime pas rester sur quelque chose que je ne comprend pas ^^

Merci

Edit: j'ai modifié le code comme suit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    send(soc, retVal.c_str(), retVal.length(), 0);
    for (int i=0; i<100; i++) {printf("bdhfjbvkjbsdkfbgdfkgvbsdbfkgvdfbnvdfbsklj\n");}
    closesocket(soc);

J'ai juste ajouté le "for" avec le printf pour faire "laguer" un peu le programme.
Ca plante à chaque requête.

Peut etre un truc qui va pas avec le send ... ?_?

[Bousk]

Bonjour,

faut savoir que le send n'est pas assuré d'envoyer toute les données.
Il envoit "tout ce qu'il peut", mais ce n'est pas forcément la chaîne entière.
Donc l'envoi typiquement, ça se fait ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int Send(const std::string& buffer)
{
		int iLenToSend = buffer.length() + 1;
		const char* pBuffer = buffer.c_str();
		int iSent = 0;
		do {
			int iLastSent = send(m_pSocket, pBuffer + iSent, iLenToSend - iSent, 0);
			m_bConnected = (iLastSent > 0);
			if (!m_bConnected)
				break;
			iSent += iLastSent;
		} while (iSent < iLenToSend);
		return iSent;
}

Par contre, pour un serveur simple, rien ne vaut Python amha !

[ninnin]

Merci pour ton petit bout de script
Mais là, avec ça; le navigateur veut carrément télécharger la page lol

Là dans le concept, il s'agit d'un + gros truc qu'un simple serveur.
Je souhaite faire une passerelle entre un site bien précis et le navigateur client.

Le navigateur va demander en local (127.0.0.1) une page, le logiciel va aller chercher la page, la modifier selon les besoins en ajoutant ou soustrayant les informations demandées, et renvoyer la page modifiée vers le client.

Donc j'essayer déjà de partir d'une base d'un serveur locale pour renvoyer une page "maison" dans un string buffer vers le client; mais avec le souci rencontré, j'ai pas été + loin pour le moment ^^.

Pour le reste, demander une page sur un site, j'ai pas de soucis en GET, juste le POST qui .... marche pas, mais ça je chercherai après, un problème à la fois ^^

[Bousk]

Si le navigateur propose de télécharger la page, peut-être est-ce un problème au niveau des headers qu'il reçoit.
Mais l'envoi doit se faire ainsi, dans une boucle qui s'assure de tout envoyer, indépendamment des données envoyées.

[ninnin]

Je pense aussi, pourtant j'ai fait un print des headers:



Je précise que j'ai également essayé le protocole HTTP/1.1, le résultat est identique.

Déjà je ne comprend pas pourquoi le type diffère entre le header et ce que le navigateur veut télécharger (application/O-S && text/Html)

[koala01]

Héhé..

Essayes peut-être Content-Type : text/html (avec htmp en minuscules).

La valeur du champs Content-Type (voir wikipedia est une chaine de caractères qui correspond au type mime de l'élément envoyé par le serveur.

Je ne serais pas étonné outre mesure que le type mime soit sensible à la casse, et que text/html soit donc considéré comme une chaine différente de text/HTML.

Si je ne me trompes pas, le navigateur ne reconnaissant pas le type mime de la réponse adopte la seule solution qui lui semble adaptée pour les type mimes inconnus : te proposer de l'enregistrer (ou de l'ouvrir avec une application particulière )

[Bousk]

Avec ce header je n'ai pas de souci:

HTTP/1.1 200 OK
Date: Tue, 29 Oct 2013 16:54:27 GMT
Content-Length: 5919
Content-Type: text/html; charset=utf-8
Server: TwistedWeb/12.3.0

[koala01]

Cela semble confirmer ce que je disais

Il existe (comme le montre le deuxième lien) une foule considérable de type mimes différents qui sont chacun adaptés à un type d'application susceptible de lire le contenu renvoyé par le serveur.

Pour faire simple, le type mime permet de savoir le type du contenu renvoyé par le serveur (en gros, l'extension du fichier tel qu'il apparait sur ton disque dur), et donc l'application (ou le plugin du navigateur) qui devra être utilisé pour afficher le contenu.

Mais les navigateurs internet sont des petites choses sensibles...

Il arrive parfois que certaines chaines de caractères (dont les en-têtes renvoyées par le serveur) soient ce que l'on appelle "sensible à la casse".

Cela signifie qu'une chaine de caractères "bonjour" sera considérée comme différente d'une chaine de caractères "Bonjour", parce que le caractères b (minuscule) est différent du caractère B (majuscule) ou encore de la chaine de caractères "BONJOUR", parce que le o (minuscule) est différent du O majuscule (et ainsi de suite pour tous les autres caractères).

Le fait est que le compilateur va simplement regarder la valeur indiquée par le champs Content-Type pour savoir quelle application (ou quel plugin) utiliser pour afficher le contenu qu'il reçoit, parce qu'il ne va pas afficher du texte et une image (par exemple) de la même manière.

Mais, s'il ne reconnait pas la chaine de caractères indiquée par le chams Content-Type (parce que, pour lui, text/html est une chaine de caractères différente de text/HTML ), il ne va, tout simplement, pas être en mesure de savoir que faire du contenu qu'il reçoit.

Il va donc "retomber sur ses pattes" en te proposant la seule solution qu'il lui reste : celle de choisir toi-même ce que tu veux en faire, à savoir