Le format de la demande n'est pas reconnu pour les URL se terminant par '/Convert', ce qui se produit après 1-2 jours.

Question

J'appelle un webservice en utilisant un appel Microsoft.XMLHTTP :

var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.open("POST", "/xxx/Converter.asmx/Convert", false);
xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xmlhttp.send("conversionFolder=" + escape(conversionFolder));
if (xmlhttp.status == 200) {
  xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
  xmlDoc.async = "false";
  xmlDoc.loadXML(xmlhttp.responseText);
  ... more stuff ...
  return str;
}
else {
  alert(xmlhttp.statusCode + " - " + xmlhttp.statusText);
}

Tout fonctionne bien lorsque je n'oublie pas d'ajouter le protocole HttpPost dans le web.config local :

<?xml version="1.0"?>
<configuration>
  <appSettings/>
  <connectionStrings/>
  <system.web>
    <webServices>
      <protocols>
        <add name="HttpPost"/>
      </protocols>
    </webServices>
    <compilation debug="false"></compilation>
  </system.web>
  <system.codedom>
  </system.codedom>
  <!--
    The system.webServer section is required for running ASP.NET AJAX under Internet
    Information Services 7.0.  It is not necessary for previous version of IIS.
  -->
  <system.webServer>
  </system.webServer>
</configuration>

Mais sur un serveur de production, il échoue après un ou deux jours de fonctionnement. Il fonctionne bien après que le processus asp.net ait été recyclé. Il fonctionne pendant 1 ou 2 jours, puis il échoue avec ceci :

Exception information:
Exception type: InvalidOperationException
Exception message: Request format is unrecognized for URL unexpectedly ending in '/Convert'.

Request information:
Request URL: https://xxx/xxx/converter.asmx/Convert
Request path: /xxx/converter.asmx/Convert
User host address: 195.50.35.4
User: extranet\kbk
Is authenticated: True
Authentication Type:
Thread account name: NT AUTHORITY\NETWORK SERVICE

Thread information:
Thread ID: 14
Thread account name: NT AUTHORITY\NETWORK SERVICE
Is impersonating: False
Stack trace: at System.Web.Services.Protocols.WebServiceHandlerFactory.CoreGetHandler(Type type, HttpContext context, HttpRequest request, HttpResponse response)
at System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler(HttpContext context, String verb, String url, String filePath)
at System.Web.Script.Services.ScriptHandlerFactory.GetHandler(HttpContext context, String requestType, String url, String pathTranslated)
at System.Web.HttpApplication.MaterializeHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Pourquoi attend-il 2 jours avant d'échouer ? Et que puis-je faire pour l'empêcher d'échouer ? Cela a-t-il un rapport avec le fait que ce serveur fonctionne en mode HTTPS ?

Answer 1

Qu'est-ce que le cadre Dot Net ? IIS 6 ou 7 ?
Avez-vous essayé d'ajouter <add name="HttpGet"/> dans la section des protocoles. Il semble que certaines personnes ont surmonté ce problème avec cette correction. (mais pas pour tous)
lien 1
lien 2
Vérifiez également l'endroit où vous déployez votre site. Se trouve-t-il au niveau de la racine de votre serveur Web ou dans un dossier virtuel ? Parfois, il peut hériter de certaines valeurs de configuration des sites de niveau supérieur ou du fichier machine.config.

Sinon, cela pourrait être lié à une fuite de mémoire dans votre code. Que faites-vous avec le XML chargé ? Je suppose également que vous analysez un XML valide.

Answer 2

Il semble qu'un correctif soit disponible lorsque le recyclage du pool d'applications corrige le problème pendant quelques jours : http://support.microsoft.com/kb/2783777/en-us

Answer 3

Il semble que le les protocoles sont désactivés par défaut . Une question similaire a déjà trouvé une réponse sur Stackoverflow. Vérifiez ceci lien et les question