none
Accés au HEADER HTTP avec les Services References sur Visual Studio 2010 RRS feed

  • Question

  • Bonjour,

    je suis sur Visual Studio 2010. J'utilise un WebService via son WSDL que j'ai intégré via les Services Reference.

    Problème : je n'ai pas la main sur le HEADER HTTP envoyé via client sur Visual Studio. Quelqu'un saurait comment prendre la main dessus, sachant que cela était possible sous 2005 ??
    mercredi 24 août 2011 12:39

Réponses

  • Bonjour,

     

    le problème était causé par le fait que le serveur hebergeant le WebService renvoyait le champ Content Type vide dans l'en tête de sa réponse SOAP.Ceci était causé par le fait que dans la requête envoyé par le serveur, le paramétre User-Agent était manquant dans l'en-tête SOAP.

    Pour pouvoir rajouter ce paramétre, il faut avoir accès aux Header de la requête. Ceci n'est pas faisable en utilisant les services References.

    Je suis donc passer par la bibliothéque HTTPWebRequest pour construire mon en-tête.

     

    Merci de votre aide,

    mercredi 31 août 2011 12:31

Toutes les réponses

  • Bonjour, Yassine228,

    Pouvez-vous svp nous donner plusieurs détails sur votre problème ? Par exemple, qu’est-ce que vous voulez dire par « le HEADER HTTP envoyé via client sur Visual Studio » ? Vous dites qu’il était possible prendre la main de HEADER HTTP sur VS2005. Quel est la version de votre .NET framework cible du projet de votre client ?

     

    Bonne journée,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    vendredi 26 août 2011 06:39
  • Bonjour Ciprian,

     

    à chaque appel WebService, via un client de type soapUI par exemple, un header de ce type est envoyé en-tête du message:

    POST http://172.16.152.23:4500/srvXrpc HTTP/1.1
    Accept-Encoding: gzip,deflate
    Content-Type: text/xml;charset=UTF-8
    SOAPAction: "urn:srvXrpc#yOPEGetAgenda"
    User-Agent: Jakarta Commons-HttpClient/3.1
    Host: 172.16.152.23:4500
    Content-Length: 573

     

    L'utilisation des Services References sur Visual Studio 2010 / .NET 4 ne permet d'avoir accès aux variables de cet en-tête pour les modifier. En effet, lors de l'execution de mon projet, l'exception de type ProtocolException suivante m'est retournée :

    "Un en-tête Content-Type HTTP est requis pour la messagerie SOAP et aucun n'a été trouvé."

     

     

    Merci d'avance pour votre aide,

     

    Yassine

    vendredi 26 août 2011 07:58
  • Bonjour,

    Selon votre description, je suppose que vous utilisez un WebService WCF. Merci d’avoir précisé le message d’erreur, qui m’a aidé à trouver des discussions sur sujets similaires.

    Sur ce thread la cause de l’erreur était le fait que le serveur n’envoyé pas l’en-tête, mais la situation est un peu différente de ce que vous avez décrit. Puis sur ce thread, le contenu interne de l’exception leurs a donné plusieurs détails sur l’erreur. Pouvez-vous nous préciser aussi le message complet d’erreur ?

    Puis, est-ce que vous utilisez Entity Framework dans votre service ? Dans l’affirmative essayez cette solution.

    Finalement, je vous invite aussi à tester les solutions proposées sur ce lien quand l’en-tête n’est pas dans la réponse reçue par le client.

    Merci de tenir la communauté informée sur la suite de vos démarches.

     

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    vendredi 26 août 2011 10:15
  • Bonjour,

    je ne pense pas utiliser WCF, vous trouverez plus bas mon code source. Je n'utilise pas Entity Framework.

    Voici la stack de l'erreur :

    l'erreur ProtocolException suivante s'est produite Un en-tête Content-Type HTTP
    est requis pour la messagerie SOAP et aucun n'a été trouvé.
    Server stack trace:
       à System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyRespo
    nse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory factory
    , WebException responseException, ChannelBinding channelBinding)
       à System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChan
    nelRequest.WaitForReply(TimeSpan timeout)
       à System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSp
    an timeout)
       à System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message
    , TimeSpan timeout)
       à System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean one
    way, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan time
    out)
       à System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallM
    essage methodCall, ProxyOperationRuntime operation)
       à System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

    Exception rethrown at [0]:
       à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqM
    sg, IMessage retMsg)
       à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgDat
    a, Int32 type)
       à ConsoleApplication1.srvXrpc.srvXrpcPortType.yOPEGetAgenda(yOPEGetAgendaRequ
    est request)
       à ConsoleApplication1.srvXrpc.srvXrpcPortTypeClient.yOPEGetAgenda(yOPEGetAgen
    daRequest request) dans C:\Users\y.zyad\Documents\Visual Studio 2010\Projects\Ou
    tlook_Psoft_Connector\ModeConsole\ConsoleApplication1\ConsoleApplication1\Servic
    e References\srvXrpc\Reference.cs:ligne 2012
       à ConsoleApplication1.Program.Main(String[] args) dans C:\Users\y.zyad\Docume
    nts\Visual Studio 2010\Projects\Outlook_Psoft_Connector\ModeConsole\ConsoleAppli
    cation1\ConsoleApplication1\Program.cs:ligne 55
    Appuyez sur une touche pour continuer...

     

    D'autre part, voici mon code source :

    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;
    using System.ServiceModel;
    using System.Net;

    namespace ConsoleApplication1
    {
        class Program
        {
       
            static void Main(string[] args)
            {

                srvXrpc.yOPEGetAgenda_input entree = new srvXrpc.yOPEGetAgenda_input();
                entree.username = "xxxxxxxx";
                entree.password = "xxxxxxxxx";
                entree.sId = "1";

                srvXrpc.yOPEGetAgendaRequest requete = new srvXrpc.yOPEGetAgendaRequest(entree); //construction de la requête avec les paramètres d'entrée

                srvXrpc.srvXrpcPortTypeClient Agenda = new srvXrpc.srvXrpcPortTypeClient();

          
                try
                {
                   srvXrpc.yOPEGetAgendaResponse retour = new srvXrpc.yOPEGetAgendaResponse();
                   retour = Agenda.yOPEGetAgenda(requete); //on récupere la réponse de XAS
                  
                   String reponse = retour.ToString();
                   Console.WriteLine("réponse" + "\r\n" + reponse);
                }
                   
                catch (System.ServiceModel.ProtocolException e1)
                {
                    Console.Error.WriteLine("l'erreur ProtocolException suivante s'est produite " +e1.Message + e1.StackTrace);
                }
               
               
               
               
               
            }
        }
    }

    vendredi 26 août 2011 10:28
  • Bonjour,

    L’espace des noms System.ServiceModel est spécifique à WCF et malheureusement la stack de l’erreur n’offre pas plus d’infos sur l’erreur. Un système de log pour le service web pourrait nous donner une idée sur la source de votre erreur, mais vu que cette erreur est sur la stack du serveur, aussi qu’au niveau du client je crois que c’est le client qui n’envoie pas l’en-tête.

     

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    vendredi 26 août 2011 12:17
  • Bonjour,

     

    j'ai utilisé Fiddler pour tracer les messages HTTP échangés. Dans la réponse envoyé par le serveur, au niveau du Header, il manque effectivement la valeur du champ Content Type.

    Lorsque j'execute la requête via soapUI, j'obtiens la valeur suivante pour Content Type : text/xml

     

    Pourquoi mon serveur répond de manière différente à deux requêtes identiques ?

     

     

    vendredi 26 août 2011 12:34
  • Bonjour,

    Est-ce que le message envoyé par votre client contient la valeur du champ Content Type au niveau du Header ? L’erreur trouvée sur le stack me fait penser que tout d’abord c’est le serveur qui ne trouve pas le champ et puis la même erreur est trouvée au niveau de votre client (« Exception rethrown at [0]: »), donc peut-être les deux requêtes ne sont pas vraiment identiques.

     

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    lundi 29 août 2011 08:17
  • Bonjour,

     

    j'ai utilisé le logiciel Fiddler pour tracer les échanges entre le client et le serveur. Le contenu du champ Content Type est bien envoyé au serveur. LA réponse du serveur ne contient pas la valeur du champ Content Type.

    D'autre part, le serveur ne répond pas à la requête que je lui envoi, il me renvoie tout le wsdl du WebService.

    Avez-vous à disposition le wsdl d'un webservice simple se trouvant sur le web pour que je fasse un test, je pourrai identifier si le problème vient du serveur que j'interroge.

     

    Merci d'avance

    lundi 29 août 2011 08:28
  • Bonjour,

     

    Et si vous essayer de faire un update de votre web référence, ça donne quoi ?

     

    Cdt.

    lundi 29 août 2011 11:42
  • Bonjour,

    j'ai fait un update sur ma référence Web. Pas de changements j'ai toujours la même erreur de Content Type manquant dans l'en-tête SOAP.

     

     

    lundi 29 août 2011 11:49
  • Bonjour,

    Avez-vous essayé à tester en utilisant le WSDL d’un autre service Web ? Normalement, si le message envoyé par le client contient le champ Content Type, mais la réponse du service ne le contient pas, cela indique une erreur au niveau du servie Web. Est-ce que l’erreur est reçue pour toutes les méthodes de votre service Web ou seulement pour yOPEGetAgenda ?

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    mardi 30 août 2011 06:04
  • Bonjour,

     

    j'ai utlisé le WSDL d'un autre service Web, cela fonctionne bien. J'ai essayé une autre méthode du service Web, cela me renvoie la même erreur.

    Il doit y avoir une spécificité aux environnements .NET car ce service Web fonctionne bien dans d'autres environnements.

     

    Cordialement,

     

     

    mardi 30 août 2011 07:57
  • Bonjour,

    J’ai revu toute la discussion qu’on a eu et je ne peux pas ni confirmer ni infirmer si le problème vient de quelque chose spécifique aux environnements .NET.

    Ce que je ne comprends pas est pourquoi l’erreur se trouve d’abord sur le stack trace du service Web et puis est retrouvée aussi au niveau du client si l’en-tête est envoyé par le client. Puis avec soapUI le résultat est différent pour la même requête et vous dites aussi que dans autres environnements le service Web fonctionne sans problèmes, donc ça veut dire qu’en fait le problème est au niveau du votre client, mais je ne peux pas trouver une explication concrète. En plus, il est difficile dire d’où vient l’erreur vu que je n’ai pas accès à votre service Web pour l’interroger et vois son comportement (en utilisant un client similaire avec lequel vous utilisez).

    En cette situation, je vous recommande essayer d’obtenir d’aide de Microsoft Support parce qu’ils peuvent reproduire votre contexte et les discussions avec eux ne sont pas publics et vous pouvez leur donner toutes les informations nécessaires.

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    mardi 30 août 2011 11:20
  • Bonjour,

     

    le problème était causé par le fait que le serveur hebergeant le WebService renvoyait le champ Content Type vide dans l'en tête de sa réponse SOAP.Ceci était causé par le fait que dans la requête envoyé par le serveur, le paramétre User-Agent était manquant dans l'en-tête SOAP.

    Pour pouvoir rajouter ce paramétre, il faut avoir accès aux Header de la requête. Ceci n'est pas faisable en utilisant les services References.

    Je suis donc passer par la bibliothéque HTTPWebRequest pour construire mon en-tête.

     

    Merci de votre aide,

    mercredi 31 août 2011 12:31
  • Bonjour,

    Merci d’avoir partagé avec nous les résultats. Une solution similaire, mais avec WebClient au lieu de HTTPWebRequest était présentée sur ce lien que je vous ai déjà proposé. De toute façon, merci d’avoir partagé avec nous la cause de l’erreur et la solution.

     

    Cordialement,

    Cipri


    Suivez MSDN sur Twitter   Suivez MSDN sur Facebook


    Ciprian DUDUIALA, MSFT  
    •Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    mercredi 31 août 2011 13:13