Comment analyser correctement les requêtes HTTP entrantes

Question

J'ai créé une application C++ en utilisant WinSck, qui a un petit serveur (gère seulement quelques fonctionnalités dont j'ai besoin) implémenté par le serveur http. Ceci est utilisé pour communiquer avec le monde extérieur en utilisant des requêtes http. Cela fonctionne, mais parfois les requêtes ne sont pas gérées correctement, car l'analyse échoue. Maintenant, je suis tout à fait sûr que les demandes sont correctement formées, puisqu'elles sont envoyées par les principaux navigateurs web comme firefox/chrome ou perl/C# (qui ont des modules http/dll). Après un certain débogage, j'ai découvert que le problème était en fait de recevoir le message. Lorsque le message arrive dans plus d'une partie (il n'est pas lu dans un appel recv()), l'analyse échoue parfois. J'ai traversé de nombreux essais sur la façon de résoudre cela, mais rien ne semble assez fiable. Ce que je fais maintenant, c'est que je lis dans les données jusqu'à ce que je trouve "\r\n\r\n" séquence qui indique la fin de l'en-tête. Si WSAGetLastError() signale quelque chose d'autre que 10035 (connexion fermée/échec) avant qu'une telle séquence soit trouvée, je rejette le message. Quand je sais que j'ai tout l'en-tête je l'analyse et cherche des informations sur la longueur du corps. Cependant, je ne suis pas sûr si cette information est obligatoire (je ne pense pas) et que devrais-je faire s'il n'y a pas de telles informations - cela signifie-t-il qu'il n'y aura pas d'organe? Un autre problème est que je ne sais pas si je devrais chercher un "\r\n\r\n" après le corps (si sa longueur est supérieure à zéro).

Est-ce que quelqu'un sait comment analyser de manière fiable un message http?

Remarque: je sais qu'il existe des implémentations de serveurs http là-bas. Je veux le mien pour diverses raisons. Et oui, réinventer la roue est mauvais, je le sais aussi.

Answer 1

Vous pourriez essayer de regarder leur code pour voir comment ils gèrent un message HTTP.

Ou vous pouvez regarder the spec, il ya message length les champs que vous devez utiliser. Seuls les navigateurs buggés envoient des CRLF supplémentaires à la fin, apparemment.

Answer 2

Si vous êtes en train d'écrire votre propre analyseur, je prendrais l'approche Zed Shaw: utilisez le compilateur de machine d'état Ragel et construisez votre analyseur basé dessus. Ragel peut gérer les entrées arrivant en morceaux, si vous faites attention.

Honnêtement, cependant, je voudrais juste utiliser something like this.

Votre ressource de référence doit être RFC 2616, qui décrit HTTP 1.1, que vous pouvez utiliser pour construire un analyseur. Bonne chance!

Answer 3

HTTP GET/HEAD Les requêtes n'ont pas de corps, et POST demande ne peut pas avoir de corps aussi. Vous devez vérifier si c'est GET/HEAD, si c'est le cas, alors vous n'avez aucun contenu (corps/message) envoyé. Si c'était un POST, faites comme le specs say about parsing a message of known/unknown length, comme @gbjbaanb a dit.

Answer 4

De toute façon la requête HTTP a "\ r \ n \ r \ n" à la fin des en-têtes de requête et avant les données de requête le cas échéant, même si la requête est "GET/HTTP/1.0 \ r \ n \ r \ n ".

Si la méthode est "POST", vous devez lire autant d'octets après "\ r \ n \ r \ n", comme spécifié dans le champ Content-Length.

Alors est pseudocode:

read_until(buf, "\r\n\r\n"); 
if(buf.starts_with("POST") 
{ 
    contentLength = regex("^Content-Length: (\d+)$").find(buf)[1]; 
    read_all(buf, contentLength); 
} 

Il y aura "\ r \ n \ r \ n" après le contenu que si le contenu inclut. Le contenu peut être des données binaires, il n'a pas de séquences de terminaison, et la seule méthode pour obtenir sa taille est l'utilisation du champ Content-Length.