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

Nick Berardi nberardi at zigamorph.com
Thu Sep 24 17:05:41 EDT 2009

Hi Marek,
I guess the misunderstanding is coming in the word "trivial".  If it
was truly trivial I would just do it.  But what may seem trivial to you,
seems like climbing a mountain to me.  In ASP.NET from Microsoft there is a
lot native invoke calls that are made to get the transfer request working
with the underlying server.  And I don't know what these are for XPS and
mod_mono, or even how to switch between the different servers or if even I
have to specify each server individually.  My reluctance to jump in head
first is that I don't know what I would be getting myself in to.

Also you probably haven't heard much about these API's because they are
closer to the iron than most ASP.NET developers get.  The only reason I use
them is because I have to be as close to the server as possible to get my
rewriter to work like mod_rewrite.  And the reason I want to get
them implemented is because I have been getting many requests from
developers who use XPS to do development and mod_mono for production, and
the XPS users want to also have my rewriter mimic the mod_rewrite stuff for
they see in the production environment.

If you give me a couple steps of what you think trivial would mean, I am
willing to take a whack at it.  But I really have no idea where to start,
because my understanding of the inner workings of Mono ASP.NET is not very

I hope you understand, that I am willing to put the work in, I just have no
idea where to start.  And I have a feeling that my knowledge of Microsoft
ASP.NET is clouding my understanding of Mom ASP.NET.


On Thu, Sep 24, 2009 at 4:20 PM, Marek Habersack <grendel at twistedcode.net>wrote:

> Nick Berardi wrote:
>> Hi Marek,
> Hey Nick,
>> It is ultimately up to the team to apply or not apply the patch.  So I
>> support whatever they choose is best for the Mono project.
> Well... I'm part of the team... and in charge of ASP.NET... :)
>  However I see no reason to wait to add these stub method in place.
>>  Because currently any application that relies on either of these API's, get
>> ugly exceptions like this:
>> Stack Trace: System.MissingMethodException: Method not found:
>> 'System.Web.HttpServerUtility.Trans
>> ferRequest'.
>> at System.Web.HttpApplication+<>c__CompilerGenerated1.MoveNext ()
>> [0x00000]
>> at System.Web.HttpApplication+<>c__CompilerGenerated2.MoveNext ()
>> [0x00000]
>> at System.Web.HttpApplication.Tick () [0x00000]
>> So there is not even a way to gracefully handle the exception from with in
>> the application.
> I realize that, but I would really prefer to accept a patch which does
> implement the API correctly.
>  And there are many ASP.NET <http://ASP.NET> applications, mine is one of
>> them, out there now that check to see if they are running on the Integrated
>> Pipeline or not.  And handle things differently based on this flag.
> Your report is actually the first one we got regarding the issue, so I'm
> not sure if it's that common (at least among apps running on Mono)
>  But by leaving out these stub API's the Mono project is essentially
>> forbidding any application that references these API's from running on their
>> software, even if the application fully supports .NET 2.0 pre and post SP2.
>>  (which is when they were introduced)  At the very least these API's should
>> be marked with MonoTODOAttribute and committed so that applications that
>> want to work around API's not currently implemented in Mono can do so.
> Frankly, I don't understand your resistance to implementing the transfer
> API - what are the technical reasons for not doing it? From MSDN docs it
> seems it should be pretty simple to implement, why not just do it (I can't
> do it right now as I'm busy with other things atm) and commit the full
> support?
>  All that I am really asking for is a graceful way to handle support for
>> Mono with in my application. Currently I can't even support Mono because I
>> get a ton of runtime errors about Missing Methods.  At least if the stubs
>> where in place, I could work around them, but setting a flag in the
>> Web.config or searching for something Mono specific in the runtime.
> I understand the issue, but it's not very hard to patch your copy of Mono,
> recompile and copy just the System.Web.dll assembly to your server.
> Alternatively you can just introduce an #if in your code to skip that part
> when compiling for Mono. Adding stubbed APIs just before 2.6 is to be
> branched is not acceptable IMO and should be the very last resort.
> best regards,
> marek
>  Nick
>> On Thu, Sep 24, 2009 at 2:32 PM, Marek Habersack <grendel at twistedcode.net<mailto:
>> grendel at twistedcode.net>> wrote:
>>    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 <http://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>
>>        <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>
>>        <mailto: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
>>        <mailto:Mono-devel-list at lists.ximian.com>
>>        http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090924/873c75dc/attachment-0001.html 

More information about the Mono-devel-list mailing list