IIS 10 donnant l'accès 401.3 refusé pour PUT, DELETE ou PATCH pour un chemin spécifique

Question

Je travaille sur une API REST et je fais des tests et des prototypes sur Windows 10 avec son installation IIS native. L'API est écrite en C#. J'ai créé une classe dérivée de IHttpHandler, et j'en dérive pour implémenter des classes pour les noms de mon API. (Cela me permet de mettre en commun la journalisation, la config, l'audit, etc, dans ma classe de nom de base). Pour implémenter les verbes, les classes dérivées remplacent les fonctions de la classe de base pour GET, POST, etc.

Quoi qu'il en soit, l'un des noms que j'ai est pour l'accès au journal de l'application. Le chemin pour cela est/log. J'ai implémenté GET, pour lire le journal, et DELETE, pour effacer le journal. GET fonctionne bien, cependant, DELETE me donne un 401.3 d'IIS. Je reçois également le même 401.3 si j'essaye PUT ou PATCH. PUT et PATCH ne sont pas implémentés dans la classe Logging, ils doivent donc renvoyer un message non implémenté. Je reçois le message non implémenté si j'essaie POST (qui n'est pas implémenté exactement de la même manière que PUT et PATCH ne sont pas implémentés).

Dans le cadre de la tentative d'affiner ce comportement, j'ai vérifié s'il y avait des verbes spécifiques bloqués par le filtrage des demandes (il n'y en avait pas). J'ai vérifié si Process Monitor détectait les refus d'accès au système de fichiers sur le chemin sous-jacent (ce n'était pas ... les choses ne sont jamais allées aussi loin). J'ai ensuite essayé d'ajouter un autre gestionnaire de mapping - exactement le même, mais avec un chemin différent nom:

<gestionnaires>

<add name="BLOBRepoLog" path="log" verb="*" type="BLOBRepoService.Log" resourceType="Unspecified" preCondition="integratedMode" > 

<add name="BLOBRepoLogSanityCheck" path="foo" verb="*" type="BLOBRepoService.Log" resourceType="Unspecified" preCondition="integratedMode" > 

</handlers >

Utilisation Postman, si je l'appelle SUPPR sur/log, je reçois le 401.3. Si j'appelle DELETE sur/foo, cela fonctionne correctement. Si j'appelle PUT sur/log je reçois le 401.3. Si j'appelle PUT sur/foo, j'obtiens le bon message non implémenté. Tout le monde a une idée pourquoi IIS devrait faire un examen minutieux sur les verbes appelés pour le chemin/log?

Merci, Paul

Answer 1

moi avons eu un problème similaire où PUT et DELETE ne fonctionnaient pas, il est avéré pour moi que Webdav était la question. Dans mon cas, je n'en avais pas vraiment besoin, donc je l'ai désinstallé et tout a fonctionné.