Discussion :

[luxior]

Bonjour,

je cherche un moyen de changer l'artribut 'content-length' dans le header du flux envoyer par le web service.

information technique:
- Miscrosoft 2000 et IIS
- Visual Web Developer 2005 Express
- FrameWork 2

explication:
J'ai un echec lors d'un appel a un service. L'entreprise partenaire m'informe que ma requette échoue car le 'content-length' de mon envoie ne correspond pas (Corrigé manuellement et rejouée, ma requette fonctionne).

merci

[Cédric B.]

Salut luxior,

tu peux essayer de construire un flux manuellement avec les objets webrequest et webresponse. Avec cela, tu peux changer ton header comme tu désire!

J'espère que ceci pussie t'aider!

Cédric

[luxior]

J'ai penser a une éventualité dans ce genre, mais je devrais apres forcer le client a l'utiliser, ce que je n'ai pas encore trouvé.

J'ai trouver une bibliotheque forte interessante :
System.ServiceModel.Web
mais elle ne fonctionne pas sous serveur 2000 et demande une FrameWork 3.5 minimum. Meme si cela me demande une migration importante de mes applicatifs je concerve cette solution.

Dans des solutions plus resonnable je travaille:
- System.Net
- System.Web.Services
mais vu l'existance de System.ServiceModel.Web et sa fonction, j'ai peur qu'il n'y a pas de solution avant FrameWork 3.5

merci pour ta reponse

[cinemania]

en même temps à part dans le secteur bancaire je vois mal l'intérêt de conserver windows 2000 server...
surtout que la maintenance est arrêtée et était payante les dernières années.
à ce compte là, migrer vers un environnement de type Windows Server 2008 constitue un coût et un risque moindre, finalement.

[luxior]

le serveur 2003 est en place pour la production. Un serveur interne 2008 viens d'etre mis en place et pourra acceuillir la recette.
Le probleme, est qu'une simulation montre que le passage en FrameWork 3.5 ou 4 (tant qu'a faire) demande de nombreuse modification (=temps). Sans compter les autres problemes liés ou non à ce projet.
L'échance d'une version pour le premier septembre, ne permet pas d'effectuer la migration materiel et logicielle maintenant.
C'est pour cela que je dis que: "je concerve cette solution", mais que j'en cherche une de "papy" pour parer au plus pressé.

PS: tout les services informatiques ne sont pas constitué d'une armée de codeurS avec du matériel/logiciel renouvellé tout les 6 mois . (j'ai entendu dire que les banques maintenaient en vie des applicatifs en Cobol , comme quoi meme une armée ne change parfois pas grand chose)

parenthese fermée peut-on revenir au sujet SVP

[cinemania]

luxior oui les banques oui, d'où ma remarque sur le cycle de vie... et le fait qu'à part en service bancaire...

je ne vois pas en quoi le passage de dotnet 2 à 3.5 peut bien être compliqué... pour une application dotnet cela ne change pas grand chose, et sur la machine juste à installer le nouveau package (sans même désinstaller l'ancien... dingue non ?)
la preuve je viens de changer le Framework base installé sur la machine serveur frontale de prod de la boite et j'ai même pas eu besoin d'interrompre l'activité, c'est pour dire.
je te déconseille toutefois le passage à dotnet 4 si tu as des consignes et des contraintes d'obsolescence fortes, et lui effectivement peut poser des problèmes car contrairement à dotnet 3.5 il ne s'agit pas d'une collection de bibliothèques à ajouter sur le framework, garantissant que toute la chaine de production continue à fonctionner, même pendant l'installation. en effet dotnet 4 constitue un changement structurel important de la plateforme, car la CLR est modifiée, et nécessite donc une installation complète qui nécessite l'arrêt de tout processus utilisant dotnet.

c'est ta requête au webservice qui pose problème, ou au contraire tu expose le webservice et c'est lui qui a un souci de content-length en réponse ?

[luxior]

Précisement:
j'utilise un web service:
1) dans le web.config:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
<configuration>
  <appSettings>
	<add key="fr.RechercheGTAService" value="http://adresseSocieteExterieur.fr/d8mjws/servlet/services/leService"/>
  </appSettings>
...
	<system.web>
		<compilation debug="true">
			<assemblies>
				<add assembly="System.Web.Services, Version=2.0.0.0, Culture=neutral, 
 
PublicKeyToken=B03F5F7F11D50A3A"/>
...
			</assemblies>
		</compilation>
...
	</system.web>
<configuration>

la partie WebService du web.config se limite la.

2) Dans le projet:
les WebService sont definit par les fichiers:
- leService.discomap
- leService.wsdl
- leService.xsd

- leService.discomap, introduit les deux autres et est propre a Window:

Code :

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

1
2
3
4
5
6
7
8
<Results>
    <DiscoveryClientResult referenceType="System.Web.Services.Discovery.ContractReference" 
 
url="http://adresseSocieteExterieur.fr/d8mjws/servlet/services/leService?wsdl" filename="leService.wsdl" />
    <DiscoveryClientResult referenceType="System.Web.Services.Discovery.SchemaReference" 
 
url="http://adresseSocieteExterieur.fr/d8mjws/servlet/services/leService?xsd=Types.xsd" filename="leService.xsd" />
  </Results>

les 2 derniers sont recuperés aupres du serveur (partenaire)

3)- j'importe un package
-je declare et instencie les classes du WebService
-et utilise les methodes d'apelle de service

-> en gros la base du WebService

Tout marche tres bien depuis des mois...

il y a quelques jours l'entreprise partenaire a fait des modifications de son cotés, désolé mais j'ai pas les details...
Mes apels ne passent presque plus, les appel contenant peu d'information passent, mais ceux contenant un complement d'information ne passent plus...

Apres quelque tests, mes partenaires me signalent:

en rejouant votre flux, il repasse. Néanmoins, en y ajoutant les headers presents, j'ai bien la même erreur que vous : le pb vient de ce que vous envoyez dans les header au niveau de la donnée content-length :
Headers: {content-type=[text/xml; charset=utf-8]..., content-length=[4146], x-forwarded-host=...

une longueur de flux max est envoyée, ce qui fait que votre flux est coupé par notre serveur.
Il faut donc que vous modifiez cette donnée (ou la supprimiez).

Personnellement je comprend pas trop pourquoi le content-length serait faux sauf si 4146 est un maximum fixé en dur a l'époque de la FrameWork 2, d'où mon essai en FrameWork 4 du a l'arrivé de nouveau matériel. Donc si j'ai bien compris la FrameWork 3.5 est juste un ajout de bibliotheque et ne demande aucune modification dans le source existant. Je ferais une simulation.

Une autre solution est de fabriquer un client, je pense que c'est ce que sous entend Cédric B. M'enfin euh, ca fait peu etre beaucoup la , ma question ne doit pas etre bien posée il a du pensé que j'avais crée moi meme un Web Service.

la troisieme solution: trouvé le moyen d'implementer en partie le service client de FrameWork:
implementer en surchargement l'existant et en en forcant l'usage
cela me raprocherai de la solution de Cédric B.

finalement l'idéal serait le parametrage dynamique du service client de FrameWork.

Une solution temporaire me permet de réduire les informations de mon appel, ce que je met actuellement en place. Mais cette solution ne peut etre que provisoire.

Voila pour repondre a ta question cinemania je dirais:
j'" expose le webservice et c'est lui qui a un souci de content-length en" request et non (réponse)