На 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-адрес будет отображать закодированную версию? Или просто то, что редирект внутренне обработает это, используя закодированную версию? В любом случае, было бы здорово, чтобы это «просто работало» и не зависело от особенностей браузеров.
Нет, как видно из открытой темы в категории Contribute > Bug здесь
@sam, я снова посмотрел на это сегодня, и здесь есть два варианта действий:
Сохранять настоящий закодированный slug в колонке slug, когда настройка генерации slug установлена в значение encoded. Создать миграцию для очистки всех текущих slug при использовании закодированных версий, чтобы они правильно регенерировались со временем.
Сохранить текущий slug в UTF-8 и преобразовывать его на лету при отправке в заголовке для редиректа 301.
По моему мнению, вариант 1 «более правильный», и он усложнит передачу необработанного slug клиенту. Однако одной лишь доработки генератора slug было недостаточно: при редиректе 301 браузер получает закодированный URL, но декодирует его для следующего запроса, из-за чего сравнение slug не совпадает, и происходит повторный редирект. Это означает, что мне также нужно будет доработать метод сравнения slug в контроллере тем (topics controller), а возможно, и в других местах.
