[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
deep.
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.
Thanks,
Nick
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