WCF sans HTTP.SYS

Question

Lors de l'utilisation d'une liaison HTTP dans WCF, je dois m'accorder des autorisations spéciales pour pouvoir lier ce port/chemin. Je comprends cela parce que WCF accepte le trafic HTTP via le pilote http.sys.

Autrefois, nous pouvions ajouter une nouvelle prise à un ancien port qui n'était pas utilisé, sans être administrateur. NetTcpBinding est toujours capable de le faire.

Si je ne me soucie pas de http.sys, existe-t-il un moyen de dire à WCF de ne pas l'utiliser, et au lieu de simplement ouvrir une ancienne socket régulière tout en utilisant les liaisons HTTP?

Answer 1

Les liaisons HTTP basées sur WCF dépendent de la classe HttpListener qui est gérée par l'API HTTP. L'API HTTP dépend de la façon dont les demandes http du processus du système d'exploitation. Donc, si vous utilisez un système d'exploitation qui utilise le pilote http.sys (Windows 2003 et versions ultérieures), vous en dépendez.

Edit:

Sur la base de très bon argument de Cassini, j'ai passé deux heures dans le réflecteur. La description suivante est seulement ma supposition. Je n'ai trouvé aucune information à ce sujet, alors peut-être que je me trompe complètement.

WCF contient en interne une classe abstraite appelée HttpTransportManager cette classe est dérivée par les classes internes HostedHttpTransportManager et SharedHttpTransportManager (celle-ci existe également en version pour HTTPS). Le premier ne dépend pas de HttpListener mais le dernier est. L'ancien est utilisé lorsque WCF est hébergé dans le pipeline ASP.NET - classes internes HttpModule et HttpHandler à partir de System.ServiceModel.Activation assembly utilisation HostedHttpRequestAsyncResult en fonction de HostedHttpTransportManager. Le dernier est utilisé lorsque HttpChannelListener est créé (auto-hébergement). Ma conclusion est que le service WCF hébergé dans le pipeline ASP.NET n'est pas directement dépendant de http.sys, mais l'IIS hébergeant le pipeline est. Cela permet de créer un serveur web personnalisé qui ne dépendra pas de http.sys mais qui pourra héberger ASP.NET et ainsi WCF. Je pense que c'est ce que fait Cassini. Le service WCF auto-hébergé dépend toujours de http.sys.

Comme je l'ai écrit ci-dessus, c'est seulement mon hypothèse basée sur une ingénierie inverse rapide.