Не думаю что там что-то сильно можно сломать. Таблицы изначально сделаны так, чтобы можно было дать свободу браузеру в мелочах и сообщить ему в коде только некоторые условия, по которым (с учётом всяческих посторонних факторов) он сам уже рассчитает всю геометрию попиксельно.
Но если всё же есть опасение что включение max-width может сломать существующие сайты — ну так ввели бы max-column-width какое-нить, которое действовало бы специально для таблиц. На тех сайтах что про него не в курсе его точно нет и следовательно ничего не сломается.
Хм, и правда. Но эта проблема — не повод выкидывать таблицы и придумывать им замену. Можно было просто сделать чтобы max-width работало, или добавить ещё какое-то свойство для этой цели специально для таблиц.
Тут видно по сути два аргумента:
1) То что div-css позволяет, в отличие от таблиц, ставить элементы в коде и выводить на экран в несовпадающих порядках. Ну, можно зачесть это за плюс, но плюс сомнительный. Когда зачем-то нужно посмотреть исходный код страницы, а там вместо ожидаемого порядка (слева направо, сверху вниз) всё расположено не пойми как — возникают только негативные эмоции.
2) В таблицах сложно сделать скруглённые углы и подобное. Ну, возможно. Хотя если использовать таблицы + css (css — не для вёрстки а для уточнения оформления) то наверно несложно.
Казалось бы, таблицы поддерживаются всеми браузерами уже около 20 лет. Но нет, сначала адепты div-css вёрстки придумали себе альтернативный способ, мучились мучились с ним годами и наконец "придумали" в своём мире таблицы. Но зато всё это время они оставались модными и современными.
Да, может быть и клиент. Но (может я конечно не так понял?) в вашем случае нет множества данных которые неизвестно когда закончатся, а есть короткий запрос.
Зачем вот слать вот такое:
Отдельно хочу заметить, что проблема не возникла, если бы Highwinds использовали любую Open Source реализацию HTTP сервера, например Varnish или Nginx, а не писали свою
Как раз написали свою, оптимизированную под работу в режиме CDN (а не http-сервера общего назначения, где может быть обоснованно нужен первый вариант), для сокращения расходов на эксплуатацию, и смогли предложить вам дешевые услуги. По-моему это с их стороны правильное действие.
Поддержу Highwinds в данном споре. Chunked encoding совсем не для того, как вы его используете — он для случаев, когда на стороне источника потока данных есть какая-то относительно сложная логика, данных много и заранее неизвестно, когда они закончатся. Тело запроса к cdn — определённо не тот случай.
Вы поняли суть, правда не совсем точно её выразили. В плане "игры в прятки с роскомнадзорами и прочими ведомствами" действительно ничего делать не надо. Не согласны с политикой — меняйте политику, политическими методами.
Не видел их комментариев на этот счёт, но скорее всего там будет что-то о том, что DV-сертификаты это только начальный уровень, а для хорошей проверки надо EV.
Ну и вон выше про certificate pinning писали.
Ну вообще подсветка синтаксиса эти проблемы сразу убирает. Хотя можно предположить ситуацию, когда при мердже двух независимых коммитов в какую-нить vcs получится такая ситуация и подсветку там уже никто не посмотрит.
Сам стараюсь использовать наоборот // чтобы компилировалось с -std=c89
Непонятно, причём тут НКО. Вообще непонятно, как в данной ситуации можно указывать целевую аудиторию софта, кроме того факта что кому-то надо разослать кучу писем.
Можно опубликовать данные, можно опубликовать результаты их обработки. Второе, естественно, надо публиковать когда оно готово и проверено. Первое же становится готовым в момент его съёма с измерительного прибора. То есть "зафиксированы такие-то и такие-то наборы волн, вот графики вывода измерителя" — без интерпретации, просто числа, дополнительных разбирательств не требуют. Возможно, это недостаточный повод сразу публиковать их в научной статье, но и возводить вокруг этих данных режим секретности тоже ни к чему.
Уже где-то писал в комментах к https-пиарной статье, напишу тут. Сделав mitm сетевого уровня к нужному https-сайту, можно без проблем за пару секунд получить DV-сертификат к нему от let's encrypt, и дальше уже делать mitm внутри https. В обычных условиях для этого достаточно быть сетевым провайдером атакуемого сайта. Если же учесть BGP-перехваты, то достаточно быть любым из множества тех, кто может их организовать. Хотя в данном случае это уже не выйдет незаметно, в отличие от первого.
Урл в котором закодированы данные = данные в спец.формате. То есть сохранить этот урл это то же самое что скачать файл по нему. Ну и вся дальнейшая логика (как касательно сохранности этих данных так и касательно возможности их заблокировать) опирается на этот факт.
Оператор просто заблокирует все нафиг со звездочкой и адресом IP
Такое развитие событий не исключено, но эти случаи я хочу рассмотреть отдельно в другой статье. Возможно, мы с вами вместе придумаем что-то дополнительно в комментариях.
По-моему, оно не "не исключено" а оно очевидно. И никаких новых законов или подзаконных актов для этого не нужно.
А вот поисковикам вы сильно помешаете вас адекватно индексировать этой защитой.
Не думаю что там что-то сильно можно сломать. Таблицы изначально сделаны так, чтобы можно было дать свободу браузеру в мелочах и сообщить ему в коде только некоторые условия, по которым (с учётом всяческих посторонних факторов) он сам уже рассчитает всю геометрию попиксельно.
Но если всё же есть опасение что включение max-width может сломать существующие сайты — ну так ввели бы max-column-width какое-нить, которое действовало бы специально для таблиц. На тех сайтах что про него не в курсе его точно нет и следовательно ничего не сломается.
Хм, и правда. Но эта проблема — не повод выкидывать таблицы и придумывать им замену. Можно было просто сделать чтобы max-width работало, или добавить ещё какое-то свойство для этой цели специально для таблиц.
Тут видно по сути два аргумента:
1) То что div-css позволяет, в отличие от таблиц, ставить элементы в коде и выводить на экран в несовпадающих порядках. Ну, можно зачесть это за плюс, но плюс сомнительный. Когда зачем-то нужно посмотреть исходный код страницы, а там вместо ожидаемого порядка (слева направо, сверху вниз) всё расположено не пойми как — возникают только негативные эмоции.
2) В таблицах сложно сделать скруглённые углы и подобное. Ну, возможно. Хотя если использовать таблицы + css (css — не для вёрстки а для уточнения оформления) то наверно несложно.
Не очень понял, что значит "колонка минимальной ширины". Чтобы её сжать дальше нельзя было, меняя размер окна браузера? Какие с этим проблемы?
Казалось бы, таблицы поддерживаются всеми браузерами уже около 20 лет. Но нет, сначала адепты div-css вёрстки придумали себе альтернативный способ, мучились мучились с ним годами и наконец "придумали" в своём мире таблицы. Но зато всё это время они оставались модными и современными.
Да, может быть и клиент. Но (может я конечно не так понял?) в вашем случае нет множества данных которые неизвестно когда закончатся, а есть короткий запрос.
Зачем вот слать вот такое:
Когда можно послать так:
.
Как раз написали свою, оптимизированную под работу в режиме CDN (а не http-сервера общего назначения, где может быть обоснованно нужен первый вариант), для сокращения расходов на эксплуатацию, и смогли предложить вам дешевые услуги. По-моему это с их стороны правильное действие.
Поддержу Highwinds в данном споре. Chunked encoding совсем не для того, как вы его используете — он для случаев, когда на стороне источника потока данных есть какая-то относительно сложная логика, данных много и заранее неизвестно, когда они закончатся. Тело запроса к cdn — определённо не тот случай.
Вы поняли суть, правда не совсем точно её выразили. В плане "игры в прятки с роскомнадзорами и прочими ведомствами" действительно ничего делать не надо. Не согласны с политикой — меняйте политику, политическими методами.
Не пытайтесь привести теорию viktorchibisov_ST4P'а к чему-то осмысленному. Его "нейтрино" — не нейтрино, а какие-то выдуманные им "частицы", просто название ему понравилось и он его позаимствовал у физиков. Тоже самое касается и всех остальных "явлений", им описываемых. Подробнее тут: https://lurkmore.to/%D1%82%D0%BE%D1%80%D1%81%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D0%BE%D0%BB%D1%8F
Не видел их комментариев на этот счёт, но скорее всего там будет что-то о том, что DV-сертификаты это только начальный уровень, а для хорошей проверки надо EV.
Ну и вон выше про certificate pinning писали.
(не та ветка)
Ну вообще подсветка синтаксиса эти проблемы сразу убирает. Хотя можно предположить ситуацию, когда при мердже двух независимых коммитов в какую-нить vcs получится такая ситуация и подсветку там уже никто не посмотрит.
Сам стараюсь использовать наоборот // чтобы компилировалось с -std=c89
Непонятно, причём тут НКО. Вообще непонятно, как в данной ситуации можно указывать целевую аудиторию софта, кроме того факта что кому-то надо разослать кучу писем.
Т.е. это инструмент для рассылки спама.
Вы хотите сказать что все желающие перехватить BGP поголовно располагаются в России?
Да и вообще, всё немного сложнее чем вы представляете.
Можно опубликовать данные, можно опубликовать результаты их обработки. Второе, естественно, надо публиковать когда оно готово и проверено. Первое же становится готовым в момент его съёма с измерительного прибора. То есть "зафиксированы такие-то и такие-то наборы волн, вот графики вывода измерителя" — без интерпретации, просто числа, дополнительных разбирательств не требуют. Возможно, это недостаточный повод сразу публиковать их в научной статье, но и возводить вокруг этих данных режим секретности тоже ни к чему.
Какой же отвратительный дизайн. И из всех вариантов картинок белка была худшей.
Напомнило: https://habrahabr.ru/post/342168/
Уже где-то писал в комментах к https-пиарной статье, напишу тут. Сделав mitm сетевого уровня к нужному https-сайту, можно без проблем за пару секунд получить DV-сертификат к нему от let's encrypt, и дальше уже делать mitm внутри https. В обычных условиях для этого достаточно быть сетевым провайдером атакуемого сайта. Если же учесть BGP-перехваты, то достаточно быть любым из множества тех, кто может их организовать. Хотя в данном случае это уже не выйдет незаметно, в отличие от первого.
Урл в котором закодированы данные = данные в спец.формате. То есть сохранить этот урл это то же самое что скачать файл по нему. Ну и вся дальнейшая логика (как касательно сохранности этих данных так и касательно возможности их заблокировать) опирается на этот факт.
Вот ещё ссылка на ту же тему https://habrahabr.ru/post/190202/
Доработают чтобы снять эти ограничения, вот и всё. Да ещё и введут статью расходов провайдерам по внедрению нового формата.
А они там все такие идиоты и не заметят ничего.
По-моему, оно не "не исключено" а оно очевидно. И никаких новых законов или подзаконных актов для этого не нужно.
А вот поисковикам вы сильно помешаете вас адекватно индексировать этой защитой.