Comments 17
Скажите это владельцу сайта sysadmins.ru Петру.
Там присутствует и не валидный html и названия топиков шифруются через AES (якобы защита от ботов) и всякое прочее. В общем минус вам за парсинг регулярками.
Там присутствует и не валидный html и названия топиков шифруются через AES (якобы защита от ботов) и всякое прочее. В общем минус вам за парсинг регулярками.
Понимаю боль автора, но от статьи ждал какого-то вывода, а вместо этого она закончилась истерикой.
Слишком толсто.
UFO just landed and posted this here
В нормальных языках и технологиях, картинки проверяются в памяти и никуда не сохраняются пока не проверяться на то, что это именно картинки. Не забить канал помогает правильная настройка, которая не даст загрузить большие файлы не только на стороне браузера, но и сервера. Проблемы с кэшем решают современные подходы (SPA и проч.) в кэше только скрипты, а остальное берется из API. Остальное просто хейтинг.
В памяти говорите? А у Вас есть фотографы которые работают с RAW? Или монтажеры которые грузян монтажную колбасу?
Т.е. мне заливать в память гигабайтную картинку и только потом пытаться ее распарсить? И пока пользователь ее заливает, 2 часа этот гигабайт серверной памяти принадлежит только ему? Или мы прикроем задницу лимитом вида «не более 100кб на файл, 640х480 наше все», наплевав на пользователя? И да, расскажите как это сделать, так как файл (а точнее запрос) начинает записываться на диск еще на стадии декодинга запроса сервером. И никакая бизнес-логика не запускается, пока пользователь свой гигабайт не загрузит (ну, во времена CGI запускалась).
А чего гигабайтную? Почему не 10гб, 20гб, 40гб или на худой конец петабайт?
Я не в курсе, какой из стеков вы используете. Если там нет настройки Request Timeout / Max Request Length / Content Size или что-то подобного, и все настроено так, чтобы принимать реквесты любого размера и длительности, и для вашего приложения это действительно проблема, то я предлагаю вам этот стек поменять на тот, в котором это все есть.
Прошу меня простить, но я не понял в чем заключается вопрос.
И пока пользователь ее заливает, 2 часа этот гигабайт серверной памяти принадлежит только ему?
Я не в курсе, какой из стеков вы используете. Если там нет настройки Request Timeout / Max Request Length / Content Size или что-то подобного, и все настроено так, чтобы принимать реквесты любого размера и длительности, и для вашего приложения это действительно проблема, то я предлагаю вам этот стек поменять на тот, в котором это все есть.
И да, расскажите как это сделать, так как файл (а точнее запрос) начинает записываться на диск еще на стадии декодинга запроса сервером. И никакая бизнес-логика не запускается, пока пользователь свой гигабайт не загрузит (ну, во времена CGI запускалась).
Прошу меня простить, но я не понял в чем заключается вопрос.
Возьмем для примера PHP, хотя описанное справедливо и для 99% остальных языков и технологий. Допустим, мы хотим позволить пользователю загружать картинки на сайт, для этого делаем формочку с полем типа file и…Так работает браузер и HTML, а серверные языки тут не при чём. Реализовать загрузку на файла с прогрессбаром можно уже очень много лет разными способами.
Всё, что вы описали далее, это обычное поведение. Его можно изменить. Например есть такие модули, как nginx-upload-module. И вообще, это скорее относится к протоколу HTTP, чем к языкам, которые его обслуживают.
Возьмем к примеру java, хотя нет — ruby или go, хотя нет — PHP!
1) При загрузке файла потоком, его можно никуда не сохранять! Он приходит потоком, который можно и остановить и оборвать, при этом еще раз — это не файл в /tmp, а поток непосредственно с клиентское приложение. Подозреваю, в PHP тоже можно получить именно поток, а не ссылку на уже загруженный файл, просто научитесь его готовить.
2) Про кеширование. Используйте правильные шаблонизаторы, которые умеют кешировать кусочки, а не всю страницу, и если данные куска страницы не поменялись, то он просто возьмется из кеша уже отрендеренный. И да, всю страницу тоже можно. И да, PHP тоже так умеет, просто научитесь его готовить.
3) Какое такое API? Вы о чем? Верстка на всем, что движется доступна в любом современном CSS фреймворке, начиная с bootstrap и заканчивая w3css, просто научитесь его готовить.
В общем — Вам двойка за подготовку домашнего задания.
1) При загрузке файла потоком, его можно никуда не сохранять! Он приходит потоком, который можно и остановить и оборвать, при этом еще раз — это не файл в /tmp, а поток непосредственно с клиентское приложение. Подозреваю, в PHP тоже можно получить именно поток, а не ссылку на уже загруженный файл, просто научитесь его готовить.
2) Про кеширование. Используйте правильные шаблонизаторы, которые умеют кешировать кусочки, а не всю страницу, и если данные куска страницы не поменялись, то он просто возьмется из кеша уже отрендеренный. И да, всю страницу тоже можно. И да, PHP тоже так умеет, просто научитесь его готовить.
3) Какое такое API? Вы о чем? Верстка на всем, что движется доступна в любом современном CSS фреймворке, начиная с bootstrap и заканчивая w3css, просто научитесь его готовить.
В общем — Вам двойка за подготовку домашнего задания.
Автор любит устаревший веб?
Когда надо было уместить хотя бы стартовую страницу сайта со всем её содержимым в 20-30 кб? Когда приходилось генерировать на сервере все страницы в десятке вариантов, ибо клиенты были разными, очень разными и dhtml почти никто не умел? Когда… много чего ещё можно перечислить такого, после чего современный веб — сказка наяву.
Автор, похоже, попросту не разобрался с технологиями и у него болит. Но может уже пора повзрослеть? Выйти из детсадовского возраста? (Это отсылка к известному тесту про скамейку, краткое изложение вот тут: bash.im/quote/418579)
Как уже было описано ранее — все «проблемы» или не проблемы или имеют решение. Я не скажу за php, но на .net уж точно :) И файлы без сохранения на диск и с прогрессбаром, и даже с проверкой содержимого до полной загрузки. И кэш на любой вкус и цвет, работающий ровно тогда, когда это надо. И API с внятной структурой и встроенной документацией. Что уж говорить про возможность универсализировано смаппить ajax запрос на запрос к БД, с валидацией, да через кэш, и с прозрачной проверкой прав пользователя…
А может автор так странно изливает недовольство заполонившими веб рукожопами, к которым он сам себя не относит? Тогда почему бы прямо так не сказать?
Когда надо было уместить хотя бы стартовую страницу сайта со всем её содержимым в 20-30 кб? Когда приходилось генерировать на сервере все страницы в десятке вариантов, ибо клиенты были разными, очень разными и dhtml почти никто не умел? Когда… много чего ещё можно перечислить такого, после чего современный веб — сказка наяву.
Автор, похоже, попросту не разобрался с технологиями и у него болит. Но может уже пора повзрослеть? Выйти из детсадовского возраста? (Это отсылка к известному тесту про скамейку, краткое изложение вот тут: bash.im/quote/418579)
Как уже было описано ранее — все «проблемы» или не проблемы или имеют решение. Я не скажу за php, но на .net уж точно :) И файлы без сохранения на диск и с прогрессбаром, и даже с проверкой содержимого до полной загрузки. И кэш на любой вкус и цвет, работающий ровно тогда, когда это надо. И API с внятной структурой и встроенной документацией. Что уж говорить про возможность универсализировано смаппить ajax запрос на запрос к БД, с валидацией, да через кэш, и с прозрачной проверкой прав пользователя…
А может автор так странно изливает недовольство заполонившими веб рукожопами, к которым он сам себя не относит? Тогда почему бы прямо так не сказать?
Краткое содержание статьи, кому лень читать: «Раньше я тырил информацию с сайтов легко, а теперь злые веб-мастера ради удобства глупых юзеров всё делают через XHR, и у нас, парсеров, бомбит.»
Прочитал до, точнее, еле дождался, конца статьи, но так и не увидел ответ на вопрос в заголовке "За что я не люблю современный веб".
Содержание всех разделов больше похоже на легкий стёб на тему «Обо всем, что слышал». Если бы в конце были выводы, могла получиться (плохая или хорошая) статья. А так, увы…
Содержание всех разделов больше похоже на легкий стёб на тему «Обо всем, что слышал». Если бы в конце были выводы, могла получиться (плохая или хорошая) статья. А так, увы…
Only those users with full accounts are able to leave comments. Log in, please.
За что я не люблю современный веб