2009-05-29 6 views
1

Nous avons installé un site Web ASP.NET sur le serveur d'un client. Ce site dispose d'un service web avec quelques méthodes web qui sont appelées par un objet Flash afin d'afficher un fil de nouvelles. Si vous naviguez sur leur site (ex: www.domain.com), tout fonctionne correctement sauf le flash. Le problème est que lorsque nous naviguons vers le .asmx, l'en-tête montre que l'hôte est un sous-domaine interne à son réseau (internal.domain.com). Évidemment, cela ne résout pas à toute adresse IP publique lors de la navigation de l'extérieur de leur réseau. Cela provoque l'échec du Flash car l'objet flash est incorporé sur une page et exécute donc le côté client.Problème avec les URL incorrectes dans le fichier WSDL d'un service Web .NET

J'ai vérifié le nom de l'ordinateur sur le serveur en question, et il ne correspond même pas "internal.domain.com" - c'est quelque chose de complètement différent. D'où provient cette information. Il ne provient pas d'IIS, car aucun en-tête d'hôte n'est configuré et l'adresse IP du site est définie sur (tous non affectés).

Nous devons soit forcer le service Web à s'exécuter sur un hôte spécifique, soit changer quelque chose sur le serveur afin qu'il se résout en un nom d'hôte public valide. Toute aide est grandement appréciée !!!!

+0

Est-ce un fichier svc WCF ou un service asmx plaine? –

+0

Je ne suis pas tout à fait sûr, car je ne suis pas la personne qui a initialement ajouté le service web dans le projet. Quelle serait la différence? Tout ce que je sais, c'est qu'il y a un fichier .asmx dans un dossier WebServices à la racine du site, et le fichier codebehind (.cs) est dans le répertoire App_Code. C'est à peu près tout ce qu'il y a à faire. – Keith

+0

Nous avons découvert que notre client utilisait un proxy inverse pour son trafic web/réseau, donc l'en-tête de l'hôte qui arrivait ne correspondait pas à l'url/hostname réel. Ils n'étaient pas en mesure de le résoudre, nous avons donc dû supprimer la partie du flash qui appelait le service Web. – Keith

Répondre

0

Alors que vous avez probablement déjà fait cela, il est toujours une bonne première étape:

Faites une recherche globale dans le code source à la fois l'objet Flash et le service Web pour la chaîne en question.

Il semble que quelqu'un ait configuré/codé la chaîne internal.domain.com dans la requête de l'objet Flash. (Hôte: un en-tête de demande HTTP, pas en-tête de réponse, IIRC.)

+0

Merci pour la réponse, mais ce n'est pas un problème avec le flash, mais avec le service Web lui-même. Si vous naviguez directement vers le fichier .asmx dans un navigateur, et cliquez sur l'un des webmethods, puis examinez l'en-tête SOAP, vous voyez "Host: internal.domain.com". Et j'ai fait une recherche pour internal.domain.com au sein de l'ensemble de la solution (et je savais qu'aucun résultat ne serait retourné puisque nous n'avions évidemment jamais su qu'internal.domain.com existait). Ce nom d'hôte doit provenir de la machine elle-même, mais où? – Keith

0

L'objet Flash obtient-il l'URL du service Web à partir du code C#? Si tel est le cas, il se peut que vous obteniez l'URL du service Web par défaut que vous choisissez lors de l'ajout d'une référence Web à votre projet dans VS. Par conséquent, il peut pointer vers une URL locale vers la machine/le serveur du développeur qui n'est pas reconnue sur le serveur en ligne.

+0

Encore une fois, cela a été développé sur nos boîtes de dev, et nos boîtes de dev n'ont aucune idée de ce qu'est internal.domain.com, donc il n'y aurait jamais de chance que cela soit par défaut. D'une certaine manière, le nom d'hôte sur le serveur de notre client se résout en interne.domain.com au lieu de www.domain.com. J'ai vérifié par IIS et dans le champ de nom d'ordinateur (mon ordinateur -> propriétés -> nom d'ordinateur), et nulle part est internal.domain.com mentionné/référencé. – Keith