Пользователь (пользователь X), которому изменили полномочия на их почтовом ящике, не будет знать, если почтовый ящик не будет открыт на другом пользователи (Пользователь Y) машина, и Пользователь Y вносит изменения в содержание почтового ящика.
В прошлом я имел дело с менеджерами, которые потребовали этой возможности, и вещи стали действительно ужасными, когда менеджер случайно удалял/изменял объекты в том пользовательском почтовом ящике.
Я не верю, что вы можете передать перенаправление, используя 503, поскольку он не предназначен для перенаправления.
Вам нужно будет либо разместить этот конкретный файл в безопасном месте, чтобы на него не влияла какая-либо действующая система обслуживания. или используйте proxy_pass, чтобы nginx извлекал страницу из amazon и затем передавал ее клиенту.
Что-то в этом роде может помочь. Я давно не касался nginx, но это может дать вам представление о том, что я предлагаю:
error_page 503 @maintenance;
location @maintenance {
rewrite ^(.*)$ /maintenance.html break;
proxy_pass http://mysite.s3-website-us-east-1.amazonaws.com;
}
Изменить: на странице, на которой упоминается рекомендация Google для 503, кто-то прокомментировал фантастическую идею о том, как перенаправить с помощью 503. Он упомянул об этом для Apache, но концепция та же самая для nginx:
Привет!
Это может помочь. На серверах Apache это s обычно невозможно перенаправить пользователя с любым другим кодом состояния HTTP, кроме класса 3xx.
Пользователи, которые посещают сайт, находящийся на обслуживании, заслуживают получить страницу с полезной информацией.
Сделайте это сначала с помощью перенаправления 302, которое ведет на страницу 503, которая выводит заголовок 503 (то есть через PHP или Perl). Это будет хорошо работать с Google, поскольку Google назначит все свойства целевой страницы исходной странице, когда они встретят 302, включая ответ заголовка. Я тестировал это на виртуальных хостах, и он работает по желанию. Если можете, выберите время с несколькими запросами для действий службы.
С уважением, Томас