Anomalie serveur HTTP

[hlaidet]

Bonjour à tous,

J'ai noté une anomalie dans le serveur HTTP qui se traduit par des fichiers perdus.

Les clients HTTP ( IExplorer, Firefox )
font des requètes GET de cette forme:

#GET / HTTP/1.1\r\n
#Accept: */*\r\n
#Accept-Language: fr\r\n
#UA-CPU: x86\r\n
#Accept-Encoding: gzip, deflate\r\n
#User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Wanadoo 6.1; Orange 8.0; .NET CLR 1.1.4322)\r\n
#Host: 81.56.xxx.yyy:59999\r\n
#Connection: Keep-Alive\r\n
#Authorization: Basic (++++++++++++++++)\r\n
#\r\n

Ce qui représente bien plus d'octets qu'il n'en est lu dans freescale_http->freescale_http_read_header().
le buffer de stockage dans freescale_http_process est de 256 octets...

Solution apportée:
---(1)---------------------------------
Dans freescale_process_header() lors du traitement de la requete GET,
il faut éliminer ce qui reste dans le tampon socket jusqua la séquence FIN DE GET (0x0d0a0d0a).
Juste avant l'appel à "collect_sensor_data", on appelle une routine de purge "m_recv_remove" si la séquence de fin n'est pas dans notre buffer.

#//////////////////////////////////////////////
#//BEWARE, THE STORAGE BUFFER SHOULD BE INCREASED ONE BYTE
#//Declared in freescale_http_process()
#//unsigned longbuffer[(RECV_BUFFER_SIZE/4)+1];
#uint32target;
#char cc, *p;
#p = &filename[strlen(filename)];//Just after filename
#buffer[bytesread] = 0; //Close received buffer
#if(strstr(p, "\r\n\r\n" )==NULL)//No correct end of header
#{//there are datas pending
#p = &buffer[bytesread];//Out of buffer
#for(i=0; i<4; i++)
#{
#cc = *(--p);
#if((cc!=0x0a)&&(cc!=0x0d))
#break;
#}
#switch(i)
#{
#case 3:target = 0x0000000a;break;
#case 2:target = 0x00000d0a;break;
#case 1:target = 0x000a0d0a;break;
#default:target = 0x0d0a0d0a;break;
#}
#m_recv_remove(freescale_http_sessions[session].socket, target);
#}
#//////////////////////////////////////////////
#collect_sensor_data( );



La routine "m_recv_remove" est une copie adaptée de "m_recv".
Je lai placée avec "m_recv" dans "tcpapi.c" (joint).

ATTENTION, IL FAUT AUGMENTER LE BUFFER DE STOCKAGE
dans "freescale_http_process" pour que "buffer[bytesread] = 0;" ne polue pas la pile de lappelant.

Je pense que le problème vient du manque de RAM qui oblige des petits buffers.
256 octets sont suffisants pour "GET /filename" mais pas avec une big suite.

---(2)---------------------------------
L'origine de cette anomalie est certainement due au compilo (Codewarrior 6.3).
En effet, dans la procédure "freescale_http_read_header" on invoque "freescale_process_header"
alors que le test dans la boucle
# for( i=NO_HEADER_FOUND; header_table.header_string!=NULL; i++ )
aurait du nous éjecter... ...
mais le code nous laisse accéder à "freescale_process_header" avec le résidu du GET précédent.
Pour contrer, changer le test dans la boucle par:
# for( i=NO_HEADER_FOUND; header_table.header_type!=0; i++ )
le code généré nexécute plus "freescale_process_header".

Ou alors changer de compilo!


---(3)---------------------------------
Les sujets (1) et (2) ne sont pas exclusifs.
Il faut faire les deux c'est mieux


Avec ces modifs, le serveur HTTP fonctionne mieux.

Salut
Henri'

[Elektor Editor]

Hi Henri,

please join the English language forum topic for the DigiButler project and feel free to ask your question there. I'm suggesting this because there are experts out there who may be able to help you solve the problem you have described.

Please, if possible rephrase your query in basic English, entente cordiale is actively practised .

You can log onto www.elektor.com using your French logon (user name and password).

DigiButler = a votre service.

Jan Buiting
Editor, Elektor English edition.