Тесты GUI в Hudson (Jenkins) в Windows
Я сказал бы, что это не хорошая идея, поскольку существует много брандмауэров, настроенных как фильтр портов, которые намеренно позволяют 80 (http) и 443 (https) другие блока и передача. Или они управляют на основе политик тем, с какими протоколами говорят на других открытых портах. Таким образом, Вы освободите части своей аудитории этот путь.
Другой источник для раздражения - то, что Ваши пользователи должны не забыть вводить правильный номер порта, если они не хотят получать ошибку сертификата. Это: Если https://www.example.com:444/будет корректен, то https://www.example.com:445/инициирует ошибку, если порт 445 использования сертификат для другого сайта.
Я никогда не пробовал это, но я полагаю, что номер порта даже должен быть частью Вашего сертификата.
В зависимости от Вашего варианта использования Вы могли бы быть более обеспечены с Wildcard-сертификатом, который сертифицирует *.example.com, и можно управлять любым количеством субдоменов с тем сертификатом. Если Вы масштабируете горизонтально Вас, может использовать это на стольких же хостов как Вам угодно сколько, пока они достигнуты как https://anysubdomain.example.com/.
Согласно этому потоку, единственный способ сделать так не состоит в том, чтобы выполнить его как услуга, но вместо этого выполнить его как зарегистрированного пользователя с рабочим столом.
Лично, у меня была удача со следующими настройками: 1) запишите пакетный файл для запуска, ведомое устройство через JNLP/javaws 2) помещенный сказал, что сценарий в автоматический запуск 3) установил пользователя для автовхождения в систему. Это было всем в VM, поэтому когда я запустил VM, он автоволшебно зарегистрировал себя как доступный гудзонскому серверу.