Надо еще и начальство иметь вменяемое. А то "хорошего" петуха возьмут и уволят за ненадобностью. Действительно, зачем он нужен, команда всё делает и без него.
Кому, интересно, вообще может понадобиться подключаться по HTTP/2 к localhost?
В спецификации HTTP/2 чрезвычайно мутно освящен вопрос об использовании HTTP/2 без TLS. Поскольку с TLS-сертификатом для localhost дела обстоят очень не очень, т.е., нормальная проверка сертификата невозможна (а можно лишь выписать self-signed сертификат и как-то особым образом его проверять) я бы сказал, что HTTP/2 на localhost-е может применяться только в каких-то очень особых случаях, когда обе стороны, и клиент и сервер, знают и учитывают эти особенности.
С другой стороны, для localhost в большинстве практически значимых случаев достаточно HTTP/1.1
Похоже, MS решили навести в этом бардаке некоторый порядок, ну и нарвались.
На месте Микрософта, я бы вообще запретил HTTP/2 для адресов 127.0.0.1 и ::1 и соответствующих доменных имен.
Я бы тут хотел не спорить о терминах, а разделить выделение/освобождение ресурса (в данном случае, сокета) и управление состоянием этого ресурса.
Некоторую путаницу в POSIX вносит то, что выделенный но не присоединенный сокет - штука довольно бесполезная, а close объединяет семантику закрытия соединения и освобождения дескриптора.
В этом смысле Go и Plan9 более последовательны, net.Dial и dial основременно создают объект и устанавливают соединение (но усложняют настройку сокета, которую хотелось бы сделать до попытки установления соединения).
Там очень много технических подробностей, но суть примерно такая.
Среде исполнения Go время от времени надо за какой-нибудь надобностью пробежаться по стекам гороутин. Например, такая потребность возникает при обработке panic. Сборщик мусора тоже так делает, чтобы поискать на стеке валидные указатели и не освободить случайно объекты, на которые они указывают.
Код, который пробегается по стеку, рассчитывает на то, что в указателе стека всегда лежит корректное значение.
При входе в функцию стек растёт, при выходе уменьшается. И делается это, естественно, командами процессора.
Особенностью архитектуры ARM64 является то, что при определенных условиях эти манипуляции со стеком раскладывались компилятором на две команды. И в тот очень короткий промежуток времени, когда первая из этих команд уже выполнилась, а вторая - еще нет, указатель стека был очень ненадолго невалидным.
Если именно в этот момент среде исполнения понадобится размотать стек именно этой гороутины, то случится беда и всё сломается.
Поскольку опасное состояние длится очень недолго, попасть именно на этот момент сложно, и проблема возникает редко. Однако при определенных патернах загрузки она всё же воспроизводится.
Вот, ребята докопались до причины и даже написали простенький тест, который устойчиво воспроизводил проблему, а разработчики компилятора починили компилятор.
Если вы создали сокет, попытались его открыть и отвалились по таймауту - не переиспользуйте его! Для новой попытки обязательно создавайте новый сокет!
Я дико извиняюсь, но создание сокета (вызовом socket) - это и есть его открытие. Что открыли, то надо закрыть.
А connect - это не открытие сокета, а установление соединения - действие, которое пытается изменить состояние сокета, но не открывает и не закрывает его.
Именно здесь семантический переход от «вакансии» к «позиции» перестает быть лингвистическим нюансом и становится механизмом психологической компенсации. Там, где исчезает объективная социальная ценность труда, язык предлагает суррогат значимости через переопределение базовых понятий.
Во-во. Механизмом психологической компенсации.
По сути, ничего не изменилось. Нанятый работник как был винтиком в механизме, так им и остался. И отчуждение результатов труда никуда не делось.
Только теперь работникам льют психологическую лапшу на уши. Ты, типа, не просто таски закрываешь в джире, а командный игрок, личность в процессе самореализации. Гордись тем, что тебя взяли в такую крутую команду, в которую берут не только лишь всех и что ты не просто делаешь костыли в выкаченном из интернета говнокоде, а определяешь светлое технологическое будущее компании.
Да еще и научились вместо денег давать "социальный пакет". Зарплату мы тебе не подымем, но зато ДМС, фитнес и раз в год от компании - фирменная маечка (и фирменная кружка в день первого выхода на работу, чтобы было в чём заваривать чай из дешевого пакетика, когда на нормальный обед сбегать некогда).
Придумали, конечно. ABNF, например, и всякое такое.
Вопрос, почему пользователи предпочитают неудобоваримые регулярки вместо более понятных инструментов.
Регулярки хороши, чтобы разбивать текст на лексемы, и классический парсер, он двухуровневый: лексемы выделяются регулярными выражениями, потом делается уже синтаксический анализ по грамматике, описанной каким-нибудь вариантом BNF (Backus–Naur form)
В RFC5822, на который вы ссылаетесь, address определён со всеми этими наворотами, а то, что имеете ввиду вы, это кусок адреса, addr-spec.
Более того, RFC6068, определяющий схему mailto, специально оговаривает, что address, это как в RFC5822, со следующими оговорками: (...), фактически сводя address к addr-spec.
addr-spec, наверное да, регулярен. Но со всеми интернационализационными наворотами это не точно.
Я не смог придумать, как сделать парсер, который обходится без backtracking. Когда парсер только прочёл слово Vasya, он не может знать, какой из двух вариантов используется.
Регулярки, которые умеют в обратные ссылки (backreference) не являются регулярными грамматиками по Хомскому и не могут быть преобразованы в регулярный ДКА. Наверное, есть граждане, которым обратные ссылки действительно нужны...
С другой стороны, синтаксис e-mail адреса (per RFC 822) не описывается регулярной грамматикой...
P.S. У Go реализация регулярных выражений из стандартной библиотеки гарантирует, что время сопоставления растёт, как O(n), где n - размер входного текста.
Которое не работает по HTTP/1.1?
И как, вернулся?
Надо еще и начальство иметь вменяемое. А то "хорошего" петуха возьмут и уволят за ненадобностью. Действительно, зачем он нужен, команда всё делает и без него.
Понятно. Я не знал.
Причём очень вероятно в данном случае, что "сломали" == "привели к требованиям, изложенным в RFC"
Кому, интересно, вообще может понадобиться подключаться по HTTP/2 к localhost?
В спецификации HTTP/2 чрезвычайно мутно освящен вопрос об использовании HTTP/2 без TLS. Поскольку с TLS-сертификатом для localhost дела обстоят очень не очень, т.е., нормальная проверка сертификата невозможна (а можно лишь выписать self-signed сертификат и как-то особым образом его проверять) я бы сказал, что HTTP/2 на localhost-е может применяться только в каких-то очень особых случаях, когда обе стороны, и клиент и сервер, знают и учитывают эти особенности.
С другой стороны, для localhost в большинстве практически значимых случаев достаточно HTTP/1.1
Похоже, MS решили навести в этом бардаке некоторый порядок, ну и нарвались.
На месте Микрософта, я бы вообще запретил HTTP/2 для адресов
127.0.0.1и::1и соответствующих доменных имен.А как надо переводить? "Легковесный поток исполнения запустил процедуру обработки критической ошибки"?
Я бы тут хотел не спорить о терминах, а разделить выделение/освобождение ресурса (в данном случае, сокета) и управление состоянием этого ресурса.
Некоторую путаницу в POSIX вносит то, что выделенный но не присоединенный сокет - штука довольно бесполезная, а close объединяет семантику закрытия соединения и освобождения дескриптора.
В этом смысле Go и Plan9 более последовательны, net.Dial и dial основременно создают объект и устанавливают соединение (но усложняют настройку сокета, которую хотелось бы сделать до попытки установления соединения).
Там очень много технических подробностей, но суть примерно такая.
Среде исполнения Go время от времени надо за какой-нибудь надобностью пробежаться по стекам гороутин. Например, такая потребность возникает при обработке panic. Сборщик мусора тоже так делает, чтобы поискать на стеке валидные указатели и не освободить случайно объекты, на которые они указывают.
Код, который пробегается по стеку, рассчитывает на то, что в указателе стека всегда лежит корректное значение.
При входе в функцию стек растёт, при выходе уменьшается. И делается это, естественно, командами процессора.
Особенностью архитектуры ARM64 является то, что при определенных условиях эти манипуляции со стеком раскладывались компилятором на две команды. И в тот очень короткий промежуток времени, когда первая из этих команд уже выполнилась, а вторая - еще нет, указатель стека был очень ненадолго невалидным.
Если именно в этот момент среде исполнения понадобится размотать стек именно этой гороутины, то случится беда и всё сломается.
Поскольку опасное состояние длится очень недолго, попасть именно на этот момент сложно, и проблема возникает редко. Однако при определенных патернах загрузки она всё же воспроизводится.
Вот, ребята докопались до причины и даже написали простенький тест, который устойчиво воспроизводил проблему, а разработчики компилятора починили компилятор.
А что, в среде исполнения Питона каким-то волшебным образом нет ошибок? :)
Я дико извиняюсь, но создание сокета (вызовом socket) - это и есть его открытие. Что открыли, то надо закрыть.
А connect - это не открытие сокета, а установление соединения - действие, которое пытается изменить состояние сокета, но не открывает и не закрывает его.
Во-во. Механизмом психологической компенсации.
По сути, ничего не изменилось. Нанятый работник как был винтиком в механизме, так им и остался. И отчуждение результатов труда никуда не делось.
Только теперь работникам льют психологическую лапшу на уши. Ты, типа, не просто таски закрываешь в джире, а командный игрок, личность в процессе самореализации. Гордись тем, что тебя взяли в такую крутую команду, в которую берут не только лишь всех и что ты не просто делаешь костыли в выкаченном из интернета говнокоде, а определяешь светлое технологическое будущее компании.
Да еще и научились вместо денег давать "социальный пакет". Зарплату мы тебе не подымем, но зато ДМС, фитнес и раз в год от компании - фирменная маечка (и фирменная кружка в день первого выхода на работу, чтобы было в чём заваривать чай из дешевого пакетика, когда на нормальный обед сбегать некогда).
Придумали, конечно. ABNF, например, и всякое такое.
Вопрос, почему пользователи предпочитают неудобоваримые регулярки вместо более понятных инструментов.
Регулярки хороши, чтобы разбивать текст на лексемы, и классический парсер, он двухуровневый: лексемы выделяются регулярными выражениями, потом делается уже синтаксический анализ по грамматике, описанной каким-нибудь вариантом BNF (Backus–Naur form)
Можно упростить. Там в целом довольно понятная алгоритмика, хоть аккуратно её реализовать - муторно, аж жуть :)
В RFC5822, на который вы ссылаетесь,
addressопределён со всеми этими наворотами, а то, что имеете ввиду вы, это кусок адреса,addr-spec.Более того, RFC6068, определяющий схему
mailto, специально оговаривает, чтоaddress, это как в RFC5822, со следующими оговорками: (...), фактически сводяaddressкaddr-spec.addr-spec, наверное да, регулярен. Но со всеми интернационализационными наворотами это не точно.Примеры валидных адресов:
есть варианты и позаковыристее. Не надо думать, что e-mail address, это только user@example.com
Более того, есть две формы адреса:
Я не смог придумать, как сделать парсер, который обходится без backtracking. Когда парсер только прочёл слово Vasya, он не может знать, какой из двух вариантов используется.
Регулярки, которые умеют в обратные ссылки (backreference) не являются регулярными грамматиками по Хомскому и не могут быть преобразованы в регулярный ДКА. Наверное, есть граждане, которым обратные ссылки действительно нужны...
С другой стороны, синтаксис e-mail адреса (per RFC 822) не описывается регулярной грамматикой...
Я просто оставлю это здесь:
Russ Cox. Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, ...)
P.S. У Go реализация регулярных выражений из стандартной библиотеки гарантирует, что время сопоставления растёт, как O(n), где n - размер входного текста.
Что такое КИС?