Страницы: 1
Было бы куда лучше если бы вы зарегистрировали этот баг на Bugzilla.
Однако, не стоит ожидать что его исправят в обозримом будущем, если он будет воспроизведён (повторяемым) и подтвердится другими пользователями. Всё будет зависеть от присвоенного уровня серьёзности и приоритета.
На моей машине и с браузером версии 100.0b4 проблема повторяется 100% Так что такой баг будет легко найти. Но я честно и не надеюсь, что этому багу назначат хоть какую то привилегию. Он особо и не критичен.
А так, есть у меня любимый баг в мозиле (баг в TLS сессии) который появляются рандомно. Может и раз в пол года вылезти. А может и 2 раза на день. Я запарился его искать. Даже скачал исходники мозилы, наставил 100500 трассировки везде где выводится сообщение бага (единственно что мне известно о нём). Скомпилировал и начал ждать появления бага. Ага. До сих пор жду. Тем более та версия что лежит в общем доступе в нете и которая у меня полу
…Собственно тему создаю - может кто из разработчиков мозилы увидит? А ещё для того что бы помочь кому то решить подобный баг.
Суть такова - если в запросе возвращается:
Это значит что браузер должен закешировать ответ. но перед его использованием должен проверить состояние кеша- не протух ли он.
В работе это выглядит так. Посылаем ответ браузеру. Устанавливаем etag. Браузер получает ответ, кеширует его. Пользователь обновляет страницу. Браузер делает запрос на сервер с ранее принятым etag. Сервер проверяет etfg и если данные не изменились возвращает 304. Если изменились возвращает новые данные (код 200) и новый etag. Браузер получив новый etag сохраняет новые данные и новый etag.
Собственно я описал классический пример работы кеша.
А теперь о баге. В процессе экспериментов я увидел что mozila работает не совсем так как ожидалось. Всё работает по сценарию, пока не придёт изменённый etag. И mozila не запомина
…В одном проекте для кеширования больших данных которые поступают с сервера и не помещаются в очень маленький storage, используется GET запрос.
Схема такая. Идёт запрос на сервер - GET. Возвращаются полезные данные для пользователя. Также устанавливается etag для этих данных. Если пользователь опять запрашивает эти данные, то сервер проверив etag и определив что данные не изменились - возвращает 304. И клиент берёт данные с кеша. Собственно старая рабочая схема.
Разумеется данные для разных пользователей разные.
И тут становится проблема. Как удалить данные клиента с кеша, если клиент разлогинивается с сайта?
Есть такой замечательный заголовок Clear-Site-Data https://developer.mozilla.org/en-US/doc … -Site-Data
Собственно при возвращении заголовка с сервера - браузер должен почистить все кеши для сайта. Я проверил работает на движках хромиума. Гугл, Edge и прочих. Но вот в мозиле не работает. По ссылке приведённой выше сказано - до 94 версии работало
…Проблему решил. Достаточно было просто прочитать лог. A именно строчку ERROR: Rust compiler 1.49.0 is too old. Установил последнюю версию раст - всё скомпилилось и запустилось. Когда топик создавал, этой задачей занимался в фоне, и был занят другой разработкой. И особо не смотрел что и как там не работало.
Вот лог:
[code]
$ ./mach build
0:00.68 Clobber not needed.
Config object not found by mach.
created virtual environment CPython3.7.9.final.0-64 in 236ms
creator CPython3Windows(dest=C:\dev\mozilla-central\obj-x86_64-pc-mingw32\_virtualenvs\build, clear=False, no_vcs_ignore=False, global=False)
activators BashActivator,BatchActivator,FishActivator,PowerShellActivator,PythonActivator
0:01.40 c:/dev/mozilla-central/obj-x86_64-pc-mingw32\_virtualenvs\build\Scripts\python.exe c:/dev/mozilla-central\configure.py
0:01.60 Using Python 3.7.9 from c:\dev\mozilla-central\obj-x86_64-pc-mingw32\_virtualenvs\build\Scripts\python.exe
0:01.62 checking for vcs source checkout... hg
0:01.67 checking for a shell... C:/mozilla-build/msys/bin/sh.exe
0:01.67 checking for host system type... x86_64-pc-mingw32
0:01.67 checking for target system type... x86_64-pc-mingw32
0:02.10 checking whether cross compiling... no
0:02.27 checking for Python 3... c:/dev/mozilla-central/obj-x86_64-pc-mingw32/_v
Устанавливал чистую версию (Firefox Developer Edition v87.0b3 64bit Win) на другой комп - баг есть. Проверил сайт с мобильника хром+лиса (какие версии не смотрел - последние наверно) - бага нету.
Суть такая. В повседневной жизни сижу именно на этой версии браузера. Есть собственный проект web движка и сайт на нём. Сайт https://linkin.link С недавнего времени стартовая страница этого сайта стала вести себя странно. При открытии - загрузчик странички не переставал крутится. Видео в формате webm - на стартовой странице не работало или работало криво.
Конечно же грешили на собственный web сервер. Вобщем потратили кучу времени но так и не нашли в чём проблема. А потом оказалось что эта страница прекрасно открывается в других браузерах. Ради эксперимента выкачали предыдущую версию 78.0b2 - и в этой версии страница открывается нормально.
Все стрелки указывают что баг именно в последней версии. Расследование показало следующие. В современном вебе нету нормально способа закачивать кусочек видео. Браузеры обычно качают полное (хотя можно было бы использовать head запрос) а потом жёстко обрывают сокет. Затем уже используют range-запросы. Видимо где то здесь и зарыт баг. Проблема видимо
…Спасибо за такой подробный комментарий. Обязательно в будущем пригодится.
Что касается моей проблемы вроде клубок развязал. Честно говоря очень странная проблема.
На сервере есть модуль авто определения размера буфера для приёмных и передающих сокетов. В этом модуле была ошибка и буфер выделялся маленький.
Из-за этого на уровне TCP постоянно сыпались ситуации с переполнением окна передачи [TCP Window Full] - что само по себе не является ошибкой
Но из за этого почему то у TLS ехала крыша - и сокет периодически закрывался со стороны клиента с выставлением флага RST. В общем описал как мог.
Увеличили размер буфера -> ошибки пропали.
Короче обложился wireshark. Проанализировал логи корректные и те которые вызывают ошибку. Методом исключение одинаковых кусков пришёл к выводу о некорректной шифрации финального рукопожатия. Получаться что мозила мне не поможет. Так что можно наверно тему закрыть.
Суть проблемы такая. Есть веб сайт при подключении к которому используя tls1.2 вылетает следующая ошибка:
Ошибка при установлении защищённого соединения
При соединении с *** произошла ошибка. библиотека безопасности: неверный формат сообщения в кодировке DER.
Код ошибки: SEC_ERROR_BAD_DER
Страница, которую вы пытаетесь просмотреть, не может быть отображена, так как достоверность полученных данных не может быть проверена.
Пожалуйста, свяжитесь с владельцами веб-сайта и сообщите им об этой проблеме.Подробнее…
Сайт использует само писанный web-сервер + крипто стек.
Эта ошибка где то в рукопожатии TLS. Со стороны сервера любая отладка. Любая точка остановки. Но вот со стороны mozila - как проверить в каком месте рукопожатия происходит сбой?
Вся проблема состоит в том что это оооо-чень редкая ошибка. Может появится раз в день, а может раз в месяц.
Есть ли исходники mozila?
Идея такая - посмотреть где именно в коде встречается ошибка SEC_ERROR_BAD_DER - и
…Страницы: 1