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

Marek Habersack grendel at twistedcode.net
Thu Sep 24 17:28:35 EDT 2009

Nick Berardi wrote:
> Hi Marek,
Hey Nick,

> 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, 
All I said was that it shouldn't be hard to do, not that it was trivial.

> seems like climbing a mountain to me.  In ASP.NET <http://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.
Well, the only way to discover is to just do it - that's the opensource way. You can't lose, you can 
only win. FWIW, this call in Mono would be probably just a simple wrapper around the old transfer APIs.

> Also you probably haven't heard much about these API's because they are 
> closer to the iron than most ASP.NET <http://ASP.NET> developers get. 
I'm hardly an ASP.NET developer as I spent 99% of my time working as close to the iron as it gets. 
My last ASP.NET site was built nearly 3 years ago.

>  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 
> <http://ASP.NET> is not very deep.  
I think, as said above, that at this point the closest we can get is to either call one of the old 
transfer APIs (HttpServerUtility.{Execute,Transfer}) or, should the functionality of the new API 
differ too much from them in _external_ behavior (as evidenced by tests on .NET), borrow code from 
them and use it to implement the new API. All you need to do that is in 
mcs/class/System.Web/System.Web/HttpServerUtility.cs in our source tree.

> 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 
Oh, believe me, I do - been there done that. My first contact with Mono and Mono's System.Web was 
quite overwhelming (Gonzalo probably laughed his noble behind off when he reviewed some of my 
patches) - but that's the only way to get started - just dive in head first.

best regards,

> Microsoft ASP.NET <http://ASP.NET> is clouding my understanding of Mom 
> ASP.NET <http://ASP.NET>.
> Thanks,
> Nick
> On Thu, Sep 24, 2009 at 4:20 PM, Marek Habersack 
> <grendel at twistedcode.net <mailto: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> <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>
>         <mailto: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>
>         <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>
>                <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>>
>                <mailto: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>
>                <mailto: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
>         <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

More information about the Mono-devel-list mailing list