С
Size: a a a
2020 June 11
С
и параметры proxy_connect_timeout
proxy_send_timeout
proxy_read_timeout
send_timeout
proxy_send_timeout
proxy_read_timeout
send_timeout
Таких вообще нет у меня
С
ну и max_execution_time и request_terminate_timeout
2400 max_execution
VZ
ну ищи во что ты упираешься , увы время вот так с ходу нет помочь и вникнуть Можно попробовать погуглить nginx php 504
S
Привет всем! Можете подсказать. Была задача: сделать редирект с одной страницы на другой домен.
Для get запросов это сделал через
rewrite ^/abc/123$ https://new.domain.com permanent;
Но обнаружил, что на страницу /ABC/123 пользователи могут попасть через другой post-запрос. И правило выше для него не работает.
Как можно создать правило в конфиге nginx, которое:
1. Почитало наш post-запрос.
2. Сумело прочитать содержимое body (json) - p-id = body['options']['portalId']
3. Если p-id равен 123, то делать редирект
4. Если нет, то просто выполняем запрос как обычно.
Кто-нибудь делал подобное? Можете поделиться решениями?
Спасибо!
Для get запросов это сделал через
rewrite ^/abc/123$ https://new.domain.com permanent;
Но обнаружил, что на страницу /ABC/123 пользователи могут попасть через другой post-запрос. И правило выше для него не работает.
Как можно создать правило в конфиге nginx, которое:
1. Почитало наш post-запрос.
2. Сумело прочитать содержимое body (json) - p-id = body['options']['portalId']
3. Если p-id равен 123, то делать редирект
4. Если нет, то просто выполняем запрос как обычно.
Кто-нибудь делал подобное? Можете поделиться решениями?
Спасибо!
С
лучше залей через консоль, столько нервов съэкономишь
Спасибо. Получилось через консоль!
k
Привет всем! Можете подсказать. Была задача: сделать редирект с одной страницы на другой домен.
Для get запросов это сделал через
rewrite ^/abc/123$ https://new.domain.com permanent;
Но обнаружил, что на страницу /ABC/123 пользователи могут попасть через другой post-запрос. И правило выше для него не работает.
Как можно создать правило в конфиге nginx, которое:
1. Почитало наш post-запрос.
2. Сумело прочитать содержимое body (json) - p-id = body['options']['portalId']
3. Если p-id равен 123, то делать редирект
4. Если нет, то просто выполняем запрос как обычно.
Кто-нибудь делал подобное? Можете поделиться решениями?
Спасибо!
Для get запросов это сделал через
rewrite ^/abc/123$ https://new.domain.com permanent;
Но обнаружил, что на страницу /ABC/123 пользователи могут попасть через другой post-запрос. И правило выше для него не работает.
Как можно создать правило в конфиге nginx, которое:
1. Почитало наш post-запрос.
2. Сумело прочитать содержимое body (json) - p-id = body['options']['portalId']
3. Если p-id равен 123, то делать редирект
4. Если нет, то просто выполняем запрос как обычно.
Кто-нибудь делал подобное? Можете поделиться решениями?
Спасибо!
это через какой?
Y
Привет всем! Можете подсказать. Была задача: сделать редирект с одной страницы на другой домен.
Для get запросов это сделал через
rewrite ^/abc/123$ https://new.domain.com permanent;
Но обнаружил, что на страницу /ABC/123 пользователи могут попасть через другой post-запрос. И правило выше для него не работает.
Как можно создать правило в конфиге nginx, которое:
1. Почитало наш post-запрос.
2. Сумело прочитать содержимое body (json) - p-id = body['options']['portalId']
3. Если p-id равен 123, то делать редирект
4. Если нет, то просто выполняем запрос как обычно.
Кто-нибудь делал подобное? Можете поделиться решениями?
Спасибо!
Для get запросов это сделал через
rewrite ^/abc/123$ https://new.domain.com permanent;
Но обнаружил, что на страницу /ABC/123 пользователи могут попасть через другой post-запрос. И правило выше для него не работает.
Как можно создать правило в конфиге nginx, которое:
1. Почитало наш post-запрос.
2. Сумело прочитать содержимое body (json) - p-id = body['options']['portalId']
3. Если p-id равен 123, то делать редирект
4. Если нет, то просто выполняем запрос как обычно.
Кто-нибудь делал подобное? Можете поделиться решениями?
Спасибо!
мне кажется, что если надо читать body - это лучше делать на бэкенде.
Ну или вкручивать lua какой-нибудь. Что, в моем понимании, ничем не лучше реализации на бэкенде, и поддерживать сложнее.
Ну или вкручивать lua какой-нибудь. Что, в моем понимании, ничем не лучше реализации на бэкенде, и поддерживать сложнее.