На community.wanikani.com ссылки на темы, содержащие японские символы в полном URL, перестали открываться в новой вкладке или при копировании и вставке ссылки. Переход по ссылке в той же вкладке по-прежнему работает.
Например, открытие этой ссылки в новой вкладке должно перенаправлять на
Если ссылка совпадает в точности, всё работает корректно. Однако, конечно, при переименовании тем это часто не так.
Я также попытался воспроизвести проблему на try.discourse.org, но в этой установке японские символы никогда не добавляются в URL, даже если они присутствуют в заголовке темы. Я не уверен, почему это происходит, но без этого я не могу продемонстрировать ошибку там.
вздыхает Похоже, это ещё одна ошибка Chrome. У меня всё работает нормально и в Firefox, и в Edge. Странно, что в режиме инкогнито всё срабатывает с первого раза, но затем при повторной попытке возникает ошибка. То же самое происходит после очистки кэша и файлов cookie сайта и перезагрузки компьютера.
Chrome сообщает, что ошибка связана с превышением количества перенаправлений.
Не могли бы вы проверить в Chrome, чтобы подтвердить, является ли это общей проблемой именно в этом браузере, а не только у меня? Просто убедитесь, что вы пытаетесь открыть страницу несколько раз, так как первый раз всё работает нормально. Благодарю за помощь!
Всё ещё с Chrome? Просто хочу убедиться перед тем, как сообщить об этом им. Предполагаю, что в последнее время в Discourse ничего не менялось, связанное с этим? (В любом случае, это, скорее всего, всё ещё проблема Chrome, так как она возникает только там, даже если в Discourse что-то и изменилось.)
Так нет же. Сегодня всё снова началось. Не понимаю, как это вообще ненадолго исправилось.
Раз это займёт время, я готов пока использовать обходные пути. В первом посте я упоминал, что на try (и я проверил это также здесь, на meta) японские символы вообще не добавляются в URL, что фактически обходит эту проблему. Это настройка сайта или категории, о которой я могу поговорить с администратором своего сайта? Есть ли какие-то другие предложения по обходу проблемы, кроме этого?
Я изучил наш код, и похоже, что ошибка довольно проста, но я хотел бы проверить свои предположения.
У нас есть настройка сайта с именем slug_generation_method, которую необходимо изменить со значения по умолчанию ascii на encoded, чтобы вызвать эту ошибку. При изменении этой настройки мы очищаем все слайги и генерируем их заново.
Что я не понимаю, так это почему при установке настройки сайта в значение “encoded” слайг генерируется следующим образом:
Необработанный слайг из таблицы возвращается в заголовке Location ответа 301, когда слайг темы не совпадает, и, на мой взгляд, мы должны возвращать там корректный URL.
То есть вы имеете в виду, что сама URL-адрес будет отображать закодированную версию? Или просто то, что редирект внутренне обработает это, используя закодированную версию? В любом случае, было бы здорово, чтобы это «просто работало» и не зависело от особенностей браузеров.
Нет, что подтверждается открытой темой в категории bug здесь
@sam, я снова посмотрел на это сегодня, и есть два пути решения:
Хранить фактически кодированный слайг в колонке slug, когда настройка генерации слайгов установлена в значение encoded. Выполнить миграцию для очистки всех текущих слайгов, использующих кодированные слайги, чтобы они со временем корректно пересоздавались.
Оставить текущий UTF-8 слайг и исправлять его на лету при отправке в заголовке для 301-редиректа.
На мой взгляд, вариант 1 «более правильный», и он затруднит передачу «сырого» слайга клиенту. Однако простого исправления генератора слайгов оказалось недостаточно: браузер получает кодированный URL при 301-редиректе, но декодирует его для следующего запроса, из-за чего наше сравнение слайгов не проходит и происходит повторный редирект. Это означает, что мне также придётся исправить метод сравнения слайгов в контроллере тем, а возможно, и в других местах.
