Как уже указывалось, Nginx не подходит для создания HTML-документов сам по себе. Обычно это работа для серверного языка обработки, такого как PHP или Perl. Однако есть несколько способов решения проблемы исключительно с помощью Nginx.
Первым очевидным выбором было бы использовать серверный язык обработки из Nginx. Существует, по меньшей мере, три дополнительных модуля для трех разных языков (Perl, Lua и диалект Javascript), которые могут быть использованы для этого.
Проблема с этим подходом заключается в том, что эти модули редко доступны по умолчанию, и во многих случаях вам придется создавать Nginx вручную, чтобы включить любой из них. Иногда это может быть болезненно, потому что, как только вы получите свою собственную сборку Nginx, вам придется самостоятельно ее поддерживать и обновлять.
Существует, однако, еще один вариант, который включает в себя SSI. Это может быть не самое приятное решение, но оно будет работать. И в отличие от вышеупомянутых модулей, поддержка SSI поставляется практически с каждым дистрибутивом Nginx. Моя ставка заключается в том, что ваш Nginx может сделать SSI из коробки без необходимости компилировать что-либо.
Таким образом, конфигурация выглядит следующим образом:
# Define a special virtual location for your cpp files
location ~* \.(cpp|h)$ {
# Unless a GET parameter 'raw' is set with 'yes'
if ($arg_raw = 'yes') {
break;
}
# Redirect all the requests for *.cpp and *.h files to another location @js
try_files @js @js;
}
location @js {
ssi on; # Enable SSI in this location
default_type text/html; # Tell the browser that what is returned is HTML
# Generate a suitable HTML document with an SSI insertion
return 200 '<!DOCTYPE html>
<link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.9.0/styles/default.min.css">
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.9.0/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>
<pre><code class="cpp"><!--# include virtual="$uri?raw=yes" --></code></pre>';
}
Теперь вот что происходит, если вы запрашиваете некоторые * .cpp файл в браузере:
- Запрос идет на первом месте, потому что URI заканчивается
cpp.
- Затем он перенаправляется во второе место
@js, потому что в вашем запросе нет параметра GET raw.
- Во втором месте шаблон SSI генерируется return, а затем немедленно обрабатывается двигателем SSI из-за
ssi on.
include virtual="$uri?raw=yes" указывает механизму SSI сделать другой запрос (подзапрос) из Nginx в первоначально запрошенный файл (внутренняя переменная $uri хранит исходный URI, то есть веб-путь к вашему файлу cpp). Разница между запросом вашего браузера и подзапросом, сделанным Nginx, - ?raw=yes.- Подзапрос снова обрабатывается первым местоположением, но он никогда не переходит ко второму из-за параметра GET
raw. В этом случае исходное содержимое файла cpp возвращается как ответ на подзапрос.
- Механизм SSI объединяет этот ответ с остальной частью шаблона и возвращает результат браузеру.Кроме того, default_type сообщает браузеру, что он отображает результат как документ HTML.
Вы можете увидеть пример вывода here. Я использовал this подсветку библиотеки для этого примера. Вы можете изменить его с помощью того, что вы предпочитаете, просто изменяя шаблон SSI.
Хотя, вероятно, это может быть сделано с помощью веб-сервера, обычно это не так. Вместо этого обычно это зависит от структуры или системы доставки контента. –
На сервере нет рамки доставки контента. Для просмотра файлов работает только fancyindex. – Hoszy
Nginx сам не может делать синтаксис hilighting, вы должны либо использовать язык на стороне сервера, как PHP, чтобы служить html-файлу с синтаксическим hilight или использовать js-плагин для hilight на стороне клиента. –