Как дела с интернет-магазином в 2012 R3?

[Narayana]

Цитата:

Сообщение от ax_mct

Я не просто крут, а очень крут. На меня еще в 2003 году работодатели с .NET в очередь выстраивались чтобы просто на меня посмотреть И я даже знаю что такое веб-сервис

Обожаю людей без ложной скромности

Цитата:

Насколько я понял вопрос и потребность. web.config приложения секция <handlers> (если IIS 7 и выше).

...не, не, не...
всю эту лабуду я перечитал вдоль и поперек.
Вопрос не в том, что есть модули, хандлеры и маппинг.
Это все хоть и криво, но описано. Не описано самое интересное.
Вот у вас запрос от браузера пришел на конвейер IIS и ASP.NET...
Этот запрос последовательно обрабатывается родными и управляемыми модулями, а потом доходит до хандлера, который и рождает ответ браузеру в http виде. А маппинг позволяет вам указать какие типы файлов какими хандлерами обрабатываются.
Также в конфиге вы можете добавить свои модули или хандлеры, которые также будут грызть запросы и возвращать html в том виде, который вам нравится.
Но, я не об этом.
А о том порядке, в котором модули грызут запрос.
Нетути никакого документа, где этот порядок определяется.
Нет его даже в applicationHost.config, а в схеме построения самого конфига IIS_schema.xml нет и намека на его присутствие.

А как же тогда гибкость и настраиваемость IIS-а?
Если логика запуска модулей зашита в IIS программно, то где эта логика хотя бы описывается?
Возможно, сначала запускаются модули по умолчанию включенные в IIS, а затем уже пользовательские, но я пока не нашел. Вот и спрашиваю, может вы знаете?

Есть замечательное видео, где автор очень хорошо обобщил информацию про IIS и представил в человеческом виде http://www.youtube.com/watch?v=XKpJuTAJX1g
При этом он даже заикнулся про порядок вызова модулей, но как-то смущенно сказал, что сервер сам определяет последовательность. Сдается мне, он просто не знает...

[ax_mct]

Цитата:

Сообщение от Narayana

...А о том порядке, в котором модули грызут запрос.
…про порядок вызова модулей

IIS Pipeline
http://blogs.msdn.com/b/tmarq/archiv...onditions.aspx

BEGIN_REQUEST
AUTHENTICATE_REQUEST
AUTHORIZE_REQUEST
RESOLVE_REQUEST_CACHE
MAP_REQUEST_HANDLER
ACQUIRE_REQUEST_STATE
PRE_EXECUTE_REQUEST_HANDLER
EXECUTE_REQUEST_HANDLER
RELEASE_REQUEST_STATE
UPDATE_REQUEST_CACHE
LOG_REQUEST
END_REQUEST

ASP.NET request-processing stages
http://www.iis.net/learn/application...ation-with-iis

Заметка 1: Integrated mode allows both managed and native modules to register for events in the IIS pipeline.
Заметка 2: Think of ASP.NET in classic mode as a pipeline within a pipeline.

BeginRequest. The request processing starts.
AuthenticateRequest. The request is authenticated. IIS and ASP.NET authentication modules subscribe to this stage to perform authentication.
PostAuthenticateRequest.
AuthorizeRequest. The request is authorized. IIS and ASP.NET authorization modules check whether the authenticated user has access to the resource requested.
PostAuthorizeRequest.
ResolveRequestCache. Cache modules check whether the response to this request exists in the cache, and return it instead of proceeding with the rest of the execution path. Both ASP.NET Output Cache and IIS Output Cache features execute.
PostResolveRequestCache.
MapRequestHandler. This stage is internal in ASP.NET and is used to determine the request handler.
PostMapRequestHandler.
AcquireRequestState. The state necessary for the request execution is retrieved. ASP.NET Session State and Profile modules obtain their data.
PostAcquireRequestState.
PreExecuteRequestHandler. Any tasks before the execution of the handler are performed.
ExecuteRequestHandler. The request handler executes. ASPX pages, ASP pages, CGI programs, and static files are served.
PostExecuteRequestHandler
ReleaseRequestState. The request state changes are saved, and the state is cleaned up here. ASP.NET Session State and Profile modules use this stage for cleanup.
PostReleaseRequestState.
UpdateRequestCache. The response is stored in the cache for future use. The ASP.NET Output Cache and IIS Output Cache modules execute to save the response to their caches.
PostUpdateRequestCache.
LogRequest. This stage logs the results of the request, and is guaranteed to execute even if errors occur.
PostLogRequest.
EndRequest. This stage performs any final request cleanup, and is guaranteed to execute even if errors occur.

ASP.NET Application Life Cycle Overview for IIS 7.0
http://msdn.microsoft.com/en-us/libr...v=vs.100).aspx

Execution order of modules in IIS7
http://www.ksingla.net/2006/06/execu...dules_in_iis7/
http://www.iis.net/learn/application...ation-with-iis

Думаю что для вас самое интересное это

Цитата:

If multiple modules subscribe to the same event and set the same priority, the module that is listed first in the system.webServer/modules section gets executed first. RQ_EXECUTE_REQUEST_HANDLER is different in this respect as it picks up the ordering from system.webServer/handlers section. Taking the example of StaticFile handler entry from default IIS configuration which looks like the following

<add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />

IIS picks one handler for a request but each entry can have multiple modules executed which can appear as comma separated list as is the case for StaticFile handler. StaticFileModule, DefaultDocumentModule and DirectoryListingModule, all three subscribe to RQ_EXECUTE_HANDLER and use default priority. The default ordering of these modules is important to ensure they work correctly.

Ссылки далеко не все "официальные" но на мой взгляд информация корректна.

[Narayana]

Цитата:

Сообщение от ax_mct

IIS Pipeline

Кажется, немного разобрался.
Когда читаешь, нужно все время понимать, где находишься... в конвейере IIS, конвейере приложения или конвейере страницы.
Пожалуй, именно непонимание этого вызывало у меня бурные эмоции.
Сейчас полегчало