none
Comment modifier le header d'une reponse d'un HTTPChannel RRS feed

  • Question

  • Bonjour,

    J'utilise une HTTPChannel pour recevoir et traiter des donnees depuis plusieurs centaines de machine. J'ai un probleme sur la construction du header de la reponse HTTP. En effet, le HTTPChannel renvoie Content-Length alors que les clients (qui sont case sensitive) attende Content-length.

     

    Existe t'il un moyen de forcer le formatage du texte juste avant de renvoyer la reponse.

     

    Merci d'avance.

     

    jeudi 10 février 2011 14:43

Toutes les réponses

  • Bonjour,

    Sans expérience sur le sujet mais d'après ce que comprend de la doc ce constructeur http://msdn.microsoft.com/en-us/library/aze39x67.aspx permet d'associer au HttpChannel des "SinkProvider" qui donnent apparemment accès aux messages envoyés et reçus.

    Egalement, vérification faite les différentes sources utilisent le plus souvent Content-Length mais la RFC indique bien que les headers ne sont pas censés être sensibles à la casse.

    Je ne sais pas quel est l'origine de ces clients mais à priori ce sont les clients qui ne sont pas conformes ce qui serait sans doute à signaler à leurs développeurs...

    Pour la RFC c'est http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html, chapitre 4.2 : "Field names are case-insensitive".

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    samedi 12 février 2011 10:36
    Modérateur
  • Bonjour,

     

    Effectivement les clients ne sont pas conforme mais les modifier entrainerait la modification de plusieurs milliers de client ce qui entraine d'autre probleme. D'ou ma recherche de solution alternative.

    J'ai deja effectivement utiliser des SinkProvider (le donnees sont transferees suivant la norme XMLRPC et j'utilise XMLRPC.Net de cookcomputing). Ces provider permettent d'ajouter des donnees au header de reponse comme par exemple le Content-Type. Par contre si j'ajoute manuellement Content-length manuellement, il est ecraser par la suite une fois que le provider a rendu la main. 

    Il faudrait que je puisse surcharger une methode juste avant l'envoi et je n'ai pas encore trouve laquelle (HttpWebResponse ou autre).

     

    Merci quand meme de t'etre interesse au probleme.

     

    Cordialement.

    samedi 12 février 2011 10:50
  • Apparemment c'est le "TransportSink" qui fait cela et la doc dit bien qu'il n'est pas modifiable.

    Il est possible que WCF soit plus flexible de ce côté là, le protocole pouvant être changé via les fichiers de config donc je dirais que le "transportsink" ou son équivalent est configurable.

    Sinon je ne vois guère qu'intervenir entre les deux (extensibilité IIS7 ? ou via un "proxy" qui viendrait s'intercaler entre les deux et ferait cette transformation) ?

    A ce stade, je poserais plutôt la question dans un groupe WCF par exemple ce qui augmentera sans doute les chances de croiser un développeur aguerri sur le sujet que dans un groupe généraliste C# (éventuellement poste ici le résultat, je serais curieux de voir comment ce problème a été résolu au final).

    Exemple impressionnant de la façon dont une erreur toute bête peut entrainer d'importantes complications (il aurait même suffit, quitte à le faire sensible à la casse, qu'ils choisissent "Content-Length" qui est sans doute la forme majoritairement utilisée). Désolé de remuer le couteau dans la plaie ;-)

    Bon courage.

    Edit : d'après http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.binding.aspx (1er tableau dans Remarks) il semble effectivement possible d'avoir un transport "custom" (qui pourrait peut-être reprendre http et modifier juste le header) mais cela commence à devenir bien compliqué (plus compliqué que mettre à jour les clients ?)

    Pose la question dans un groupe HTTP et/ou WCF, qq aura peut-être une voie différente et plus simple à proposer ?

     


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".
    samedi 12 février 2011 13:13
    Modérateur
  • Salut Gawa,

     

    As tu trouvé une réponse à ton problème ?

     

    J'utilise moi aussi XMLRPC.Net avec les HTTPChannel et le content-type n'étant pas transmis, impossible d'utiliser le responseXML :(

     

    Merci beaucoup d'avance...

     

    A+

    samedi 26 février 2011 01:08