Как настроить Play в подкаталоге, за обратным прокси-сервером Apache? - PullRequest
Новая
       10

Как настроить Play в подкаталоге, за обратным прокси-сервером Apache?

6 голосов
/ 04 января 2012

У меня есть интерфейс Apache 2, который обслуживает два вида запросов:

  • Запросы к корневой папке (например, http://mysite.com/ и http://mysite.com/help) обслуживаются самим апачем (PHP / Wordpress).
  • Особые запросы к подпапке '/ playapp' перенаправляются в Play! через обратный прокси через мод-прокси:

мод-proxy.conf 

ProxyPass        /playapp/ http://localhost:9000/
ProxyPassReverse /playapp/ http://localhost:9000/

Конечным результатом является то, что запросы http://mysite.com/playapp/Controller/action доходят до сервера Play в виде http://localhost:9000/Controller/action

Теперь играй! обслуживает страницу корректно, но все ссылки, включая javascript, css и ссылки на другие страницы, не работают. Например, если представление использует: 

#{stylesheet 'style.css' /}

Тогда результат будет 

<link rel="stylesheet" type="text/css" href="/public/stylesheets/style.css" charset="utf-8" ></link>

Таким образом, конечный пользователь пытается получить http://mysite.com/public/stylesheets/style.css, который возвращает 404, потому что он на самом деле не является частью Play! приложение.

Как правильно настроить Apache + Play для игры здесь?

Я ищу результат для Play! чтобы возвратить URL-адреса, подобные этому, в окончательном отрендеренном HTML-коде (или, возможно, Apache перезапишет URL-адреса соответствующим образом): http://mysite.com/playapp/public/stylesheets/style.css

Кроме того, мне нужна возможность устанавливать ссылки за пределами приложения Play. Например, я хочу, чтобы домашний маршрут (/) отображался в моем абсолютном корне (http://mysite.com/), а не в корне Play.

Ответы [ 4 ]

3 голосов
/ 04 января 2012

Во-первых, кое-что важное: apache2 не может (легко) изменять ссылки на страницах.Так что Play уже должен предоставить правильные.

Использование субдомена сделает все это полностью прозрачным, но давайте ответим на ваш вопрос.

У вас действительно есть два вопроса в вашем вопросе,

Исправить подпапки для статических ресурсов

  • Результат, который я ищу, - для Play!чтобы возвратить URL-адреса, подобные этому, в окончательно отрендеренном HTML (или, возможно, Apache перезапишет URL-адреса соответственно): http://mysite.com/playapp/public/stylesheets/style.css

Используя маршруты, просто установите

GET / playapp / public/ staticDir: public

Используете ли вы http.path ?

Я думаю, обратное должно учитывать это ....

внешние ссылки

  • Кроме того, мне нужна возможность устанавливать ссылки за пределами приложения Play.Например, я хочу, чтобы домашний маршрут (/) был привязан к моему абсолютному корню (http://mysite.com/),, а не к корню Play).

Ну, это звучит просто: если он находится вне приложения воспроизведения, то выне использовать обратный URL, поэтому просто укажите абсолютный путь в ссылках ... или вы используете обратный? Если да, можете ли вы привести пример?

1 голос
/ 05 января 2012

Глупо ожидать, что Apache будет переписывать файлы HTML, JS и CSS. Как насчет SWF-файлов или динамически создаваемых URL-адресов в JS? Во всяком случае, вы поняли мой дрейф. Документация ProxyPassReverse гласит:

Только заголовки ответа HTTP, специально упомянутые выше, будут переписаны. Apache не будет переписывать другие заголовки ответа и не будет переписать URL-ссылки внутри HTML-страниц. Это означает, что если Прокси-контент содержит абсолютные URL-ссылки, они будут игнорироваться прокси. Сторонний модуль, который будет смотреть внутри HTML и Переписать ссылки URL - это mod_proxy_html Ника Кью.

Как один из предложенных комментариев, гораздо более вероятный подход - это настроить другое DNS-имя (например, play.ripper234.org) и создать такую ​​конфигурацию, как: 

<VirtualHost>
ServerName play.ripper234.org
ProxyPass / http://localhost:9000/
ProxyPassReverse / http://localhost:9000/
</VirtualHost>

Даже это не спасет вас, если файлы будут возвращены Play! будет использовать полный URL-адрес, такой как http://localhost:9000/ или http://www.yahoo.com/ или еще много чего.

Что касается рекомендации вам другого веб-сервера, я на самом деле думаю, что вы должны придерживаться Apache. Он имеет очень разумную и мощную конфигурацию, и он достаточно быстр для всех ваших потребностей. В общем, Apache не особо медленный. Существуют веб-серверы, которые лучше подходят для встраиваемого использования, и есть веб-серверы, которые лучше подходят для максимально быстрой обработки большого количества статических страниц. Вам не о чем беспокоиться, пока вы не станете действительно большими.

1 голос
/ 04 января 2012

Вы настроили ваш application.conf с 

XForwardedSupport=127.0.0.1

и вашим apache.conf 

ProxyPreserveHost on

Альтернативный вариант, если он не работает, из предыдущего поста.*

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

как использовать "war.context" в файле конфигурации Play Framework?*

По сути, это означает чтение некоторого значения из файла свойств и предварительное ожидание этого значения для всех ваших маршрутов.Это рекомендуемый метод развертывания сервлета, в котором путь отличается от того, который используется настройкой воспроизведения по умолчанию.

0 голосов
/ 27 марта 2012

Play 1.x поддерживает настройку "http.path".

Play 2.1-snapshot уже поддерживает параметр конфигурации «application.context», чтобы поместить контекст приложения в подкаталог.

Пожалуйста, проверьте этот коммит:

Разрешить корневой контекст с использованием параметра конфигурации [application.context].

...