Регулярное выражение Nginx (Perl) для перенаправления с одного URL на другой

У меня есть блог wordpress, где у меня есть серия постов с их собственными слагами. Недавно я заметил законные ошибки 404, когда люди переходят на mysite.com/my-slug/&somestuff. или mysite.com/my-slug/somestuff. Я понятия не имею, откуда они взяли «кое-что», но я хочу предотвратить это.

Я написал регулярное выражение для перенаправления с mysite.com/my-slug/anything на mysite.com/my-slug/

^/easy-fluffy-american-pancakes/.+

Это прекрасно работает. Ну, почти. Как оказалось, мой удобный для печати вид любого поста

^/easy-fluffy-american-pancakes/print/1234

1234 — это идентификатор сообщения. Итак, теперь это также перенаправляется на почту. Как я могу исключить печать из редиректа?

^/easy-fluffy-american-pancakes/(.+)|(?!print/[0-9]*/)

Я не могу заставить его работать. Либо он не совпадает, либо я получаю слишком много переадресаций.

Я думаю, вам нужен отрицательный просмотр сразу после косой черты ^/easy-fluffy-american-pancakes/(?!print/[0-9])(.+)regex101.com/r/LifGRJ/1 Если вы вообще не хотите сопоставлять print, вы можете использовать, например, ^/easy-fluffy-american-pancakes/(?!print\b)(.+) regex101.com/r /PehXrT/1

The fourth bird 19.12.2020 00:32

Похоже, что странные URL-адреса, вероятно, просто люди, пытающиеся использовать ваш сайт. Я бы вообще не стал их перенаправлять. На самом деле, я бы, вероятно, заставил их вернуть 500 (фальшивые 500) или оставил их как 404. Однако обычно боты не останавливаются из-за этого, но я не хочу, чтобы они думали, что нашли что-то, что отвечать.

brian d foy 19.12.2020 16:09

Да, я определенно задавался этим вопросом

David Brossard 19.12.2020 21:35
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
3
94
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Закрывать

^/easy-fluffy-american-pancakes/(?!print/[0-9]).+

Читать (?!...) как «не следует ...". С точки зрения внешней стороны (?!...), (?!...) ничему не соответствует, поэтому .+ начинает совпадать сразу после /.

Спасибо, мне нужно экранировать символ /?

David Brossard 19.12.2020 02:25

Неважно... Это не работало из-за кэширования.

David Brossard 19.12.2020 02:27

Возможно, вы захотите сделать так (?!print/[0-9]+$).+, чтобы URL-адреса для печати с конечным мусором также перенаправлялись.

lordadmira 19.12.2020 05:13

@lordadmira Это ломает .../print/1234?o=1

ikegami 19.12.2020 06:58

@ikegami Это то, что я собирался. /print/1234?o=1 будет перенаправлять, а /print/1234 нет.

lordadmira 19.12.2020 07:14

@lordadmira, Опять же, это было бы плохо. Я не уверен, почему я должен объяснять это для вас, но .../print/1234?... должен идти на ту же страницу, что и .../print/1234. На самом деле, многие веб-сайты добавляют параметры к ссылкам (например, в целях отслеживания), и вы сломаете все эти ссылки (в дополнение к тем, которые созданы самим хост-сайтом).

ikegami 19.12.2020 11:08

@ikegami Как ты можешь говорить, что это будет плохо? Вы не знаете вариант использования. Почему у вас есть проблемы с тем, что я выкладываю другой вариант? Как я уже писал, если возникает проблема с остатками мусора на отпечатках, вот как их можно отловить. Ты должен перестать быть таким императивным и быть более сослагательным, как я. В любом случае мой ответ является ценной иллюстрацией несоответствия для всех, кто приходит сюда. Я не должен объяснять это для вас.

lordadmira 19.12.2020 21:37

Если вы добавите проверку конца строки к отрицательному просмотру вперед, он также поймает print с конечным мусором. Если это проблема.

print "foo/" =~ m{foo/(?!print/[0-9]+$).+} ? "redirect" : "pass";
pass

print "foo/9ujsdu" =~ m{foo/(?!print/[0-9]+$).+} ? "redirect" : "pass";
redirect

print "foo/print/1234" =~ m{foo/(?!print/[0-9]+$).+} ? "redirect" : "pass";
pass

print "foo/print/1234?o=1" =~ m{foo/(?!print/[0-9]+$).+} ? "redirect" : "pass";
redirect

Это было бы плохо. Это сломает .../print/1234?..., который должен находиться на той же странице, что и .../print/1234?.... Почему ваше предположение по умолчанию было бы иным? Я уже указал на это до того, как ты это написал...

ikegami 19.12.2020 11:10

Другие вопросы по теме

Похожие вопросы