FastCGI on IIS 7.0 Risman Adnan ISV Lead, Microsoft Indonesia 11/30/2017 FastCGI on IIS 7.0 Risman Adnan ISV Lead, Microsoft Indonesia rismana@microsoft.com http://geeks.netindonesia.net/blogs/risman © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

IIS 7.0 Core Architecture

IIS6 Architecture refresher Web garden (w3wp.exe) Application Pool (w3wp.exe) Worker Process ISAPI Extensions ISAPI Filters Worker Process ISAPI Extensions ISAPI Filters Worker Process ISAPI Extensions ISAPI Filters Svchost.exe Inetinfo.exe IIS Admin Service WWW Service (w3svc) Lsass.exe FTP Service Windows Authentication SMTP Service SSL metabase NNTP Service Winsock HTTPAPI User Kernel HTTP.SYS TCPIP.SYS

IIS7 Architecture overview Web garden (w3wp.exe) Application Pool (w3wp.exe) Worker Process ISAPI Extensions ISAPI Filters Worker Process ISAPI Extensions ISAPI Filters Worker Process ISAPI Extensions ISAPI Filters Managed Mods Managed Mods Managed Mods Configuration (applicationhost.config) Svchost.exe Inetinfo.exe IIS Admin Service WAS Lsass.exe FTP Service Windows Authentication WWW Service (w3svc) SMTP Service SSL IIS 7.0 was built on top of an already successful architecture, the configuration system in IIS 7.0 is significantly different than in previous versions of IIS, and builds on top of some (but not all) of the concepts of the .NET framework configuration system. Its scope spans across the entire web server platform (e.g. IIS, ASP.NET) and serves as the core of the all-new IIS 7.0 administration "stack". metabase NNTP Service Winsock HTTPAPI User Kernel HTTP.SYS TCPIP.SYS

IIS6 Request flow refresher Server is monolithic: cant extend core features cant remove core features cant add features Feature duplication between IIS and ASP.NET. Features limited due to position in pipeline. ASP.NET functionality not applied to IIS content types. w3wp.exe iiscore aspnet_isapi.dll handlers cgi static file Isapi exts IHttpModule Events url map begin req determine handler logging auth’c req custom errors auth’z req w3svc Svchost.exe compression resolve cache end req authentication handler map update req cache ISAPI Filter Notifications handler exec rel req state To understand some of the improvements IIS7 delivers, lets review the IIS6 architecture.   Overview: Mapping the out high-level components we have, kernel http driver, worker process activation and management service, and the server worker process The IISCore provides request processing services, such as authentication, caching, logging, and various protocol support functionality. Requests can be handled by mapping them to either the static file handler, or an external handler such as CGI, or an ISAPI extension. Low level ISAPI filter mechanism can be used to intercept all requests in several points during request processing. The server is monolithic. Request processing services are tightly integrated with the server core – cannot be removed, cannot be replaced with custom services. Following an ASP.NET request through the server pipeline we observe the following: Pipeline duality produces a lot of service duplication and overlap between IIS and ASP.NET pipeline, such as: url mapping, authentication, handler mapping. This means having to configure services in two different places and different ways, runtime overhead, loss of fidelity due to incompatibility and side effects. ASP.NET functionality limited due to position in the server pipeline. Always run after IIS counterparts, no way to hook into low level ISAPI notifications. This would frequently necessitate complex and expensive ISAPI filter development. Follow static request through the server. Separate pipelines result in the problem of not being able to apply all services to all content types. ASP.NET services cannot be applied to IIS content types (forms authentication for static files). ASP.NET mapped requests cannot get the benefit of IIS functionality, such as static file handler or ASP. url map log IHttpHandlers auth’c req Trace.axd PageHandler Pre-proc headers End net session http.sys

IIS7 Architecture W3wp.exe iiscore aspnet_isapi WAS w3svc http.sys Unified request processing pipeline. All services provided by self-contained modules Modules can be managed or native All services can apply to all requests Native or Managed Handlers iiscore Native Handler Managed IHttpHandler aspnet_isapi static file isapi ext *.aspx trace.axd IHttpModule Events handlers url map cgi static file Isapi exts Integrated pipeline begin req Native Module IHttpModule end auth’c req other native modules log other managed modules Determine handler update cache auth’z req WAS w3svc Svchost.exe Isapi filter notifications release state resolve cache end req execute handler url map log handler map update req cache pre-execute handler acquire state handler exec rel req state basic auth url auth’z IIS7 unifies the request processing pipelines of ASP.NET and IIS, to enable components developed in managed or native code to provide services with equal fidelity. Observation> Single request processing pipeline, with a superset of request processing stages . Observation> All functionality is factored out into modular components. Modules can be developed either using a new native API or the ASP.NET managed model. All IIS7 request processing functionality provided by either a managed or native module. You can decide what components are needed and add/remove them as necessary. Follow a request through. Observation> All services provided by modules can apply to all content types. Example: The application can define url access rules uniformly using url authorization, specifying them in terms of user roles that are obtained by the role manager module from a authorization role store in the backend. This authorization can be used to protect static content served by the static file handler, and CGI scripts. auth’c req End net session map handler digest auth resolve cache role mgr IHttpHandlers authorize Pre-proc headers windows auth Trace.axd forms auth *.aspx authenticate begin User Kernel http.sys Tcpip.sys

Integrated pipeline Unified request processing pipeline for both native and managed (ASP.NET) modules All modules can provide services for all content types. You can use ASP.NET forms authentication and url authorization to protect all content on the server You can develop an ASP.NET module to append custom headers to static file requests. Duplicate features unified You can configure authorization, caching, and custom errors in one place. Managed modules have full ordering flexibility Managed modules can be intermixed with native modules as desired The integrated pipeline model provided by IIS7.0 seeks to provide a unified view of the request processing pipeline, where both native and managed extensibility manifested as modules can execute side by side and can accomplish the same degree of functionality.   In the IIS7.0, the integrated pipeline presents a unified view. In this model, a request coming to IIS7.0 is processed in the single request pipeline, where both native and managed modules can provide request services with equal power. The request is then mapped to either a native or a managed handler. In this mode, the following scenarios are possible: ASP.NET Forms Authentication and Url Authorization can be used to provide internet ticket based authentication and access control for all resources on the server, including static files, CGI scripts, and ASP pages. (All services can apply to all content types). A custom managed request filtering module can deny requests before any other module sees the request, by being the first to run in BeginRequest. (Managed modules have ordering fidelity with native modules) A single custom errors configuration exists for a single native custom errors module. (Duplicate services unified). IIS7.0 allows each worker process to be configured independently for either Integrated or Classic pipeline mode allowing for backward compatibility for applications that are unable to run properly in Integrated mode. This can be configured via the normal management UI and makes the following changes in the applicationhost.config file: <system.applicationHost> <applicationPools> <add name="DefaultAppPool" /> <add name="Classic .NET AppPool" managedPipelineMode="Classic" /> <add name="AppPool2" managedPipelineMode="Integrated" /> <applicationPoolDefaults> <processModel identityType="NetworkService" /> </applicationPoolDefaults> </applicationPools> </system.applicationHost> Here we see that there are two application pools configured. The DefaultAppPool is inheriting its configuration from the applicationPoolDefaults section and the schema defaults which will cause it to run in Integrated pipeline mode under the NetworkService security context. The ‘Classic.NET AppPool’ will also run under the NetworkService context but will run in Classic pipeline mode. Note: you can also explicitly specify “Integrated” for managedPipelineMode

Module breakdown A full description of all IIS7 modules is covered in the following tables, they have been broken down in to groups based on functionality: Caching Modules Compression Modules Content Modules Authentication Modules Security Modules Logging & Error Modules Diagnostics Modules Development Modules IIS 7.0 Managed Modules

Development Modules Development technologies offered as to execute code from that platform Implements Managed Interfaces, etc. Module Name Description Resource Location IsapiModule Implements ISAPI Extension Server Functionality Inetsrv\isapi.dll IsapiFilterModule Implements ISAPI filter functionality Inetsrv\filter.dll CgiModule Executes CGI processes to build response output. Inetsrv\cgi.dll FastCgiModule Enables Fast CGI application frameworks like PHP be hosted on the IIS web server. inetsrv\iisfcgi.dll ConfigurationValidationModule Implements configuration validation, e.g. if an application runs in integrated mode but has handlers or modules declared in the system.web section. inetsrv\validcfg.dll ManagedEngine Connects the IIS core pipeline with the ASP.NET runtime and bridge between native and managed code in IIS 7.0 ..\Framework\v2.0.50727\webengine.dll

Hosting PHP on Windows

Options for Hosting PHP on IIS CGI FastCGI ISAPI Invokes a process for each request. Advantages Easy to Configure Stable Execution Disadvantages Slow due to I/O Overhead of Process Creation Extension to CGI allowing reuse of a process. Advantages Easy to Configure Faster than CGI More stable than PHP on ISAPI Loaded as extension in process. Advantages Better Performance Disadvantages Many PHP Applications are not Thread-Safe

FastCGI for IIS6 Same FastCGI functionality as in IIS7, available as a separate download for IIS6 from the Microsoft download center http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1521 Fully supported by Microsoft Walk-throughs demonstrating how to run popular PHP applications on Windows Server See http://www.iis.net/php Close collaboration with Zend Technologies Improvements in PHP engine for IIS with contributions and collaboration back to PHP Community Zend Core Available for Commercially Supported PHP

FastCGI in IIS6 and IIS7 FastCGI in IIS6 FastCGI in IIS7 Available today on Download Center Available with Windows Server 2008 and Vista SP1 Delivered as a separate download from Windows Server 2003. Delivered as part of IIS7. Users must install the CGI feature in IIS to enable FastCGI. ISAPI extension Native IIS7 module Resources, forums, and reference material available on IIS.NET Product help documentation, as well as resources on IIS.NET. Configured via fcgiext.ini Configured via the new XML-based configuration system in IIS7. Fully supported by Microsoft Supports PHP and other FastCGI frameworks

Advantages of PHP on IIS7 Modular architecture for reduced attack surface XML-based configuration system Remote management capability Advanced diagnostics Integration with WMS and Media Pack Ability to extend IIS7 using managed code PHP users who deployed to Apache in the past will be more comfortable with IIS7 than IIS6 due to the new configuration system and modular architecture.

FastCGI on IIS 7.0

FastCGI Design Goals What is FastCGI : A language and server independent, scalable, open extension to CGI that provides high performance and persistence A protocol for data interchange between a web server and a FastCGI application The set of libraries that implement the protocol Developed by Open Market in 96 as open solution Design goals: Speed! Eliminate CGI’s weaknesses Scalable Persistent Build on CGI’s strengths Simple, Open Standard with an easy migration path Server, Language, & OS independent Server Isolation Of course, the motivating factor behind the development of FastCGI was speed. Allowing CGIs to run on backend machines was important. CGI has some really good traits.. Want to keep those and dump the bads without adding unnecessary complexity. Easy to migrate from CGI. Web hosts want a solution that is isolated from the rest of their customers. The ability to make use of other computing resources without having to manage them as directly exposed to the Internet. Persistence from two angles, process persistence and data persistence.

FastCGI Handler Architecture FastCGI process pool for PHP5 IIS Worker Process FastCGI handler ASP.NET Static FastCGI protocol over named pipes or TCP Read Configuration Authenticate Authorize Map Request Handle Request Send Response Log Request php-cgi.exe FastCGI process pool for PHP4 Request queue php.exe

FastCGI Handler 1 : Receiving requests in IIS WP 2 : Queieing requests 3 : Dispacthing and receiving response from FastCGI process 4 : Creating one or more FastCGI App Process Its operation roughly breaks down into following actions: Receiving requests in the IIS worker process (1) Creating one or more FastCGI application processes (4) Dispatching each request to one of the FastCGI application processes over a named pipe or TCP socket using the FastCGI protocol (3), and receiving a response from the FastCGI application process Queueing requests when the maximum number of FastCGI application processes has been reached, and each is already processing a request. (3)

FastCGI Handler Mapping the FastCGI handler to process requests Processing all URLs in a directory Response buffering 64 bit support Process Management Create configured FastCGI application processes when needed. Maintain a connection with each FastCGI application process during its lifetime Monitor health of FastCGI application processes Periodically recycle FastCGI processes Detect when FastCGI processes exited / crashed, and recover gracefully Terminate FastCGI processes Queuing and request dispatching Security model

FastCGI Protocol Support Initialization Request processing FastCGI Roles Error handling Errors during FastCGI handler initialization Errors during application initialization Request processing errors Rapid Failure Protection

FastCGI Roles Responder Authorizer Filter The fundamental FastCGI role Functionally identical to CGI Supported by all FastCGI capable servers Authorizer Provides a means of controlling access to a site, a page, or something in between Typically, this involves some form of authentication, but this isn’t required It has server dependent significance Filter Allows “processing” of a file before it is sent Intended to support: Format conversions Dynamic documents (embedded code) Applying templates: e.g. headers, footers, backgrounds Conceptually this could support dynamic content chaining, but without server support has limited utility The spec describes 4 roles. The Filter Role conceptually allows the chaining of dynamic content. There’s also a Logger role that isn’t described in the documentation, but mentioned in the headers. It allows for colocating logging –there’s better solutions like piped logs under Apache.

11/30/2017 © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

FastCGI Application Process The FastCGI application process uses a FastCGI communication library to communicate via a transport mechanism to the calling process. On Windows, many application frameworks use the LibFcgi library from http://www.fastcgi.com/. The FastCGI application library typically supports the following transport mechanisms to the creating server: Named Pipes (PHP, Ruby, Perl) TCP (Python)

FastCGI Protocol All data is wrapped in the protocol A simple standard header precedes every Protocol Data Unit (PDU) The header describes the type of data and its length PDU Types Begin Request Name-Value Stream Stdin Stream Stdout Stream Stderr Stream End Request Reserved Padding Length Content Length Request Id PDU Type Protocol Version The Padding field allows the data alignments to be maintained at 8 byte boundaries for efficiency. = one byte

Typical PDU Flow - To FastCGI Application Begin To FastCGI Application NV {X} NV Data ... NV {0} Stdin {X} Stdin Data ... Stdin {0}

Typical PDU Flow - From FastCGI Application Stdout {X} Stdout Data To Web Server ... Stderr {X} Stderr Data Stdout {X} Stdout Data Stdout {0} Stderr {0} End