Кто-нибудь когда-нибудь пытался реализовать веб-сервер?Или знаете что-нибудь о недоделке работающей программы веб-сервера?Мне интересно, что происходит именно с того момента, когда веб-сервер получает URL-адрес, чтобы файл на веб-сервере находился и отправлялся обратно в качестве ответа.
Сохраняет ли сервер только внутреннюю таблицу, чтобы запомнить сопоставление междуURL-адреса, которые он поддерживает, и соответствующие локальные пути?Или есть что-нибудь более хитрое?
Спасибо!
Обновление
Спасибо за ваши ответы.Вот мое понимание на данный момент.
Я проверил с помощью Microsoft IIS (Internet Information Service), я заметил, что IIS может разместить несколько сайтов, и каждый сайт IIS запоминает его корневой путь в локальной файловой системе.Разные сайты на одном и том же хосте имеют одно и то же имя или IP-адрес и различаются по разным портам.Например:
http://www.myServer.com:1111/folderA/pageA.htm
Веб-сервер будет использовать www.myServer.com: 1111 часть строки URL, чтобы определить, какой путь в его локальной файловой системе будет использоваться, а затемв этом локальном пути он ищет подпапку folderA , а затем файл pageA.htm .
Веб-сервер только необходимо запомнитьследующее отображение между двумя простыми строками:
"http://www.myServer.com:1111/" <---> "D:\myWebRoot"
Я не знаю, где хранится такая информация отображения, возможно, некоторые файлы конфигурации для рассматриваемой Программы веб-сервера.
Но результатом этого сопоставления granularity является то, что мы можем получить доступ только к контенту в этой сопоставленной локальной папке.Мы не могли выполнить произвольное сопоставление.
Обновление - 2 -
Я нашел, где IIS хранит сопоставление, вот несколько цитат из applicationHost.config:
<sites>
<site name="Default Web Site" id="1" serverAutoStart="false">
<application path="/">
<virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:80:" />
<binding protocol="net.tcp" bindingInformation="808:*" />
<binding protocol="net.pipe" bindingInformation="*" />
<binding protocol="net.msmq" bindingInformation="localhost" />
<binding protocol="msmq.formatname" bindingInformation="localhost" />
</bindings>
</site>
<site name="myIISService" id="2" serverAutoStart="true">
<application path="/" applicationPool="myIISService">
<virtualDirectory path="/" physicalPath="D:\MySites\MyIISService" />
</application>
<bindings>
<binding protocol="http" bindingInformation="*:8022:" />
</bindings>
</site>
<siteDefaults>
<logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
<traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
</siteDefaults>
<applicationDefaults applicationPool="DefaultAppPool" />
<virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>
Обновление - 3 -
После того, как я прочитал ответ foo , мой недостаток "сервера" увеличился.Я хочу сделать некоторые комментарии, основанные на моем недавнем изучении WCF.
Независимо от того, какой это сервер, мы всегда можем отправлять им сообщения, указывая протокол, URL, порт.Например:
[http://www.myserver.com:1111/]page.htm
[net.tcp://www.myserver.com/]someService.svc/someMethod
[net.msmq://www.myserver.com/]someService.svc
[net.pipe://localhost/]
После того, как сообщения поступят в серверную программу с использованием частей в квадратных скобках вышеуказанных URL-адресов, остальная часть URL будет отправлена серверной программе в качестве входных данных.для дальнейшей обработки.И следующее поведение может быть таким же простым, как подача статического контента, или сложным, как генерация динамического контента.