[Mono-dev] Patch for HttpRuntime and HttpServerUtility to bring API in sync with .NET 2.0 SP2

Thu Sep 24 14:32:10 EDT 2009

Nick Berardi wrote:
> Hi Marek,
Hello,

> I am a little hesitant to to implement this for Mono for the following 
> reasons. 
> 
> /Number 1/ is the description Microsoft provides for it
> "Gets a value that indicates whether the current application is running 
> *in the integrated-pipeline mode of IIS 7.0*."
You can ignore this particular part of the description. As I wrote in the previous mail, Mono 
effectively implements what was introduced in IIS 7 and termed "integrated-pipeline mode". Therefore 
it's perfectly fine to implement that in Mono.

> /Number 2/ is that the key feature of the integrated-pipeline is that 
> outside processes still run through the .NET framework first, such as, 
> you can use IHttpModules to process request/response data from for 
> example PHP code, I don't know enough about Mono/XPS to get something 
> like this working. 
XSP doesn't implement that and it doesn't have to, it's just a development server. Apache, otoh, 
provides a full filter/pipelining infrastructure with which Mono should work just fine (i.e. you can 
define a module to act as a filter and pass its output to another module, etc etc) - I have never 
tried it, but I mod_mono is no different to other modules and it should work just fine. It will NOT 
use IHttpModules, of course, because Apache (being IIS counterpart) doesn't have that notion, but 
functionality is exactly the same. We might (just might) approach it at some point and extend 
mod_mono (or create an auxiliary module) in the way which will expose IHttpModules etc to Apache, 
but it's definitely not a priority. Mono/mod_mono/XSP is much more flexible than .NET + IIS combo, 
so the elements are more losely coupled but they can be arranged to work in the same way as IIS.

> Many developers use the UsingIntegratedPipeline flag to indicate if they 
> are running in IIS 7.0 integrated mode or the older "classic mode."  I 
> really feel that getting both the "classic mode" and integrated mode 
> working under Mono would be a huge undertaking, especially in regards to 
> some of the built in support for their Rewriter Module that they have 
We don't have to aim for 1:1 compatibility in this regard - Apache has rewriter modules which can 
easily replace their IIS counterpart, and we do not aim to make Mono a replacement for .NET under 
IIS. Therefore, if a developer deploys an ASP.NET application to Mono/Apache/mod_mono they should be 
aware of architectural differences. But, again, that doesn't stop us from supporting the APIs (and 
other "integrated pipeline" ones) for the benefit of applications and developers.

> added in to the .NET 2.0 SP2 framework.  Also because a number of 
> sub-routines change in ASP.NET <http://ASP.NET> depending on this one 
> flag. 
Nothing prevents us from defaulting to false for UsingIntegratedPipeline and providing a mechanism 
to turn it on (by e.g. providing a MonoServerEnableIntegratedPipeline AppSettings entry - we already 
have a number of them, documented in the xsp and mod_mono manpages)

> I would like to commit the patch as is for now, to complete some of the 
> missing parts of the API, and I will look in to what it will take to 
> really get this supported in the Mono framework. 
What the patch generally does is provide stub implementations of the API (with, perhaps, the 
exception of the property) which we don't generally like to do, especially if the functionality is 
relatively easy to implement as in this case. I'd rather vote on not commiting the patch in this 
state, but rather wait till you (or somebody else, perhaps even me) provides full support for the 
APIs together with tests etc.

best regards,

marek

> Thanks,
> Nick
> 
> P.S. I know of a dozen places where having integrated mode turned on 
> will allow you to do things that you weren't allowed to before.  For 
> example when integrated mode is enabled you can directly add headers 
> using /HttpRequest.Headers.Add/, instead of getting an exception thrown.
You can do it just fine with Mono as well. As said before, we treat Mono as working in the 
integrated pipeline mode. There's nothing wrong in not having full support for all of its features 
right away, we can implement it step by step.


> 
> On Thu, Sep 24, 2009 at 4:56 AM, Marek Habersack 
> <grendel at twistedcode.net <mailto:grendel at twistedcode.net>> wrote:
> 
>     Nick Berardi wrote:
> 
>         Hello group,
> 
>     Hello,
> 
> 
>         This is my first time submitting a patch.  So if anything I have
>         done is out of the norm, please let me know so that I can
>         correct it.  
>         There are two API's related to IIS 7.0 that were added as part
>         of the .NET 2.0 SP2 release that I need supported for an Open
>         Source project that I work on (http://urlrewriter.codeplex.com).
>          (http://urlrewriter.codeplex.com/WorkItem/View.aspx?WorkItemId=7187)
> 
>         The patch that I am submitting is for the following APIs:
> 
>            * HttpRuntime.UsingIntegratedPipeline { get; }
>            *
>         HttpServerUtility.TransferRequest(string,[bool],[string],[NameValueCollection])
> 
>         Since both of these API's are IIS 7.0+ specific and that they
>         require the Integrated Pipeline to function.  I have the first
>         property UsingIntegratedPipeline always returning false, since
>         it is currently impossible to put Mono in to the core of IIS
>         7.0, so Integrated Pipeline
> 
>     Technically Mono has always been using what IIS 7 calls "integrated
>     pipeline" - there are no plans to make Mono run in the IIS core, so
>     we should try to implement whatever functionality makes sense in
>     Mono context without looking whether or not it works in this or that
>     IIS mode. I'd say UsingIntegratedPipeline could return 'true'
>     without harm.
> 
> 
>         can't currently be supported.  So I hoped to achieve the 2nd
>         best option of API completeness.  The second method
>         TransferRequest relies on the Integrated Pipeline so again it
>         will not be supported.  So I have the method just throwing the
>         publically available exceptions shows on MSDN.  This second
>         method will always throw PlatformNotSupported, for API
>         completeness with the .NET 2.0 SP2 framework.
> 
>     This method, as well, can be implemented to perform its function on
>     Mono just fine. If you feel like giving it a try, I'd welcome a new
>     patch which implements it. If not, I will accept the patch as it is
>     now and implement the API fully at some point.
> 
> 
>         Please let me know what the next steps are or if there is
>         anything that I need to change in order to get this patch moved
>         into production.
> 
>         Thanks,
>         Nick
> 
> 
>     best regards,
> 
>     marek
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list