Cообщество пользователей SMF

Не знаю с кем посоветоваться: smf начиная с поздних версий 1 до 2 + система шифрует имена файлов при загрузке. Замечено, что изображения, независимо от размера, при таком способе secure upload визуализируются в браузерах как бы постепенно проявляясь горизонтальными линиями с белыми просветами. Случается, что изображения перестают рендериться на половине. Помогает в этом случае только F5. Вопрос: кто сталкивался?

В моём случае я использую в прицепах полноразмерные изображения, хотя что tumbs, что fullsize - рендерятся словно подгружаются ассинхронно. Я полагаю, что проблема лежит в механизме/процессе декодирования. Однако, может кто-нибудь знает лечение?

Сервер: vps, ngnix, debian, mariadb. Проблема существ(овала)ует на всех релизах продуктов.

P.S. Попробовал загрузить изображение в это сообщение, но оно вместе со страницей улетело в кэш браузера и проверить существует ли такая проблема на этом сервере нет возможности.

P.P.S. Полез в профиль: на этом сервере с аватаром в профиле аналогичная проблема.

Спасибо всем, кто не откликнулся, потому что решение проблемы, как пока оказалось, не лежит на поверхности.

Да, у тех пользователей, чей сервер работает на apache или в связке с apache, проблема заметней меньше, но она, тем не менее, присутствует.

Всё дело в механизме отдачи графических файлов сервером. Как мы знаем, smf не использует прямой путь к файлу картинки, а делает так: src=...action=dlattch...;image что представляет собой конструкцию скрипта для вызова и последующей загрузки/отображения файла. Для ngnix прочитать такой скрипт не представляет труда, а в каком формате, спрашивается, отдавать файл? Поэтому такой (зашифрованный) файл не попадёт в cache клиента и каждый раз при обновлении страницы зашифрованный графический файл будет загружаться заново. Можно закешировать (у меня, например, закешировано) запрос action=dlattach, только ничего это в плане скорости загрузки файла не изменит.

Правильный ответ я пока не знаю. Я искал ответы на русском smf уже после того, как не нашёл их на родном.

Я нарочно хотел бы продолжить вести этот блог пока не решу проблему.

В чем именно проблема, я так и не понял. То, что вложения отдаются скриптом и, соответственно, не кэшируются - всем известно и, вроде, очевидно. Сделано это для улучшения безопасности и возможности управления правами доступа к вложениям.
То, что не кэшированные картинки медленно отрисовываются на медленном соединении, тоже не открытие. Еще, на нагруженном сервере сам процесс чтения файлов с дисков тоже может подтормаживать.

Цитата: polsovatel от 16 сентября 2014, 17:43:51
P.P.S. Полез в профиль: на этом сервере с аватаром в профиле аналогичная проблема.

На этом сервере аватары отдаются напрямую, без скрипта.

Не возражаю, но не совсем всё так: изображения не "медленно отрисовываются на медленном соединении", а проявляются постепенно на любом соединении. Это нюанс.

То, что аватарки на этом сайте лежат в своей папке в явном виде, ясный-красный, просто,  хотел сказать читателю, что при первой загрузке (до попадания в cache) можно и на этом сервере понаблюдать проблему: т.е. тому, кто не в курсе или не сразу въезжает (я одним из таких немногих).

Мне бы хотелось поработать с ngnix сервером чтобы убедиться, что ничего сделать нельзя, чтобы переделать механизм smf прицепов по аналогии, например, с аватарами (я коробочный uLogin уже так переделал, к слову).  В моём серверном случае "безопасная загрузка" это избыточная функция. Библиотека рисков связанных с expoit-ами уже какая-никакая собрана, под нагрузками тоже поработал, поэтому сервер, теоретически неуязвим (это самовнушение, само собой).

Мой случай:  моя система прицепов изображений построена на stand-alone галерее , но это не вполне удобно пользователям/постёрам: открывать лишние вкладки/окна, подписывать заголовки загружаемых файлов и т.п. Думал, аналог ILA вкупе с родным smf прицепом могут выступить заменой, оказалось, не могут. Не могут так, как мне бы хотелось, т.е. без постепенного проявления с риском оборваться на половине загрузке.

Короче, спасибо за то, что подтвердили мои догадки, что моя проблема не понятна никому, но всем известна ^ ^ ^

Цитата: polsovatel от 16 сентября 2014, 17:43:51Случается, что изображения перестают рендериться на половине.

С обрывом загрузки, были однажды проблемы (вроде прошлый год), но этому причиной как выяснилось был антивирус "Касперский", сейчас они уже пофиксили этот баг. Больше с данной проблемой я не встречался.

Цитата: polsovatel от 19 сентября 2014, 17:35:29
Короче, спасибо за то, что подтвердили мои догадки, что моя проблема не понятна никому, но всем известна ^ ^ ^

Проблема никому неизвестна и не понятна, потому что ее, кроме как у вас, ни у кого не существует.
Я ничего не подтверждал, а только повторил как работает механизм вложений в SMF и ни у кого такая работа проблем не вызывает.

На самом деле, я не одинок, например, мне удалось найти свою проблему в теме 2009 года см. http://www.simplemachines.ru/index.php?topic=8815.0, в частности, на этой странице
http://foto44.ru/club/index.php?action=mgallery;sa=item;id=18
(обновите страничку и понаблюдайте).

У автора странички тоже ngnix и он тоже 5 лет назад сетовал на постепенную прорисовку. Как вы можете убедиться, проблему он не решил.

На самом деле, учитывая неприхотливость большинства классических форумистов, ничего такого, что следует исправить, в этом нет. Ввиду того, что я, напротив, "форумный хипстер-перфекционист", с такой проблемой мне вряд ли ужиться.

Когда я её решу, я дам об этом знать и поделюсь рецептом.

Цитата: polsovatel от 19 сентября 2014, 19:05:23в частности, на этой странице http://foto44.ru/club/index.php?action=mgallery;sa=item;id=18
(обновите страничку и понаблюдайте).

Посмотрел во всех имеющихся браузерах (с отключением кэша), в Opera Presto и IE картинки отрисовываются целиком разом, в FF и Chrome сверху вниз тоже разом, ни о каких заметных глазу линиях с белыми просветами и речи нет.
Если вы такое видите на всех форумах, больше похоже, что это у вас или проблемы с интернет-соединением или с каким-то локальным софтом или особенности вашего зрения позволяют вам видеть отдельные стадии отрисовки изображений в браузерах которые рендерят картинку по мере получения потока, а не разом после загрузки целой.

Я не знаю, что ответить вам на вашу реплику об отсутствии у вас такой проблемы. Правда, не знаю. Не понимаю, чем может быть полезен такой ответ. Я искал свой случай - нашёл на этом форуме. На том и пользовательское спасибо.

Судя по частоте с которой всплывает моя проблема, можно сделать вывод (я сделал такой вывод), что либо никто этого не замечает, либо замечает, но не парится, либо проблемы нет. У меня - есть, я её замечаю.

На ВСЕХ формах, где ngnix без связки с apache и имеется src=... action=dlattach я вижу (возможно, только я один), что картинка загружается постепенно. Может быть, дело в моём уникальном зрении, психике, аппаратной мощности клиента и т.п. Я, как уже было сказано выше по ветке, вижу её в вызове зашифрованного файла, который не ложится в cache. На мобильных устройствах пока не проверял, но думаю, что клиент не виноват.

Важно в моей говорилке одно: проблему я детектировал и решу плюс  с пользой для кого-то ещё. Вам, как я понимаю, моё решение не пригодится  (@_@)

А вы скринкаст запишите с экрана во время загрузки таких изображений и выложите ролик.

Да, я обязательно это сделаю по шаблону «ДО -> ПОСЛЕ», иначе результат будет для большинства неочевиден. Заодно и soft установлю надлежащий для таких случаев.

Цитата: polsovatel от 19 сентября 2014, 20:28:47Я не знаю, что ответить вам на вашу реплику об отсутствии у вас такой проблемы.

У меня тоже нет проблемы с прорисовкой. Вы хоть видео запишите...

По заявкам записал два видео: первое (http://www.youtube.com/watch?v=fskPVCLjRE8) – с обновлением страницы, ссылку на которую уже давал ранее, второе (http://www.youtube.com/watch?v=zQPmFcv57Qg) – с моего форума (доступ к тестируемой странице для гостей закрыт). Решение пока не применил, иначе бы позже возникли сложности с видео фиксацией стадии «ДО». Когда решу вопрос, вместо видео «ПОСЛЕ» дам ссылку на живую страницу.

Тестирование на firefox, провайдер Ростелеком, 5  Мбит/c, ОС Win XP

Работа над ngnix сервером для вызова изображений через action=dlattach не привела к сколь-нибудь успешным результатам. Файл изображения по адресу вида scr=http:...action=dlattach...;image удалось загонять в cache браузера через дополнительный local \ с уловием $arg для action внутри local \.php, в котором были заданы expires, и заголовки. Но, как оказалось, несмотря на то, что в cache они попадают как рисунки JPG (мой тестовый файл), где прописываются last modified, expires и пр., тем не менее, система не воспринимает такой cache, как корректный и не работает с ним. Это равносильно тому, как заставить читать файлы с окончанием ;image как статику. Может быть, конечно, такой подход  теоретически работает, только фактически никаких визуальных улучшений я не увидел (см. видеоролики выше). Таким образом, идею с конфигурацией ngnix сервера под такие нужды оставлю до лучших времён: когда будет время на такой девелопмент или когда буду рефакторить проект.

Остаётся одно: либо сочетать apache с ngnix (что для такой мелочи нецелесообразно), либо прицепы с изображениями очищать от вредоносных скриптов, переименовывать и запрашивать напрямую. Таким образом, при загрузке неизображений будет работать правило оригинального механизма шифрования, а для изображений - правило, как для обычного хостинга изображений. В свою очередь, при вызове прицепов будет использоваться соответствующее правило.

На самом деле, мой  smf уже давно потерял связь с оригиналом, поэтому, грешить так грешить. С результатами поделюсь.

Попрбовал на двух ноутах,планшете и телефоне.Везде всё нормально открывается.Инет Тринити 100 на 100.

Я не знаю, куда уходят корни решения о том, чтобы отображать форумные изображения через вызов скрипта action=dlattach...;image, хотя, возможно, эта была в своё время защита от hotlinking или защита от встроенных в графические файлы злобных скриптов, но по веским причинам я банально переделал эту "немного дебильную" систему на традиционную, т.е. без action=dlattach. В итоге все изображения кэшатся и все находятся в галерее google images и все без проблем распознаются twitter-ом и прочими социальными сетями при «поделиться с друзьями». Теперь от оригинальной SMF у меня не осталось ничего, кроме названия. К слову, переделка путей к изображениями (к attachments) представляет собой небольшую подрезку/модификацию кода, но то, как это сделать т.е. решение потребовало значительного времени. Кому интересно, я готов через ЛС дать ссылку на сайт.

Прошу закрыть тему. Решение найдено чрезе модификацию кода.

Цитата: polsovatel от 16 августа 2015, 13:55:31Я не знаю, куда уходят корни решения о том, чтобы отображать форумные изображения через вызов скрипта action=dlattach...;image, хотя, возможно, эта была в своё время защита от hotlinking или защита от встроенных в графические файлы злобных скриптов, но по веским причинам я банально переделал эту "немного дебильную" систему на традиционную, т.е. без action=dlattach. В итоге все изображения кэшатся и все находятся в галерее google images и все без проблем распознаются twitter-ом и прочими социальными сетями при «поделиться с друзьями». Теперь от оригинальной SMF у меня не осталось ничего, кроме названия. К слову, переделка путей к изображениями (к attachments) представляет собой небольшую подрезку/модификацию кода, но то, как это сделать т.е. решение потребовало значительного времени. Кому интересно, я готов через ЛС дать ссылку на сайт.

Прошу закрыть тему. Решение найдено чрезе модификацию кода.

расскажите как код модифицировали))

Цитата: polsovatel от 16 августа 2015, 13:55:31представляет собой небольшую подрезку/модификацию кода, но то, как это сделать т.е. решение потребовало значительного времени.

Цитата: kak2z от 16 августа 2015, 14:06:22расскажите как код модифицировали))

Да, было бы познавательно, чтобы самому не идти той же тропой.

GeorG
Для связки Apache2 + Nginx в файле Display.php ф-ция Download() просто меняем код который отдает файл клиенту на код который отдает заголовок X-Accel-Redirect. Тогда nginx сам отдаст статику.
Хочу внести поправку.
В исходных скриптах форума разработчики так организовали отдачу вложения.
Вначале проверяют сколько весит файл, если более чем 4194304 байта то читают его частями по 8КБайт в выходной буфер и отправляют пользователю.
Если же файл легче - то 2 варианта.
Сперва проверяют можно ли использовать ф-цию readfile, если нельзя - file_get_contents
Между ними есть различие. readfile сбрасывает результат своей работы в буфер вывода, а file_get_contents отображает файл в память
Если использовать X-Accel-Redirect то мы освободим бэкенд от чтения файла с диска и передадим эту задачу nginx.

Я могу показать «что сделано», но не «как сделано». Обращайтесь. У меня сервер ngnix+fpm. Решить мою проблему через конфигурацию ngnix не получилось, хотя, помню, нашёл где-то в комментарии у швейцарца идею как заставить ахинею вида <img src="http://www.simplemachines.ru/index.php?action=dlattach;topic=17446.0;attach=11572;image" alt="" id="thumb_11571" class="atc_img"> попадать в cache у клиента и читаться как путь к графическогму файлу, которая на практике не нашла подтверждения. Когда мне надоело искать обходные пути и паллиативы, я изменил код. Думать пришлось много, работать – немного.
Подрезать код нужно помаленьку в разных местах.

upd 17/08/2015 20:10
То, что вверху это что? Теоретизация чего собственнно? Вызов изображения через action=dlattach это атавизм. Попытка превратить php запрос в url путём серверного скрипта – бесперспективна и подобна социальной адаптации безногого калеки. Однако, если кто-либо предложит сниппет для встройки в конфигурацию ngnix, то я готов взяться за доработку, протестировать и выложить результаты.

upd 18/08/2015 9:00
Забыл рассказать, что я сохранил оригинальный порядок отображения вложений для Личной почты. При загрузке изображений в сообщения форума название файла принудительно изменяется и имеет такой вид (для превьюшки): 201507082053rltrd1993_thumb.jpg, в то время, как для сообщений в личной почте название не изменяется, имеет вид (как в этой теме) 010.jpg и при этом отображается под изображением (как здесь). Дело в том, что через почту часто передаются документы, названия файлов которых несут информативную функцию, например, чертёжCADкурсовая.cad и т.п.

polsovatel
Да выложите вы наконец хоть что-то конкретное. Это все же форум русскоязычной поддержки пользователей.
Хорош просто пиарится.
Если хотите денег и стесняетесь - просто заявите об этом. Может кто и заплатить если ваше решение реально крутое и от него есть польза.