Назад | Перейти на главную страницу

Обратный прокси Nginx: действие публикации при ударе proxy_cache - возможно?

Недавно мы узнали о nginxes post_action.

Нам было интересно, есть ли способ использовать эту директиву при попадании в прокси-кеш?

Поток, на который мы надеялись, выглядит следующим образом:

1) User request comes in
2) If cache HIT goto A / If cache MISS goto B

A) 1) Serve Cached Result
A) 2) post_action to another url on the backend

B) 1) Server request from backend
B) 2) Store result from backend

Есть идеи, возможно ли это с помощью post_action или любого другого метода?

Причина этого заключается в следующем:

По сути, мы хотели бы изменить сеанс пользователя (php, но та же концепция может применяться к большинству языков на стороне сервера) при отображении кэшированного содержимого. Это значительно увеличило бы количество обрабатываемых нами запросов с возможностью кеширования, поскольку эти запросы только ЗАПИСЫВАЮТ в сеансы, а не читают их.

Спасибо!

Если вы еще не решили это, вот пример конфигурации, которая соответствует вашим требованиям:

server {
    listen 80;
    server_name img1.example;
    root /var/www/images;
    location / { // Users request comes in
        try_files $uri @proxy; // If cache HIT goto A (show) / If cache MISS goto B (@proxy), server cached result
        post_action /url.php; // post_action to another url on the backend
    }

    location @proxy {
        proxy_pass http://static.exmaple; // Server request from backend
        proxy_store /var/www/images$uri; // Store result from backend (cache)
    }
}

Я не тестировал это, но вы можете добиться этого с помощью try_files.

location / {
  post_action /update-session;
  try_files $uri @cachemiss;
}

location @cachemiss {
  #pass to relevant backend
  post_action off; #this may or may not be needed... is post_action cleared when we change location blocks?
}

location /update-session {
  #pass to session update script
}

Другое предположение, которое мы оба делаем, заключается в том, что post_action получает все те же HTTP-заголовки, что и родительский запрос.