Как обычно, хочется странного...

Чт Дек 16 11:48:06 MSK 2010

Допустим, есть фронтенд (nginx) и есть некий бэкенд
В конфиге фронтенда что-нить в духе

location /news/ {
  set $backend_content_url  /backend/some/uri$uri;
  rewrite ^(.*)$ /frontend/layouts/news.shtml;
}
...
location /frontend/ {
   internal;
   ssi on;
   root  /some_dir/frontend;
}
...
location /backend/ {
   internal;
   fastcgi_pass ......
   ...
  вобщем, на бэкенд за контентом
}

layout_one.shtml представляет из себя что-нить в духе
<html>
  <head>
  ..
  </head>
<body>
  <div class="header">
   ...
  </div>
  <div class="content">
  
  </div>
  <div class="header">
   ...
  </div>
</body>
</html>

То есть, допустим,  на фронтенде лежат лэйауты страниц, собирающие данные из разных кусочков (что-то из кеша, что-то непосредственно из бэкенда и т.п.).
И при этом возникает следующая проблема -- как реализовать "нормальную реакцию" на ошибки?
Что имеется в виду:
   1. пользователь обращается по какому-то урлу (ну, скажем, посмотреть некую новость с id=125)
   2. фронтенд по урлу определяет, какой именно лэйаут следует использовать для формирования страницы просмотра новости,  загружает этот лэйаут (shtml) и исполняет его ssi-команды, которые "собирают" страницу из кусочков через include virtual/include file
   3. пользователь видит готовую страницу
   3а. НО: если новости с заданным id не существует, то хотелось бы отдать пользователю 404 или редиректнуть его куда-нибудь сообразно логике приложения

Однако, как это сделать, если о том, что "новости с таким id не существует!" знает бэкенд , и происходит это уже где-то в середине формирования страницы (то есть на этапе include virtual)?
Таким образом, имеем вопрос: можно ли каким-то образом буферизировать сборку страницы с целью проверить, не вернула ли в процессе сборки какая-то значимая её часть интересный нам код ошибки, чтобы на основании этих данных принять окончательное решение -- отдать собранный контент пользователю или же прервать "сборку страницы" и куда-нить его (пользователя) редиректнуть?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20101216/10f7b2e3/attachment-0001.html>