Изменения в настройках сервера репозитория NPM привели к неработоспособности (https://github.com/npm/npm/issues/20791) сервиса. Проблему усложняло то, что столкнувшиеся с проблемой пользователи были введены в заблуждение странным кодом и сообщением об ошибке "ERR! 418 I'm a teapot", который возвращался в ответ на попытки обновления или установки пакета. При этом страница status.npmjs.org (https://status.npmjs.org/) показывала, что все подсистемы отвечают и работают в штатном режиме, а откат на прошлую версию NPM на стороне клиента не решал проблемы.
Разбор ситуации показал, что проблема затрагивает только пользователей, использующих прокси, как правило работающих из корпоративных сетей или с использованием виртуальных машин. Спустя семь часов проблема была исправлена. Далее выяснилось (https://github.com/npm/npm/issues/20791#issuecomment-392627314), что запросы с использованием HTTPS, отправленные через прокси, приходят с указанием номера порта в заголовке Host (registry.npmjs.org:443), в то время как разработчики NPM рассчитывают увидеть только registry.npmjs.org. Странный код ошибки 418 возвращался для проблем неопределённого характера и был составлен по мотивам шутки, опубликованной 1 апреля в RFC 2324 (https://tools.ietf.org/html/rfc2324).
URL: https://news.ycombinator.com/item?id=17175960
Новость: https://www.opennet.me/opennews/art.shtml?num=48681
>>>NPM
>>ERR! 418 I'm a teapot
>странным кодом и сообщениемНичего странного. Всё нормально. Что не так?
В nginx обычно 418 использую для перехвата вариантов из if через return и error_page, удобно.
В nginx не рекомендуется использовать if: https://www.nginx.com/resources/wiki/start/topics/depth/ifis.../
Вместо этого лучше использовать map: https://habr.com/post/231277/
NPM та ещё шарага, жаль nodejs foundation им доверились когда-то.
NPM та ещё шарага, жаль nodejs foundation им доверились когда-то.
Они друг друга стоят..
Г-н Эскобар глупость не скажет (18+) https://www.youtube.com/watch?v=giC3-LnnV4c
Прямо неделя замшелых баянов на ОН.
А есть тут эксперты по этой хрени? Как, например, организовать свой репозиторий из ПУБЛИЧНЫХ пакетов? Это нужно для закрытого сегмента сети.
Nexus
Ох ты ж ё...Дя прям таки бесценный совет! А купить jfrog artifactory не посоветуешь? Я не спрашивал какой менеджер мне взять, я спросил как это всё реализовать, например, через тот же nexus. Меня интересует реализация.
https://blog.theodo.fr/2016/01/speed-up-npm-install-with-a-n.../
на слуху у меня был только этот https://www.npmjs.com/package/sinopia
> запросы с использованием HTTPS, отправленные через проксиэто что ещё за такой прокси -- для HTTPS ?
А что не так?
Вероятно, имеется ввиду reverse-proxy, напр. nginx. И да, как админ на аутсорсе часто вижу неправильно приготовленный nginx шлющий всякое в заголовках.
Прозрачный. А что не так? Системный и файрфоксовый прокси всегда работал и для https, без mitm, естественно. Включая всякие расширения, от foxyproxy с возложением поиска прокси на тебя, до фригатов и прочих зондо-проксей со встроенными.
Без mitm нельзя заголовки поменять, так что либо непрозрачный прокси и клиент шлет разные заголовки в зависимости от настроек, либо mitm
какой нахрн *прозрачный* прокси для https?что за чушь вы тут несёте?
кто напустил на форум админов?
Нашёлся я смотрю главный админ всея опеннета http://bfy.tw/IMnB
> Нашёлся я смотрю главный админ всея опеннета http://bfy.tw/IMnBа дальше-то куда нажимать?
ато по твоей ссылке выпадает список сайтов щёлкнув на парочку из которых -- предложили *убить* клиентскую систему (что кстати является весьма *НЕ_прозрачным), скомпрометировав там список TLS-сертификатов.. и нужно быть полным идиотом-пользователем чтобы сделать такое у себя на компе (даже пусть на рабочем.. хотя НЕ! на рабочем этого ВООБЩЕ делать нельзя, ибо там ответственности больше).
может что-то более конкретное предложишь? ато вдруг я тыкнул не на ту ссылку?
# P.S.: и не забуть написать пару слов про "Public Key Pinning" (HPKP) и про "Certificate Transparency" (CT)
> # P.S.: и не забуть написать пару слов про "Public Key Pinning"
> (HPKP)Так оно же сдохло: https://www.leaderssl.ru/news/452-google-planiruyut-udalit-p...
Есть https прокси с недавних пор. Пару лет хромиум умеет. Вот curl недавно научился, а больше никто из софта.
Что конкретно тут значит "хромиум умеет"? Подключиться к проксе и сказать ей "CONNECT куда-нибудь:443" и дальше пускать шифрованный поток как бы все браузеры и клиенты всегда умели...
ну 1 ссылка же, нуhttps://daniel.haxx.se/blog/2016/11/26/https-proxy-with-curl/
Эм. Вы это серьезно?? Причем тут вообще https-сессия *до* прокси, когда мы обсуждаем проксирование https-соединения до сервера? То, что до прокси https вообще ни на что тут не влияет, прокся ровно так же не может вмешиваться в соединение (и не сможет поставить заголовок Host, как в примере выше). Там ровно такой же CONNECT и дальше шифрованный трафик, про который прокся ничего не знает.