Controle Existance de Fichier par le Net

Version imprimable

21/09/2009, 22h13
Danyel

Controle Existance de Fichier par le Net

Salut All,

Je cherche un moyen efficace et rapide de rechercher et controler si un fichier (dont je connais le nom) est present sur un serveur par internet (connu aussi)
Ca fait qq temps que je cherche sur msdn et autres, mais sans grand resultat.
J'ai passe en revu le My.Computer.Network et le System.Net mais ...

Le mieux que j'ai trouve serait le system.net.webclient, mais j'ai juste besoin d'un retour de boolean.

Merci pour votre aide.

Il faut faire une requête HTTP "HEAD" (et non POST ou GET), de façon à récupérer seulement les en-têtes. Si tu récupères un code 200 (OK), le fichier existe. S'il n'existe pas, c'est un 404 (Not found).

La méthode suivante renvoie True si l'URL existe (200), False si elle n'existe pas (404), et lève une exception si une autre erreur se produit

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Function CheckUrlExists(url As String) As Boolean
    Dim request As HttpWebRequest = DirectCast(WebRequest.Create(url), HttpWebRequest)
    request.Method = "HEAD"
    Try
        Using response As HttpWebResponse = DirectCast(request.GetResponse(), HttpWebResponse)
            If response.StatusCode = HttpStatusCode.OK Then
                Return True
            Else
                Return False
            End If
        End Using
    Catch ex As WebException
        Dim response As HttpWebResponse = TryCast(ex.Response, HttpWebResponse)
        If response IsNot Nothing AndAlso response.StatusCode = HttpStatusCode.NotFound Then
            Return False
        Else
            Throw
        End If
    End Try
End Function

22/09/2009, 16h39
Danyel

Je me suis arrete sur ce fameux system.net.httpwebrequest mais il faut dire que la doc m'a laisse ... comment dire ... perplexe ;)
Un immense merci pour cette function que je vais aller tester de ce pas.
22/09/2009, 18h12
Danyel

C'est nickel tom.
J'ai juste rajoute un timeout et qq specifications.
Par contre, je me demande pourquoi le throw ? merci de m'eclairer ;)
22/09/2009, 19h07
tomlev

Citation:

Envoyé par Danyel

C'est nickel tom.
J'ai juste rajoute un timeout et qq specifications.
Par contre, je me demande pourquoi le throw ? merci de m'eclairer ;)

En fait, HttpWebRequest.GetResponse lève toujours une exception si le serveur renvoie un code d'erreur (ce que je trouve pas très pratique d'ailleurs...), d'où le catch. Si l'exception est due à une erreur 404, c'est une erreur "attendue", donc on renvoie False pour dire que le fichier n'existe pas. Par contre, si c'est une autre erreur, genre accès refusé, on ne peut pas déterminer si le fichier existe, donc on relance l'exception interceptée par le catch (c'est à ça que sert le Throw sans paramètre, au cas où tu te demandais ;))
22/09/2009, 19h49
Danyel

Génial ... que dire de plus ;)
22/09/2009, 20h06
Danyel

Arf pas glop, je viens de me rendre compte que l'appel fait executer le fichier demande ... et ca c'est pas bon !!!
Une autre idee ?
23/09/2009, 01h22
tomlev

Citation:

Envoyé par Danyel

Arf pas glop, je viens de me rendre compte que l'appel fait executer le fichier demande ...

Hein ? :koi:
Quel genre de fichier ? Si c'est un exe, il ne sera sûrement pas exécuté, ou alors je sais pas ce que tu utilises comme serveur :?
Par contre si c'est une page ASPX, PHP ou assimilé, ce sera effectivement exécuté. En quoi est-ce un problème ? C'est fait pour ça...
23/09/2009, 01h55
Danyel

Ce sont des fichiers .cgi ou .pl (tous en perl) en chmod 755.
L'inconvenient, c'est que la plupart attendent des datas et s'executent pour faire qq chose ... qui peuvent engendrer d'autres actions ... etc.

J'avais créé plusieurs fichiers pour faire mes tests, mais en condition reelle, ca a foutu un bord.. total ;)
Juste un petit exemple :
Comme je controle ce qui entre et sors de mes cgi, il y a donc appel de 1 (ou il manque des datas), cela provoque une erreur (que je gere) et qui m'envoi (entre autre) des mails d'alertes ...
Dans le pire des cas, ca peut planter le serveur ... :(

En reflechissant un peu, et si tu n'as pas d'autres solutions pour faire ce check de fichier (sans l'executer), je peux de le contourner en appelant un autre cgi/perl ...
23/09/2009, 02h00
tomlev

Attends, tu me fais peur là... ces scripts sont supposés pouvoir s'exécuter en HTTP ou pas ? parce que si ce n'est pas le cas, tu aurais intérêt à revoir en vitesse les autorisations des fichiers et la conf du serveur web :aie:

S'ils sont prévus pour s'exécuter en HTTP, il n'y a pas de moyen d'y accéder sans les exécuter (heureusement, sinon on pourrait récupérer les sources serveur de n'importe quel site...). Par contre tu peux créer un script qui vérifie sur le serveur l'existence du fichier spécifié, tu appelles ce script et tu regardes le résultat
23/09/2009, 02h36
Danyel

Citation:

Envoyé par tomlev

Attends, tu me fais peur là... ces scripts sont supposés pouvoir s'exécuter en HTTP ou pas ?

Bien sur que si :lol:
En fait, apres cette verification, je les utilise ;)

Citation:

Envoyé par tomlev

S'ils sont prévus pour s'exécuter en HTTP, il n'y a pas de moyen d'y accéder sans les exécuter (heureusement, sinon on pourrait récupérer les sources serveur de n'importe quel site...).

Effectivement, c'est d'une logique implaquable, mais je ne pensais pas dans mon cas precis.

Citation:

Envoyé par tomlev

Par contre tu peux créer un script qui vérifie sur le serveur l'existence du fichier spécifié, tu appelles ce script et tu regardes le résultat

C'est ce dont a quoi je pensais.

Merci pour ta patience et ton aide tom. :ccool:

ps : je suis quand meme etonne que tu ne m'as pas demande pourquoi j'utilise vb alors que perl est tres tres proche du c ;)
23/09/2009, 03h01
tomlev

Citation:

Envoyé par Danyel

ps : je suis quand meme etonne que tu ne m'as pas demande pourquoi j'utilise vb alors que perl est tres tres proche du c ;)

Ben je sais bien que tu es un indécrottable VBiste :mouarf:
Perl très très proche du C ? la syntaxe ressemble un peu (et encore) mais à part ça les 2 langages n'ont pas grand chose en commun...