1. Может. Через конфиг она подключается как к service endpoint, так и к client endpoint. Поле 'Settings.IsService' — на самом деле не является настройкой, библиотека сама его вычисляет динамически для собсвтенных нужд. Похоже, более удачным было бы использовать слово 'Parameters'. Вот тут и тут происходит определение режима endpoint'a.
2. Хм, и правда, Content-Type может быть другим, надо переделать.
3. Потоковый режим работы для WCF не является дефолтным режимом. А в самой библиотеке идет оперирование сообщениями целиком, так как она парсит XML с целью извлечения operation name и его форматирования. Но замечение хорошее.
4. Да, логирование с помощью IDispatchMessageInspector (IClientMessageInspector) гораздо тривиальнее. Но на том проекте этот подход был бесполезен — на сервис иногда приходили символы с некорректной кодировкой, десериализация падала, и до Behavior исполнение просто не доходило. Поэтому пришлось спуститься на уровень ниже, чтобы увидеть реальное содержимое некорректного запроса. Фактически MessageInspector не видит самого запроса/ответа, ему дается xml-результат после десериализации + сериализации.
Как автор данной старой статьи добавлю сюда ссылку на библиотеку для логирования SOAP под WCF. https://github.com/capslocky/WcfSoapLogger
Я написал ее для одного из прошлых проектов. Вижу, что сюда все еще идет хороший трафик ) будут вопросы — пишите.
Вообще планы разработчиков Chrome по https marking описаны тут. Там написано, что в следующем релизе Chrome 70, все http сайты будут «красными» при вводе данных, а в будущем они будет «красными» сразу же при открытии страницы.
Хотя Chrome 69 и «убил» зеленый замочек и зеленую строку, факт небольшой визуальной разницы между DV и EV остается. Что все еще позволяет заметить попытку фишинга. Тут уже можно дать рекомендацию запрашивать более длинное значение Subject Organization.
Я бы назвал такие причины:
1. Прежде чем пушать новую порцию коммитов я их всех просмотраиваю, а также смотрю итоговый diff ветки «было-стало», и иногда вношу правки.
2. Каждый пуш — это коннект и передача данных на сервер. Зачем мне делать 10 пушей, если я могу сделать 1 пуш в конце?
3. Собственно я могу вообще не пушать ветку пока она никому не нужна или пока она не смерджена.
4. Если на ветке работает кто-то еще, то не всегда допустимо просто пушнуть новый коммит. Не говоря уже о мердж-конлфиктах.
5. У меня нет интернета (самое банальное).
Я не говорил, что это плохо. Существуют и разные позитивные сценарии использования такой огромной базы закрытого кода. Навскидку:
1. Анализ применения языков программирования и технологий, которые развивает сам Microsoft, с целью их дальнейшего улучшения. C#, TypeScript, F#, .NET Core, Xamarin etc.
2. Совершенствование статических анализаторов кода в VS / VS Code.
3. Улучшение работы VS / VS Code с большими проектами.
4. Анализ экосистемы NuGet пакетов
По умолчанию сертификаты LetsEncrypt имеют рейтинг B на https://www.ssllabs.com/ssltest/, это из соображений совместимости со старыми браузерами. И только специальными настройками можно выключить устаревшие шифры для получения A.
Один из просчетов было отдать 127.0.0.0/8 под loopback. В теории, это может пригодится, чтобы использовать разные IP (127.0.0.2, 127.0.0.3… ) для разных соединений, но на практике достаточно разных портов на 127.0.0.1. Думаю, хватило бы и 127.0.0.0/24 для разных случаев. Может какой-нибудь highload это как-то использует, кто подскажет? Кстати, в IPv6 всего один адрес — ::1.
Оборонка и IT компании еще понятно, но Ford и Daimler было неожиданно. Причем они получили эти блоки еще в середине 90-х. Чем-то похоже на киберсквоттинг.
Еще одна полезная фича — можно явно указать по IP адресам какую часть трафика направлять через VPN — исключая некоторые, или наоборот, только некоторые. Есть и способы автоматически срезолвить домены в IP адреса.
2. Хм, и правда, Content-Type может быть другим, надо переделать.
3. Потоковый режим работы для WCF не является дефолтным режимом. А в самой библиотеке идет оперирование сообщениями целиком, так как она парсит XML с целью извлечения operation name и его форматирования. Но замечение хорошее.
4. Да, логирование с помощью IDispatchMessageInspector (IClientMessageInspector) гораздо тривиальнее. Но на том проекте этот подход был бесполезен — на сервис иногда приходили символы с некорректной кодировкой, десериализация падала, и до Behavior исполнение просто не доходило. Поэтому пришлось спуститься на уровень ниже, чтобы увидеть реальное содержимое некорректного запроса. Фактически MessageInspector не видит самого запроса/ответа, ему дается xml-результат после десериализации + сериализации.
https://github.com/capslocky/WcfSoapLogger
Я написал ее для одного из прошлых проектов. Вижу, что сюда все еще идет хороший трафик ) будут вопросы — пишите.
1. Прежде чем пушать новую порцию коммитов я их всех просмотраиваю, а также смотрю итоговый diff ветки «было-стало», и иногда вношу правки.
2. Каждый пуш — это коннект и передача данных на сервер. Зачем мне делать 10 пушей, если я могу сделать 1 пуш в конце?
3. Собственно я могу вообще не пушать ветку пока она никому не нужна или пока она не смерджена.
4. Если на ветке работает кто-то еще, то не всегда допустимо просто пушнуть новый коммит. Не говоря уже о мердж-конлфиктах.
5. У меня нет интернета (самое банальное).
1. Анализ применения языков программирования и технологий, которые развивает сам Microsoft, с целью их дальнейшего улучшения. C#, TypeScript, F#, .NET Core, Xamarin etc.
2. Совершенствование статических анализаторов кода в VS / VS Code.
3. Улучшение работы VS / VS Code с большими проектами.
4. Анализ экосистемы NuGet пакетов