[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 16:20:33 EDT 2009
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
More information about the Mono-devel-list
mailing list