Discussion :

[Arno_94]

Bonjour à tous et à toutes,

Je suis confronté à un souci inédit pour moi et j'ai bien du mal à trouver une explication.

Le prob est simple : intégrer un lecteur media branché sur une playlist Youtube.

Je n'ai pas le choix, je dois utiliser le composant de Telerik. Il suffit de lui donner le nom de la Playlist et il fait la requête automatiquement pour récupérer les vidéos. C'est là que le problème apparaît : "Impossible de se connecter, le serveur ne répond pas, bla bla".

Comme je suis dans un contexte entreprise dont je ne connais pas encore la stratégie réseau, j'en ai conclu que nous avions possiblement des ports bloqués qui nous empêcherait d'effectuer cette requête.

Puis, en grattant un peu, j'ai trouvé l'url appelée par le composant (c'était pas dur, c'est gdata.youtube.com en l'occurrence).

Pour être sûr que ce soit bien ce que je voulais, j'ai fait la requête à la va-vite via jQuery pour m'afficher bêtement le résultat dans une alert.

Et là, parfait, j'ai ma réponse avec les infos désirées.

Du coup, je décide de faire le travail de Telerik (récupérer la PL puis créer une liste de vidéos que j'enverrai "à la main" au composant).

Je passe donc par une WebRequest et là, j'obtiens le même résultat qu'avec le composant (impossible de se connecter, le serveur ne répond pas, bla bla).

J'ai du mal à comprendre pourquoi la requête fonctionne sans souci via jQuery mais pas en code behind.

Auriez-vous une idée ?

D'avance merci.

[DotNetMatt]

Comme je suis dans un contexte entreprise dont je ne connais pas encore la stratégie réseau, j'en ai conclu que nous avions possiblement des ports bloqués qui nous empêcherait d'effectuer cette requête.

A priori tu as toi-même donné la réponse ! Renseigne toi sur la stragégie réseau, ce sera déjà un bon point de départ. La seule chose dont on puisse être sûr c'est que le port 80 ne doit pas être bloqué, vu que c'est par-là que passe le traffic HTTP. A noter si la requête vers Youtube est en HTTPS, c'est le port 443 qui est utilisé...

[mermich]

Salut,

Je ne puis que te conseiller d'utiliser fiddler un soft fait par telerik(gratuit) pour regarder ce qui est envoye par ton code dotnet.

Tu avancera plus rapidement.

[Arno_94]

Merci pour ton aide.

Toutefois, ce n'est plus pertinent de chercher du côté de Telerik car j'ai effectué la requête "à la main" via l'objet WebRequest et, systématiquement, il renvoie une erreur de serveur distant inaccessible tandis que la même requête de la même page mais côté client (via jQuery) me renvoie le résultat souhaité...

Donc, oublions Telerik, le problème est : Une requête web fonctionne côté JavaScript mais ne fonctionne pas côté code behind. On peut aussi exclure le HTTPS de youtube car j'ai essayé avec des free feeds (http://gearside.com/public-json-feeds/) et j'obtiens le même résultat (réponse instantanée et correcte côté JS mais serveur injoignable côté code-behind...). Je pas comprendre...

[mermich]

donc c'est bien un probleme de WebRequest/reseau, je preconise donc de lancer fiddler et tu verra les trames http envoyees/recues.

Sans-doute une restriction de l'admin reseau...
T'as essayer de lancer ton programme en mode admin ?

[Arno_94]

Bonjour,

A nouveau, merci de t'intéresser à mon souci.

Hier, j'ai copié coller le code pour le tester chez moi et effectivement, ça passe comme une lettre à la poste.

Le prob vient donc bien d'une restriction réseau ici.

Toutefois, j'ai du mal à comprendre pourquoi, dans le même projet, sur la même page, la requête n'aboutit pas via code behind et WebRequest mais qu'elle passe bien via jQuery côté aspx...

[DotNetMatt]

Peut-on voir ton code et ton web.config ?

[Arno_94]

Côté ASPX :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
<script type="text/javascript">
         $(document).ready(function () {
             $.ajax({
                 type: "GET",
                 url: "<a href="https://gdata.youtube.com/feeds/api/playlists/PLo9h0dMEvwhPtCg638qOYAS7uCt3-K6aM" target="_blank">https://gdata.youtube.com/feeds/api/playlists/PLvmaC-XMqeBb991YNEWAHYL9ZJAeURr-r</a>"
             }).done(function (msg) {
                 alert(msg);
             });
         });
</script>

Ca, ca fonctionne à merveille, j'obtiens un objet XML contenant bien les infos liées à la PlayList.
Edit : Il n'y a pas de balise <a> dans le code original, elle a été ajoutée à mon insu.

Côté codebehind :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
        WebRequest request = WebRequest.Create("https://gdata.youtube.com/feeds/api/playlists/PLvmaC-XMqeBb991YNEWAHYL9ZJAeURr-r");
        request.Credentials = CredentialCache.DefaultCredentials;
        using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
        {
            using (Stream dataStream = response.GetResponseStream())
            {
                using (StreamReader reader = new StreamReader(dataStream))
                {
                    string responseFromServer = reader.ReadToEnd();
                }
            }
        }

Ca, ça ne répond pas (serveur distant inaccessible)

Web.Config :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?xml version="1.0"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
    <system.web>
      <compilation debug="true" targetFramework="4.5" />
      <httpRuntime targetFramework="4.5" />
    </system.web>
</configuration>

Bien sûr, ce n'est pas le "vrai" web.config de l'appli mais, question d'être sûr que mes soucis ne proviennent pas du framework interne, j'ai crée un nouveau projet from scratch (qui me donne les mêmes résultats), d'où ce web.config désertique...

[DotNetMatt]

Merci, il n'y a à première vue rien de choquant

Le fait de voir le code behind me fait penser qu'il y a peut-être un proxy en sortie, et peut-être que ce dernier nécessite des identifiants particuliers pour laisser passer les communications ? Bref à voir avec l'équipe réseau de chez toi

[Arno_94]

Merci DotNetMatt,

J'en viens à la même conclusion mais il me reste une interrogation pour mon information personnelle.

Pourquoi la requête passe via jQuery mais pas en code behind ? Les "tuyaux" utilisés sont sensés être les mêmes, non ? (en l’occurrence, une requête HTTP).

[mermich]

Non, ce ne sont pas forcement les memes.

ton navigateur peut s'executer en mode admin, tu peux avoir un proxy, et cote reseau l'admin peut filtrer l'acces a une liste de programmes par exemple.

[DotNetMatt]

Les "tuyaux" utilisés sont sensés être les mêmes, non ? (en l’occurrence, une requête HTTP).

Pas forcément, et même si c'était le cas il pourrait y avoir des comportements différents. Je m'explique.

On peut avoir les mêmes règles appliquées aux PC des employés et aux serveurs. Mais on peut aussi appliquer des règles différentes aux PC des employés (en général plus souples), et des règles spécifiques pour les serveurs (en général plus rigides et contraignantes).

Après on peut aussi avoir des scénarios bien plus complexes, et c'est souvent le cas dans les banques par exemple. Les serveurs étaient carrément isolés d'Internet par défaut (bon, j'exagère un peu, mais c'était pas loin de ca). Pour avoir y avoir accès, il fallait suivre une procédure ultra relou avec tout un tas de validations, faire ouvrir des routes dans une galaxie de firewalls, faire configurer les "sondes", etc...

Donc pour répondre à ta question, on peut supposer que depuis ton PC ca marche car il a plus de permissions et/ou le traffic HTTP n'est pas filtré.

[Arno_94]

Très bien, merci pour toutes ces informations. Ceci met un peu plus en exergue mes lacunes concernant le réseau.

Encore merci à tous.