Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jbongran
Badradine wrote:
Bonjour,
Alors, d'abord le contexte:
On a:
- sur n'importe quel station PC connectée à Internet, une appli Delphi client d'un Web Service
- sur un serveur Web, un Web Service qui tourne (physiquement, une DLL ISAPI).
Objectif du système: permettre le transfert de fichiers depuis le PC client vers le serveur Web, et la récupération de fichiers du serveur Web vers le PC client.
Nature du problème:
Pour atteindre l'objectif, on a implémenté à la fois dans l'application cliente et dans la DLL ISAPI (le tout écrit en Delphi) une unité chargé de compresser/décompresser des fichiers. Pour envoyer des fichiers vers le Serveur Web, on compresse les fichiers dans une archive Zip temporaire, on charge l'archive Zip dans un flux (TMemoryStream), on crypte le flux, et on l'envoie au Web Service en l'enveloppant dans un attachement SOAP.
Le Web Service récupère l'attachement SOAP, charge son contenu dans un flux (TMemoryStream), décrypte ce flux, sauvegarde le flux décrypté dans un
fichier temporaire (qui correspond donc à l'archive temporaire générée par l'application cliente), et dézippe finalement l'archive ainsi générée dans un répertoire donné du serveur Web.
Pour l'envoi de fichiers de l'application (et le PC) client(e) vers le
serveur Web, le problème survient au moment de la décompression de l'archive temporaire générée sur le serveur Web. L'algo de cette étape tient en
quelques lignes de code mettant en oeuvre un composant Delphi de compression (ZipTV, cf www.ziptv.com). L'exécution de ce code donne l'impression que l'archive zip est vide (0 fichiers trouvés dans l'archive), alors que cette même archive, ouvert avec Winzip, permet bien de retrouver les fichiers envoyés par l'application cliente. Plus fort: le même algo, c-a-d les mêmes quelques lignes de code, compilées non plus dans la DLL ISAPI mais dans un exécutable autonome, réussissent cette fois-ci parfaitement la
décompression. Donc le même code, appelé dans une DLL ou dans un EXE, ne poduit pas le même résultat.
Pour la récupération des fichiers, le problème est identique; c'est toujours au niveau de la DLL ISAPI que l'anomalie survient, alors que le même code, dans l'application cliente, gère parfaitement la compression/décompression des fichiers...
So, help me please... : )
Rien dans l'obervateur d'evènements ? Un coup de filemeon montre un accès refusé lors du decompactage ? Peut tu compiler ton code en tant que cgi (exe ou dll) pour voir ?
Badradine wrote:
Bonjour,
Alors, d'abord le contexte:
On a:
- sur n'importe quel station PC connectée à Internet, une appli Delphi
client d'un Web Service
- sur un serveur Web, un Web Service qui tourne (physiquement, une DLL
ISAPI).
Objectif du système: permettre le transfert de fichiers depuis le PC
client
vers le serveur Web, et la récupération de fichiers du serveur Web
vers le
PC client.
Nature du problème:
Pour atteindre l'objectif, on a implémenté à la fois dans
l'application
cliente et dans la DLL ISAPI (le tout écrit en Delphi) une unité
chargé de
compresser/décompresser des fichiers. Pour envoyer des fichiers vers
le
Serveur Web, on compresse les fichiers dans une archive Zip
temporaire, on
charge l'archive Zip dans un flux (TMemoryStream), on crypte le flux,
et on
l'envoie au Web Service en l'enveloppant dans un attachement SOAP.
Le Web Service récupère l'attachement SOAP, charge son contenu dans
un flux
(TMemoryStream), décrypte ce flux, sauvegarde le flux décrypté dans un
fichier temporaire (qui correspond donc à l'archive temporaire
générée par
l'application cliente), et dézippe finalement l'archive ainsi générée
dans
un répertoire donné du serveur Web.
Pour l'envoi de fichiers de l'application (et le PC) client(e) vers le
serveur Web, le problème survient au moment de la décompression de
l'archive
temporaire générée sur le serveur Web. L'algo de cette étape tient en
quelques lignes de code mettant en oeuvre un composant Delphi de
compression
(ZipTV, cf www.ziptv.com). L'exécution de ce code donne l'impression
que
l'archive zip est vide (0 fichiers trouvés dans l'archive), alors que
cette
même archive, ouvert avec Winzip, permet bien de retrouver les
fichiers
envoyés par l'application cliente. Plus fort: le même algo, c-a-d les
mêmes
quelques lignes de code, compilées non plus dans la DLL ISAPI mais
dans un
exécutable autonome, réussissent cette fois-ci parfaitement la
décompression. Donc le même code, appelé dans une DLL ou dans un EXE,
ne
poduit pas le même résultat.
Pour la récupération des fichiers, le problème est identique; c'est
toujours
au niveau de la DLL ISAPI que l'anomalie survient, alors que le même
code,
dans l'application cliente, gère parfaitement la
compression/décompression
des fichiers...
So, help me please... : )
Rien dans l'obervateur d'evènements ?
Un coup de filemeon montre un accès refusé lors du decompactage ?
Peut tu compiler ton code en tant que cgi (exe ou dll) pour voir ?
- sur n'importe quel station PC connectée à Internet, une appli Delphi client d'un Web Service
- sur un serveur Web, un Web Service qui tourne (physiquement, une DLL ISAPI).
Objectif du système: permettre le transfert de fichiers depuis le PC client vers le serveur Web, et la récupération de fichiers du serveur Web vers le PC client.
Nature du problème:
Pour atteindre l'objectif, on a implémenté à la fois dans l'application cliente et dans la DLL ISAPI (le tout écrit en Delphi) une unité chargé de compresser/décompresser des fichiers. Pour envoyer des fichiers vers le Serveur Web, on compresse les fichiers dans une archive Zip temporaire, on charge l'archive Zip dans un flux (TMemoryStream), on crypte le flux, et on l'envoie au Web Service en l'enveloppant dans un attachement SOAP.
Le Web Service récupère l'attachement SOAP, charge son contenu dans un flux (TMemoryStream), décrypte ce flux, sauvegarde le flux décrypté dans un
fichier temporaire (qui correspond donc à l'archive temporaire générée par l'application cliente), et dézippe finalement l'archive ainsi générée dans un répertoire donné du serveur Web.
Pour l'envoi de fichiers de l'application (et le PC) client(e) vers le
serveur Web, le problème survient au moment de la décompression de l'archive temporaire générée sur le serveur Web. L'algo de cette étape tient en
quelques lignes de code mettant en oeuvre un composant Delphi de compression (ZipTV, cf www.ziptv.com). L'exécution de ce code donne l'impression que l'archive zip est vide (0 fichiers trouvés dans l'archive), alors que cette même archive, ouvert avec Winzip, permet bien de retrouver les fichiers envoyés par l'application cliente. Plus fort: le même algo, c-a-d les mêmes quelques lignes de code, compilées non plus dans la DLL ISAPI mais dans un exécutable autonome, réussissent cette fois-ci parfaitement la
décompression. Donc le même code, appelé dans une DLL ou dans un EXE, ne poduit pas le même résultat.
Pour la récupération des fichiers, le problème est identique; c'est toujours au niveau de la DLL ISAPI que l'anomalie survient, alors que le même code, dans l'application cliente, gère parfaitement la compression/décompression des fichiers...
So, help me please... : )
Rien dans l'obervateur d'evènements ? Un coup de filemeon montre un accès refusé lors du decompactage ? Peut tu compiler ton code en tant que cgi (exe ou dll) pour voir ?
Yanos El Guerilleros
>
Rien dans l'obervateur d'evènements ? Un coup de filemeon montre un accès refusé lors du decompactage ? Peut tu compiler ton code en tant que cgi (exe ou dll) pour voir ?
A cela je rajoute :
- ces composants ont-ils besoins de DLL externes, et dans ce cas là sont-elles bien dans windows/system32 ?
- ces composants ne font-ils pas appels par hazard à une pompe à message (genre Application.ProcessMessages) ce qui dans une DLL peut poser des problèmes ?
- est-ce que les fonctions de bases fonctionnent dans une DLL ? Genre 1 DLL avec un composant qui se contente d'extraire une archive, sans code particulier. Cela juste pour vérifier si il s'agit d'un problème avec les composants dans une DLL ou ton propre code qui fait un truc qui ne plait pas.
- A priori étant donné que même dans une DLL ca ne fonctionne pas trop, je pense plus qu'il s'agit d'un problème Delphi que d'un problème IIS, aussi je te conseilles de poser ta question sur un forum Delphi/Pascal
A++
Yanos
>
Rien dans l'obervateur d'evènements ?
Un coup de filemeon montre un accès refusé lors du decompactage ?
Peut tu compiler ton code en tant que cgi (exe ou dll) pour voir ?
A cela je rajoute :
- ces composants ont-ils besoins de DLL externes, et dans ce cas là
sont-elles bien dans windows/system32 ?
- ces composants ne font-ils pas appels par hazard à une pompe à message
(genre Application.ProcessMessages) ce qui dans une DLL peut poser des
problèmes ?
- est-ce que les fonctions de bases fonctionnent dans une DLL ? Genre 1
DLL avec un composant qui se contente d'extraire une archive, sans code
particulier. Cela juste pour vérifier si il s'agit d'un problème avec
les composants dans une DLL ou ton propre code qui fait un truc qui ne
plait pas.
- A priori étant donné que même dans une DLL ca ne fonctionne pas trop,
je pense plus qu'il s'agit d'un problème Delphi que d'un problème IIS,
aussi je te conseilles de poser ta question sur un forum Delphi/Pascal
Rien dans l'obervateur d'evènements ? Un coup de filemeon montre un accès refusé lors du decompactage ? Peut tu compiler ton code en tant que cgi (exe ou dll) pour voir ?
A cela je rajoute :
- ces composants ont-ils besoins de DLL externes, et dans ce cas là sont-elles bien dans windows/system32 ?
- ces composants ne font-ils pas appels par hazard à une pompe à message (genre Application.ProcessMessages) ce qui dans une DLL peut poser des problèmes ?
- est-ce que les fonctions de bases fonctionnent dans une DLL ? Genre 1 DLL avec un composant qui se contente d'extraire une archive, sans code particulier. Cela juste pour vérifier si il s'agit d'un problème avec les composants dans une DLL ou ton propre code qui fait un truc qui ne plait pas.
- A priori étant donné que même dans une DLL ca ne fonctionne pas trop, je pense plus qu'il s'agit d'un problème Delphi que d'un problème IIS, aussi je te conseilles de poser ta question sur un forum Delphi/Pascal
