[РЕШЕНО] Вебсервер: логика маршрутизации

[alexis031182]

День добрый

Пишу Вебсервер. Знаю про велосипеды, но у меня чисто академический интерес, поэтому прошу воздержаться от соответствующих комментариев. К делу...

Идея моего вебсервера исключает использование каких бы то ни было интерпретаторов на своей стороне (да, знаю, что это не ново). Сайты будут на С++, и будут подключаться (динамически) в виде плагинов. Конечно HTML и Javascript будут передаваться клиентам. Просто идея в замене того же PHP на C++. Резон - скорость.

Однако тут имеется подводный камень, заключающийся в том, что, например, пыхпых так или иначе привязан к конкретным файлам скриптов, они... э-э-э... как точки входа. В случае же с C++ таковое не получается. Файлы, являющиеся точками входа не существуют. Их заменяет, по сути, вызов функции из динамически подключаемой библиотеки. Однако, файловые ресурсы всё же могут быть. Например, совершенно ни к чему хранить в файле-библиотеке (dll-ке) сайта картинки или видеоролики. Создатель сайта просто закидывает такие файлы в выделенную этому сайту папку и может быть уверен, что те будут переданы клиенту на его соответствующий запрос.

Мой вопрос относится к той ситуации, когда запрос клиента может содержать указание на файловый ресурс (например "/favicon.ico", который непременно автоматом отсылается тем же Google Chrome), но такового файла в папке сайта может и не быть. И как тут лучше поступить? Выдать "Not Found"? Или передать запрос по цепочке от сервера сайту, и тот, мол, пусть сам разбирается с этой проблемой? Но тогда получается, что необходимо делегировать сайту права на выставление статуса ответа, поскольку уже автомат сайта сам может придти к выводу, что "Not Found" - лучший ответ. Корректно ли это решение? А может быть есть ещё какие-либо варианты поведения в рассмотренной ситуации?

[Bepec]

Делать то же самое, что делает и нормальный сервер. Выдать пустую картинку, если нет файла. Или ты хочешь что - то другое придумать?

[V1KT0P]

Сайты будут на С++, и будут подключаться (динамически) в виде плагинов.

Ты собираешься какой-то готовый C++ фреймворк использовать? Или что-то свое писать собрался?

[alexis031182]

Делать то же самое, что делает и нормальный сервер. Выдать пустую картинку, если нет файла. Или ты хочешь что - то другое придумать?

Картинка - просто пример, с видеофайлом... э-э-э... выдать пустой видеофайл? Речь не об этом. Вопрос заключался в том, на чьей стороне (сервера или сайта-плагина) лучше, оптимальнее оформлять ответ на означенную ситуацию. Ведь может случиться, что сайт приемлет запросы на несуществующие ресурсы (файлы, страницы) за счёт заранее сформированных правил перенаправления (в Apache - это .htaccess). А может и не приемлет...

[alexis031182]

Ты собираешься какой-то готовый C++ фреймворк использовать? Или что-то свое писать собрался?

Полностью своё, поскольку есть интерес именно с нуля. Знаю, что существуют подобные проекты (один даже где-то в закладках имеется), но не хочу тянуть в проект ничего другого, кроме Qt.

[alexis031182]

Да, если кому-нибудь нужно соответствия маймтипов файловым расширениям, то в аттаче приложил xml, собранные с апачевского mimetypes файла. Знаю, что парсится исходник легко, но может xml для собственных задач кому-нибудь сгодится

[Bepec]

В любом случае будет идти запрос на сервер. В любом случае будет проверка. И тут уже вопрос третий - что выдавать вместо несуществующих.

А так по идее, конечно же сервер должен проверять и отдавать файлы. Хотя на вкус и цвет все шмели разные

[alexis031182]

В любом случае будет идти запрос на сервер. В любом случае будет проверка. И тут уже вопрос третий - что выдавать вместо несуществующих.

Вот я и подошёл к этому третьему моменту вплотную.

А так по идее, конечно же сервер должен проверять и отдавать файлы. Хотя на вкус и цвет все шмели разные

Да, этому следую, но вопрос с несуществующими файлами пока нерешён у меня. Как определить, что запрос клиента указывает не на несуществующий файл на диске, а просто на динамически формируемую страницу? По наличию расширения файла в запросе? Тогда разработчику сайта придётся следовать негласному правилу, что динамически формируемые страницы не должны в своём наименовании выглядеть как наименования файлов... Другими словами символ точки содержать... Или типа того... Иначе до сайта запрос не дойдёт, сервер будет отсылать "404 Not Found". Какое-то левое правило, и очень хотелось бы извратиться как-нибудь по-другому.

[V1KT0P]

Да, этому следую, но вопрос с несуществующими файлами пока нерешён у меня. Как определить, что запрос клиента указывает не на несуществующий файл на диске, а просто на динамически формируемую страницу? По наличию расширения файла в запросе? Тогда разработчику сайта придётся следовать негласному правилу, что динамически формируемые страницы не должны в своём наименовании выглядеть как наименования файлов... Другими словами символ точки содержать... Или типа того... Иначе до сайта запрос не дойдёт, сервер будет отсылать "404 Not Found". Какое-то левое правило, и очень хотелось бы извратиться как-нибудь по-другому.

Я не могу понять что тебя ставит в тупик? Твой сервер получает запрос, согласно своему правилу разбирает запрос и выполняет его. Тут проще пример привести. К примеру выполняется такой запрос: site.com/somequery для начала ищется файл в директории сайта и если не обнаруживается то передается на разбор в данном случае вычленяется somequery. Далее передается управление плагину который зарегистрировал запрос somequery. Если ни один плагин не регистрировал, то тупо 404 вощвращай. Если регистрировал то он и должен решать что возвращать.

[alexis031182]

Я не могу понять что тебя ставит в тупик? Твой сервер получает запрос, согласно своему правилу разбирает запрос и выполняет его. Тут проще пример привести. К примеру выполняется такой запрос: site.com/somequery для начала ищется файл в директории сайта и если не обнаруживается то передается на разбор в данном случае вычленяется somequery.

Ну вот банальный пример с иконкой в Google Chrome:
1. шлётся запрос "site.com/" - тут всё понятно, сайт, если в нём предусмотрен контроллер по умолчанию (а это как правило так и есть) корректно отработает.
2. тут же браузер автоматом шлёт второй запрос (может даже не дожидаться ответа на первый, стандартом это разрешено) "site.com/favicon.ico" - и вот что произойдёт в этом случае, если передать этот запрос сайту? Он его отработает также, как и  первый запрос, то есть второй раз сработает контроллер по умолчанию, и будет снова отправлена, например, главная страница сайта. Это плохо.

Конечно ситуацию эту на стороне сайта можно обойти. Написать там правила соответствующие, но мне бы хотелось именно на уровне сервера исключить подобное, чтобы создатель сайта не заморачивался по данной теме (вообще, по идее, его это не должно касаться).

Далее передается управление плагину который зарегистрировал запрос somequery.

У меня сайты не регистрируют ничего на сервере. Я стараюсь добиться минимума вариантов взаимодействия. Каждый запрос отправляется конкретному сайту. Определение соответствия производится от имени хоста. Просто в конфигурационном файле пишем, какие хосты/доменные имена "слушает" сайт.

Если ни один плагин не регистрировал, то тупо 404 вощвращай. Если регистрировал то он и должен решать что возвращать.

Вот здесь и получается, что если сервер ничего о внутренностях сайтов не знает (и это желательно сохранить), то обработку того, относится ли запрос к файлу или динамической странице становится определить проблематично. Если ничего не получится придумать, то наверное придётся на стороне сервера проверять, является ли запрос на файл (по наличию файлового расширения), и если нет, то отправлять запрос сайту.

[Bepec]

Ну как бе, насколько я знаю, стандарт состоит в хранении иконок /файлов и прочего в одном(паре) мест, для одного сайта.

Не вижу в этом ничего плохого. А далее стандартный разбор, как тебе говорит Виктор.

PS у тебя сейчас вопрос стоит простой:
Я хочу, чтобы клиент запрашивал о чём то сервер, а сервер, в свою очередь запрашивал плагины, а плагины в свою очередь запрашивали файл (мп3, ико, несуществующий фал, нужное подчеркнуть), а далее плагин отправлял серверу, а сервер отправлял клиенту. Не?

[V1KT0P]

Ну вот банальный пример с иконкой в Google Chrome:
1. шлётся запрос "site.com/" - тут всё понятно, сайт, если в нём предусмотрен контроллер по умолчанию (а это как правило так и есть) корректно отработает.
2. тут же браузер автоматом шлёт второй запрос (может даже не дожидаться ответа на первый, стандартом это разрешено) "site.com/favicon.ico" - и вот что произойдёт в этом случае, если передать этот запрос сайту? Он его отработает также, как и  первый запрос, то есть второй раз сработает контроллер по умолчанию, и будет снова отправлена, например, главная страница сайта. Это плохо.

Конечно ситуацию эту на стороне сайта можно обойти. Написать там правила соответствующие, но мне бы хотелось именно на уровне сервера исключить подобное, чтобы создатель сайта не заморачивался по данной теме (вообще, по идее, его это не должно касаться).

У тебя проблемы на ровном месте. К примеру ставим nginx как фронтенд, при site.com/favicon.ico если в директории есть иконка он ее возвращает если нету, то передает твоему серверу, твой сервер уже по твоим правилам решает что делать.

У меня сайты не регистрируют ничего на сервере. Я стараюсь добиться минимума вариантов взаимодействия. Каждый запрос отправляется конкретному сайту. Определение соответствия производится от имени хоста. Просто в конфигурационном файле пишем, какие хосты/доменные имена "слушает" сайт.

Ну вот конфигурационный файл и играет роль регистратора.

Вот здесь и получается, что если сервер ничего о внутренностях сайтов не знает (и это желательно сохранить), то обработку того, относится ли запрос к файлу или динамической странице становится определить проблематично. Если ничего не получится придумать, то наверное придётся на стороне сервера проверять, является ли запрос на файл (по наличию файлового расширения), и если нет, то отправлять запрос сайту.

Снова проблема на ровном месте. Если есть файл по указанному пути, то отдаем этот файл. Если нету то передает твоему серверу, если нет обработчика запроса то возвращаем 404, если обработчик есть то передаем ему. Если он решает что получил невалидный запрос то возвращает 404, если валидный то результат. В чем проблема-то?

[alexis031182]

Ну как бе, насколько я знаю, стандарт состоит в хранении иконок /файлов и прочего в одном(паре) мест, для одного сайта.

Для каждого сайта всё индивидуально будет. Взять для аналогии всяческие PHP фреймворки. Картинки расположены как Бог пошлёт, и тот же Апач не ведает что к чему, пока очередной запрос не заставит его смотреть конкретные папки-файл на присутствие соответствующей картинки. У Апача нет проблемы в определении из запроса, что есть файл, а что - страница. Он работает исключительно с файлами (ну если только в .htaccess не начать писать перенаправления, но, правда, всё равно на файлы). У Апача например, если запрос касается PHP динамической страницы, всё равно точка входа файлом является. У меня же этого нет. Отсутствует чёткое определение, что есть файл на диске, а что есть страница.

Не вижу в этом ничего плохого. А далее стандартный разбор, как тебе говорит Виктор.

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

PS у тебя сейчас вопрос стоит простой:
Я хочу, чтобы клиент запрашивал о чём то сервер, а сервер, в свою очередь запрашивал плагины, а плагины в свою очередь запрашивали файл (мп3, ико, несуществующий фал, нужное подчеркнуть), а далее плагин отправлял серверу, а сервер отправлял клиенту. Не?

Нет. Вопрос в том, как сервер может отличить адрес файла от адреса динамически формируемой в плагине сайта страницы даже в том случае, если запрашиваемого файла не существует.

[alexis031182]

У тебя проблемы на ровном месте. К примеру ставим nginx как фронтенд, при site.com/favicon.ico если в директории есть иконка он ее возвращает если нету, то передает твоему серверу, твой сервер уже по твоим правилам решает что делать.

Можно и так конечно, но этот вариант мне не нравится. Ради простейшей в общем-то ситуации...

Ну вот конфигурационный файл и играет роль регистратора.

Регистратора соответствия хостов сайтам - да. Но не запросов. Хост - составная часть в запросе.

Снова проблема на ровном месте. Если есть файл по указанному пути, то отдаем этот файл. Если нету то передает твоему серверу, если нет обработчика запроса то возвращаем 404, если обработчик есть то передаем ему. Если он решает что получил невалидный запрос то возвращает 404, если валидный то результат. В чем проблема-то?

То есть делегировать плагинам возможность устанавливать статус ответа? Этот вариант мне понятен, он вроде как сам собой напрашивается, но мне не хочется передавать таковые полномочия плагинам. В Апаче, вроде, этого нет. Заголовки там всякие - это пожалуйста, а вот статус... Да и ситуация с иконкой говорит о том, что могут возникнуть всяческие недоразумения, что приведёт к снижению производительности. То есть подобные вещи, по идее, не должны касаться сайта. Он там у себя колупается в своей песочнице, и не особо лезет на сервер. Это было бы гут.

[alexis031182]

Пожалуй остановлюсь на парсинге имени файла из запроса. Если имеется файловое расширение - значит файл. Если же нет - кидаю запрос плагину, который сформирует страницу. Конечно это наложит ограничение на имена страниц - они не должны будут точку содержать (например, site.com/documents/main.document). Из такого запроса сервер решит, что это файл на диске, а не страница. Ёк-королёк... а ещё ведь могут быть и динамически формируемые картинки (аналогия imagick на пыхпыхе). Тоже плохо