Problème CGI en C

**virus321** · 24/11/2010, 16h59

Bonjour,
Je m'adresse à vous après deux journées de recherche. En faite, j'essaye de programmer un CGI en C qui récupère un fichier via un formulaire avec la méthode POST.
Mon formulaire est le suivant

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
  <title>Transfert de fichier/title>
</head>
 
<body>
 
<form name="nom_formulaire" action="http://10.193.6.56:80/cgi-bin/transfertFichier.cgi" method="post" enctype="multipart/form-data">
 
<input type="hidden" name="MAX_FILE_SIZE" value="600000" />
Choose a file to upload: <input name="uploadedfile" type="file" /><br />
<input type="submit" value="Upload File" />
</form>
 
</body>
</html>

de l'autre coté j'ai écrit mon CGI de la façon suivante:

Code :

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

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
31
32
33
34
35
36
37
38
39
40
 
 
#include <stdio.h>
#include <stdlib.h>
#define MAXLEN 600000
#define EXTRA 5
/* 4 for field name "data", 1 for "=" */
#define MAXINPUT MAXLEN+EXTRA+2
/* 1 for added line break, 1 for trailing NUL */
#define DATAFILE "essaie.wav"
 
 
int main(void)
{
char *lenstr;
char input[MAXINPUT], data[MAXINPUT];
long len;
printf("%s%c%c\n",
"Content-Type:text/html;charset=iso-8859-1",13,10);;
lenstr = getenv("CONTENT_LENGTH");
if(lenstr == NULL)
printf("lentstr problem\n");
 else if ( sscanf(lenstr,"%ld",&len)!=1)
printf("error sscanf.\n");
 else if ( len > MAXLEN)
  printf("len et MAXLEN prob.\n");
 
else {
  FILE *f;
  fgets(input, len+1, stdin);
  f = fopen(DATAFILE, "a");
  if(f == NULL)
    printf("Sorry, cannot store your data.\n");
  else
    fputs(data, f);
  fclose(f);
  printf("Thank you! Your contribution has been stored.\n");
  }
return 0;
}

le problème est que dans le résultat j'ai une page vide avec aucune information et aucun message de ce que j'ai spécifié.
J'ai essayé de débugger mais sans vain

Pour résumer je veux uploader un fichier essaie.wav de ma machine windows et je voudrais que mon programme CGI qui se trouve sur le serveur linux récupère se fichier et le stocke sur son disque dur.

Avez vous une idée

**Médinoc** · 25/11/2010, 13h57

Ta CGI doit cracher un header HTTP "complet". Donc, si tu veux avoir quelque chose de visible, même des messages d'erreur, il faut au minimum que tu retournes un code HTTP 500 et ton type MIME.

Ou en cas de succès, HTTP 200.

**virus321** · 25/11/2010, 14h07

Merci pour la réponse,

Est ce que vous pouvez m’éclaircir un peu, je débute avec le CGI donc je trouve ta réponse un peu compliqué pour moi

**Médinoc** · 25/11/2010, 14h17

Je pensais à un truc de ce genre-là:

Code :

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

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#include <stdio.h>
#include <stdlib.h>
#define MAXLEN 600000
#define EXTRA 5
/* 4 for field name "data", 1 for "=" */
#define MAXINPUT MAXLEN+EXTRA+2
/* 1 for added line break, 1 for trailing NUL */
#define DATAFILE "essaie.wav"
 
void PrintHeaderAndMessage(int code, char const *code2, char const * message)
{
	printf("HTTP/1.0 %d %s\r\n", code, code2);
	printf("%s","Content-Type:text/html;charset=iso-8859-1\n");
	putchar('\n');
	printf("%s", message);
}
 
int main(void)
{
	char *lenstr;
	char input[MAXINPUT], data[MAXINPUT];
	long len;
 
	lenstr = getenv("CONTENT_LENGTH");
	if(lenstr == NULL)
		PrintHeaderAndMessage(500, "internal server error", "lentstr problem\n");
	else if ( sscanf(lenstr,"%ld",&len)!=1)
		PrintHeaderAndMessage(500, "internal server error", "error sscanf.\n");
	else if ( len > MAXLEN)
		PrintHeaderAndMessage(500, "internal server error", "len et MAXLEN prob.\n");
	else
	{
		FILE *f;
		fgets(input, len+1, stdin);
		f = fopen(DATAFILE, "a");
		if(f == NULL)
			PrintHeaderAndMessage(500, "internal server error", "Sorry, cannot store your data.\n");
		else
		{
			fputs(data, f);
			fclose(f);
			PrintHeaderAndMessage(200, "OK", "Thank you! Your contribution has been stored.\n");
		}
	}
	return 0;
}

**virus321** · 25/11/2010, 14h21

d'accord je comprends

c'est une bonne idée, je vais essayer ça et voir ce que ça donne. attends à me voir dans pas longtemps

j'espère que j'aurais des infos merci pour l'aide

**virus321** · 25/11/2010, 14h41

Re,

j'ai essayé ton code mais rien du tout, je n'ai aucun affichage page vierge

**Médinoc** · 25/11/2010, 14h43

Es-tu sous Windows ou *n*x?

**virus321** · 25/11/2010, 14h49

Je suis sur linux distribution REDhat

**Médinoc** · 25/11/2010, 14h55

Dans ce cas, essaie de précéder explicitement chaque '\n' d'un '\r'.

**virus321** · 25/11/2010, 15h05

Toujours rien

rassurer moi je suis pas si nul que ça !

**Obsidian** · 25/11/2010, 17h33

Bonjour,

Envoyé par Médinoc

Ta CGI doit cracher un header HTTP "complet". Donc, si tu veux avoir quelque chose de visible, même des messages d'erreur, il faut au minimum que tu retournes un code HTTP 500 et ton type MIME.

Ou en cas de succès, HTTP 200.

Envoyé par Médinoc

Je pensais à un truc de ce genre-là:

Pas nécessairement. S'il utilise par exemple un serveur Apache qui, lui, appelle son programme C.G.I. (cas le plus courant), il n'est besoin de préciser le code HTTP de retour que s'il est différent de « 200 OK ». Sinon, cela n'empêchera pas la réponse d'être renvoyée. Par contre, il faut bien un header d'une ligne minimum et terminée par une ligne vide. Donc, le « Content-Type ».

Par contre, je me demande s'il ne faut pas un espace séparateur après le deux-points « : ». Je n'ai pas vérifié.

Ensuite, pour changer le code HTTP le cas échéant, il faut utiliser l'étiquette « Status: » et non balancer l'entête HTTP telle que vue depuis le client.

Envoyé par virus321

le problème est que dans le résultat j'ai une page vide avec aucune information et aucun message de ce que j'ai spécifié.
J'ai essayé de débugger mais sans vain

Il y a des dizaines de raisons qui peuvent empêcher un C.G.I. de fonctionner. Parmi elles :

Le fait que le programme ne soit pas accessible (mauvais chemin) ;
Le fait qu'il ne soit pas exécutable (chmod) ;
Le fait que ses entêtes soient mal formées (très fréquent) ;
Le fait que ses entêtes soient mal formées parce qu'il plante (encore plus fréquent) ;
Des règles oubliées de ré-écriture ou de redirection qui t'envoient au mauvais endroit ;
Un SuexecUserGroup un peu trop tatillon ;
etc.

La première chose à faire est de regarder les logs. Fais un « tail -l /var/log/httpd/acces_log » avec les droits nécessaires (root). Puis fais un appel depuis ton poste client et dis-nous quel message apparaît.

L'ennui est que si ton programme segfaulte (probable), le serveur ne te le dira pas. Il se plaindra juste parce que ton programme lui a envoyé les mauvais headers (c'est-à-dire : aucun). En plus, si ton programme plante, tout ce qui est écrit dans le buffer avec printf() y restera.

De fait, débugger une application CGI n'est pas chose très facile parce qu'il faut intercepter le processus. Le mieux, je pense, est de faire en sorte qu'il s'auto-signale avec SIGSTOP en début de programme, de le récupérer en console avec gdb et le faire poursuivre de là.

**virus321** · 25/11/2010, 17h37

Je reviens vers vous.
J'ai résolu le problème précédent: En effet,la première ligne doit etre Status:XXX et pas HTTP/....

sinon maintenant je suis face à un autre problème dans l'affichage j'ai le résultat

Content-Type:text/html;charset=iso-8859-1

Sorry, cannot store your data.

En gros il tente d'ouvrir le fichier mais il a NULL comme valeur de retour. Je ne comprends pas pourquoi! Pourtant en essayant avec un programme tout con l'ouverture de fichier se passe bien !

**Obsidian** · 25/11/2010, 17h50

Il y a un truc qui s'appelle perror() : ça te donne en toutes lettres la dernière erreur système. Par contre, ça écrit sur la sortie d'erreur standard (« 2 »). Donc, tu auras la réponse dans le log et pas sur le navigateur du client.

Neuf chances sur dix que tu essaies d'ouvrir ton fichier dans le même répertoire que l'exécutable de ta C.G.I. et, donc, que tu n'aies pas le droit de le faire.

**virus321** · 25/11/2010, 18h13

j'ai eu ça comme erreur

fatal lock manager error: Semop failed, errno=22

alors la

**Obsidian** · 25/11/2010, 18h59

Envoyé par virus321

alors la

Quand on ne voit pas, le premier réflexe est de demander à Google s'il a déjà vu ça ou pas. N'attends pas que l'on te dise de le faire.

Et ses résultats montrent que ça a l'air d'être un message d'InterBase. D'où les questions :

Est-ce que tu utilises InterBase sur ton serveur ?
Si oui, c'est que le message en question ne vient pas du tout de ton application.

Accessoirement, semop() est un appel système Unix qui sert à manipuler les sémaphores, mais cela ne te concerne pas pour le moment.

Donc, je repose en plus précis les questions que je t'ai posées plus haut :

À quel endroit (dans quel répertoire) t'attends-tu à recevoir ton fichier ? Parce que dans DATAFILE, il y a écrit « essaie.wav » (avec une faute d'orthographe ;-) ), mais il n'y a aucun chemin d'accès ;
Es-tu sûr que le serveur a le droit d'y écrire ?

**virus321** · 25/11/2010, 19h34

Merci pour la réponse j ai effectivement regardé sur Google et je n'ai pas compris grand chose vu que je ne connais pas interbase et je l utilise pas

Sinon j ai supprimé le DATAFILE et j ai mis a la place un nom de fichier test.wav avec l'option a! Même si le fichier n'existe pas il va le créer.
Maintenat pour l histoire de l endroit, je pense ( peut être je le trompe) que le fichier sera créer dans l endroit ou le cgi est exécuté coté serveur. Je ne voit pas comment il pourrais y avoir des problème de droit. Le script cgi va être exécuter avec les droits root non?

**virus321** · 26/11/2010, 10h15

Bonjour

de bonne humeur ce matin, je suis arrivé à ouvrir le fichier, Effectivement c'est un problème de droit et le cgi ne s'exécute pas en tant que root.( déja je ne sais pas si on peut changer ça )
Donc du coup l'application est passé, il crée bien le fichier et il me sort le message :

Content-Type:text/html;charset=iso-8859-1

Thank you! Your contribution has been stored.

Mais reste à savoir pourquoi le fichier est vide! il n'écrit aucune donnée dedans.

**virus321** · 26/11/2010, 11h15

Pour préciser , j'ai corriger une faute dans le code du cgi ( à la place de data j'ai mis input). les choses sont un peu amélioré car mon fichier passe de 0octet à 46

mais bon vous vous douter bien que ce n'est pas la taille réel. Du coup je pense y'a un problème dans le transfère de fichier ou bien il lit pas l'entrée correctement ou bien il écrit pas dans le fichiers correctement.
Qu'est ce que vous en pensez ?

**Obsidian** · 26/11/2010, 13h09

Envoyé par virus321

Merci pour la réponse j ai effectivement regardé sur Google et je n'ai pas compris grand chose vu que je ne connais pas interbase et je l utilise pas

Ton serveur est à toi ou est-ce celui de ta compagnie ? Parce qu'il fait peut-être tourner des choses qui ne sont pas les tiennes…

Sinon j ai supprimé le DATAFILE et j ai mis a la place un nom de fichier test.wav avec l'option a! Même si le fichier n'existe pas il va le créer.

Il faut en plus préciser explicitement un chemin d'accès vers l'endroit où tu veux qu'il le crée. Pas attendre qu'il fasse un choix pour toi.

Le meilleur endroit — dans un premier temps — pour cela est /var/tmp. Donc, tu peux remettre ton DATAFILE là ou il était, et changer sa définition en début de fichier en « /var/tmp/essai.wav ».

Maintenat pour l histoire de l endroit, je pense ( peut être je le trompe) que le fichier sera créer dans l endroit ou le cgi est exécuté coté serveur. Je ne voit pas comment il pourrais y avoir des problème de droit. Le script cgi va être exécuter avec les droits root non?

Non. Et heureusement.

C'est le serveur Apache qui va lancer ta C.G.I. et elle sera donc lancé sous son identité. Généralement, c'est l'utilisateur « apache ». Essaie « ps aux | grep http » en ligne de commande pour le savoir.

D'une manière générale, lancer un programme en root est une mauvaise idée dans 9 cas sur 10, et c'est pour ainsi dire toujours une erreur de lancer en root quelque chose qui est visible à distance, si l'on peut faire autrement.

L'idée générale, ici, étant de ne pas utiliser root pour contourner une interdiction (ce qui est stupide puisque cette interdiction n'est pas là par hasard), mais d'accorder les droits nécessaires et juste ceux-là à ton application, après mûre réflexion. Dans le cas présent, c'eût consisté à faire un « chmod » sur le bon répertoire. Mais « /var/tmp » est déjà là pour ça.

Envoyé par virus321

de bonne humeur ce matin, je suis arrivé à ouvrir le fichier, Effectivement c'est un problème de droit et le cgi ne s'exécute pas en tant que root.( déja je ne sais pas si on peut changer ça )

On peut mais il ne faut pas le faire.

Donc du coup l'application est passé, il crée bien le fichier et il me sort le message :

Content-Type:text/html;charset=iso-8859-1

Thank you! Your contribution has been stored.

Mais reste à savoir pourquoi le fichier est vide! il n'écrit aucune donnée dedans.

[…]

Pour préciser , j'ai corriger une faute dans le code du cgi ( à la place de data j'ai mis input). les choses sont un peu amélioré car mon fichier passe de 0octet à 46

mais bon vous vous douter bien que ce n'est pas la taille réel. Du coup je pense y'a un problème dans le transfère de fichier ou bien il lit pas l'entrée correctement ou bien il écrit pas dans le fichiers correctement.
Qu'est ce que vous en pensez ?

As-tu au moins essayé d'ouvrir ton fichier pour voir ce qu'il contient ?

D'une part, lorsque tu envoies un fichier, surtout à travers un protocole texte tel que HTTP, tu n'envoies pas seulement le fichier tel quel, mais également un certain nombre d'entêtes, qui contiennent notamment les arguments passés dans l'URL et dans les autres champs <input> lorsqu'ils existent.

Ensuite, tu lis une seule ligne avec ta fonction fgets(). Celle-ci s'arrête au premier retour à la ligne qu'elle rencontre. En l'occurrence, il lit la première ligne mais même en lisant un fichier binaire, si celui-ci contient un code correspondant au retour à la ligne, il n'en faudra pas plus à fgets() pour s'arrêter là.

**virus321** · 26/11/2010, 16h57

Envoyé par Obsidian

Ton serveur est à toi ou est-ce celui de ta compagnie ? Parce qu'il fait peut-être tourner des choses qui ne sont pas les tiennes…

Il faut en plus préciser explicitement un chemin d'accès vers l'endroit où tu veux qu'il le crée. Pas attendre qu'il fasse un choix pour toi.

Le meilleur endroit — dans un premier temps — pour cela est /var/tmp. Donc, tu peux remettre ton DATAFILE là ou il était, et changer sa définition en début de fichier en « /var/tmp/essai.wav ».

Non. Et heureusement.

C'est le serveur Apache qui va lancer ta C.G.I. et elle sera donc lancé sous son identité. Généralement, c'est l'utilisateur « apache ». Essaie « ps aux | grep http » en ligne de commande pour le savoir.

D'une manière générale, lancer un programme en root est une mauvaise idée dans 9 cas sur 10, et c'est pour ainsi dire toujours une erreur de lancer en root quelque chose qui est visible à distance, si l'on peut faire autrement.

L'idée générale, ici, étant de ne pas utiliser root pour contourner une interdiction (ce qui est stupide puisque cette interdiction n'est pas là par hasard), mais d'accorder les droits nécessaires et juste ceux-là à ton application, après mûre réflexion. Dans le cas présent, c'eût consisté à faire un « chmod » sur le bon répertoire. Mais « /var/tmp » est déjà là pour ça.

On peut mais il ne faut pas le faire.

As-tu au moins essayé d'ouvrir ton fichier pour voir ce qu'il contient ?

D'une part, lorsque tu envoies un fichier, surtout à travers un protocole texte tel que HTTP, tu n'envoies pas seulement le fichier tel quel, mais également un certain nombre d'entêtes, qui contiennent notamment les arguments passés dans l'URL et dans les autres champs <input> lorsqu'ils existent.

Ensuite, tu lis une seule ligne avec ta fonction fgets(). Celle-ci s'arrête au premier retour à la ligne qu'elle rencontre. En l'occurrence, il lit la première ligne mais même en lisant un fichier binaire, si celui-ci contient un code correspondant au retour à la ligne, il n'en faudra pas plus à fgets() pour s'arrêter là.

oui, la première fois j'ai eu dans le fichier wav :

----------------------------755643323123

ensuite après ta remarque j'ai essayé de bidouiller pour avoir un truc plus claire: du coup j'ai changé le code de la facon suivante:

Code :

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

1
2
3
4
5
6
7
 
 
 while(stdin!=NULL){
                        fgets(input, len+1, stdin);
                        fputs(input, f);
 
                        }

bon le résultat était mieux si on peut dire ça , j'ai trouvé dans le fichier toute l'entete http et plusieur champs réservé à la requete http, ensuite une suite de caractère bizzare qui sont surêment les données de mon fichier son.
Le problème et que lorsque j'envoie mon fichier la page reste en chargement et j'arrive sur le serveur pour voir le fichier crée. et Surprise taille 280 000 000
:p

et le navigateur s'arrete pas de chargé :p
Bien évidement mon fichier ne dépasse pas les 284000 octet. Du Coup j'ai essayé d'utiliser d'autre fonction comme fread et fscanf mais pas réussi.

Cété peut être pas une bonne idée de le faire en c

mais je dois le faire je suis obligé ( contrainte technique). Je sais que je vous ai trop dérangé mais je sais que vous allez m'aider !

Problème CGI en C

C

Discussions similaires

Partager

Partager