Используйте порт 443 для самостоятельной службы wcf и IIS одновременно

У меня есть собственная WCF-служба и веб-сайт ASP .Net, которые нужно запускать на одной машине. Я обнаружил, что при запуске самообслуживаемой службы все вызовы на порт 443, предназначенные для IIS (на основе IP и заголовков хостов/SSL-привязок), маршрутизируются в архитектуру WCF, поэтому веб-сайт перестает работать до тех пор, пока сам хостинг. Это эффективно предотвращает способность IIS выполнять свою работу.

Обратите внимание, что IIS по-прежнему отлично работает на других портах, например, на порту 80. Он просто перегружен на порту 443. Не совсем уверен, что это проблема сервера или проблема с кодом/wcf.

4
nl ja de
Http, соединение webHttpBinding и basicHttpBinding.
добавлено автор Grant H., источник
У меня две проблемы. Во-первых, будут ли все клиентские машины иметь доступ к портам, отличным от 80 и 443. Во-вторых, эти службы WCF уже активны на другом сервере, поэтому я пытаюсь выполнить миграцию без обновления клиентских компьютеров.
добавлено автор Grant H., источник
Какой тип привязки вы делаете? HTTP или net.tcp?
добавлено автор Sam, источник
Есть ли причина, по которой вам нужно использовать 443 для вашего порта wcf? Можете ли вы использовать порт, который не используется? например 8081
добавлено автор Sam, источник

2 ответы

После довольно много исследований я смог определить, что одна из конечных точек службы, конечная точка REST, предназначенная для имитации файла crossdomain.xml, была предупреждением IIS. В противном случае все работало так, как ожидалось. Я удалил эту конечную точку и использовал IIS для работы с файлом.

2
добавлено

Похоже, что, как вы подозреваете, самообслуживаемая служба перехватывает вызовы на порт 443, прежде чем IIS сможет их забрать. Быстрая проверка журналов IIS должна подтвердить, что это происходит.

Имейте в виду, что хотя вы можете запускать несколько доменов на порту 80, если я правильно помню, вы можете использовать его только на порту 443, поэтому такие вещи, как заголовки хостов, не работают с HTTPS-соединениями. Это также может способствовать вашей проблеме.

Есть ли способ, которым вы могли бы разместить самообслуживаемую службу через IIS? Это может решить эту проблему и снизить административную нагрузку в будущем.

Редактировать следующие комментарии: Если вы не можете размещать в IIS, тогда, полагая, что я прав, что служба WCF перехватывает запросы на IIS, и это то, что мешает прохождению трафика, тогда вам может потребоваться либо добавить что-то в ваше приложение WCF, либо создать (или найти существующий пример) независимого прокси-сервера для входящего трафика на основе HttpListener и использовать его для определения запросов на обслуживание и соответствующим образом реле. Конечно, этот тип прокси-сервиса также можно использовать для маскировки расширений, чтобы вы могли использовать его для ретрансляции внешнего URL-адреса любого формата на соответствующий внутренний URL-адрес службы. Важно то, что прокси-сервер сидит впереди как WCF, так и IIS в сетевом стеке, поэтому он может перехватывать запросы до того, как их подхватит. Если вы пишете свой собственный, то HttpListener , вероятно, будет хорошей отправной точкой.

1
добавлено
Хостинг в IIS не совсем исключен, но я использую конечные точки URL без расширения в моей службе, например./LSClient. Если я использовал IIS, мне пришлось бы использовать /LSClient.svc, что заставило бы меня обновлять код клиента, чтобы отразить новые привязки. Это нетривиально, поскольку я не контролирую клиентов.
добавлено автор Grant H., источник
Кроме того, ограничение порта 443 - это одно приложение на комбинацию ip/port, я полагаю. Даже это можно получить, вручную обновив конфигурацию IIS, чтобы проанализировать заголовки хоста.
добавлено автор Grant H., источник
@Rajesh, да, но для этого потребуются новые привязки, что означает обновление клиента.
добавлено автор Grant H., источник
@GrantH: Если вы используете webapi, тогда у вас не будет зависимости от файла .svc и вы можете получить URL-адреса без расширения
добавлено автор Rajesh, источник
Microsoft Stack Jobs
Microsoft Stack Jobs
1 788 участник(ов)

Work & freelance only Microsoft Stack. Feed https://t.me/Microsoftstackjobsfeed Чат про F#: @Fsharp_chat Чат про C#: @CSharpChat Чат про Xamarin: @xamarin_russia Чат общения:@dotnettalks

Microsoft Developer Community Chat
Microsoft Developer Community Chat
584 участник(ов)

Чат для разработчиков и системных администраторов Microsoft Developer Community. __________ Новостной канал: @msdevru __________ Баним за: оскорбления, мат, рекламу, флуд, флейм, спам, NSFW контент, а также большое количество оффтоп тем. @banofbot