[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,
marek
> 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