Pull to refresh

Comments 16

И вроде бы интересно, но при чем тут k8s? Он не сыграл вообще никакой роли. Или я не прав?
Спасибо за замечание. По существу — он разве что «усложнил» цепочку трафика для troubleshooting'а, о чём сказано в тексте. Из хаба Kubernetes статью убрали.

P.S. А в заголовке K8s по той причине, что хотим сделать такой цикл из материалов, объединённых тем, что все они будут из практики эксплуатации приложений в Kubernetes, однако с самим K8s напрямую могут быть не связаны. Их суть в первую очередь о «просто интересном опыте» и более «системных» выводах из него (что вообще случается в нашей практике, как подходить к вопросам troubleshooting'а и т.п.).
Казалось бы, на дворе 2019. А про Юникод то тут, то там вообще не слышали. Сам недавно столкнулся с тем, что в Windows 10 клиент NFS не умеет Юникод, только ASCII. Пришлось ради одной машины с Виндой поднимать зеркало на отдельной машине, где уже можно было бы запустить Самбу.

Больше поражают ответы разработчиков Kestrel в issues на эту тему, лаконично — "Нет!" :-)

Программа реализует стандарт, причём реализует правильно, отвергая какашки там, где должен быть ASCII.
А при чём тут unicode?

В стандарте (на него ссылается стандарт HTTP/1.1) написано:
Each header field can be viewed as a single, logical line of
ASCII characters, comprising a field-name and a field-body.
For convenience, the field-body portion of this conceptual
entity can be split into a multiple-line representation; this
is called «folding». The general rule is that wherever there
may be linear-white-space (NOT simply LWSP-chars), a CRLF
immediately followed by AT LEAST one LWSP-char may instead be
inserted.

tools.ietf.org/html/rfc822#section-3.1

А вот люди, которые решили, что могут писать улыбающиеся какашки с кодом гендера и цвета кожи всюду — немного погорячились.

Kestrel делает всё правильно, товарищи, дописывающие unicode — нарушают RFC. Хотят юникод? base64 их друг.

Тут даже скорее проблема с конца GeoIP.

UFO just landed and posted this here

Будь это год назад, я бы согласился. Но проблемы становились меньше или уходили с каждой новой версией acs-engine/aks-engine и свежими версиями Kubernetes, поэтому сейчас всё вполне живёт. Есть дискомфорт у инженеров, есть много разных проблем, но в целом — можно жить :-) Мы научились его готовить. Ну и клиент изначально зашёл к нам уже с Azure.

Насчёт ажура — полностью соглашусь. Причем такие же отзывы слышал от коллег

очень громко и без каких либо фактов, не стоит выставлять себя со стороны «мне не зашло, потому что я не разобрался и не справился»

Ну, засовывать такие вещи в ingress — странно. Вообще, бизнес-логика в ингресс (всякие реврайты и ко) — опасная вещь.
В случае этого клиента — почему гео-айпи нельзя было реализовать уже на оконечном контейнере? Ведь "настоящий" ip клиента туда доезжает? И никаких "странных" проблем тогда бы и не получили.

Простите, я не понимаю, почему GeoIP в nginx становится бизнес-логикой? Какая разница, какой nginx будет отправлять хидеры с символами utf-8 с city в Kestrel, который их в итоге и не поймет?

Я задал вполне конкретный вопрос, а Вы вопросом на вопрос — как-то не очень хорошо получается.


Какая разница, какой nginx будет отправлять хидеры с символами utf-8 с city в Kestrel, который их в итоге и не поймет?

в стоимости отладки, например? Я просто обожаю кейсы с овер-инжинирингом (сам грешен — чего скрывать) и георическими попытами его потом пофиксить.


почему GeoIP в nginx становится бизнес-логикой?

А зачем он в Ingress — можете объяснить? Какая разница в каком месте трейса запроса появляется GeoIP данные?

Извините, не хотел вас оскорбить ни в коей мере своим вопросом. :-) В этом ингрессе GeoIP просто есть. Можно назвать это стандартным решением, для многих кейсов. Кроме того, заголовки могут улетать не только в одно приложение за этим ингрессом.

Простите, я не понимаю, почему GeoIP в nginx становится бизнес-логикой? Какая разница, какой nginx будет отправлять хидеры с символами utf-8 с city в Kestrel, который их в итоге и не поймет?

Sign up to leave a comment.