[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 16:02:45 EDT 2009
Hi Marek,
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.
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.TransferRequest'.
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.
And there are many 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.
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.
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.
Nick
On Thu, Sep 24, 2009 at 2:32 PM, Marek Habersack <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 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> 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>> 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
>> 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/a01b7a1d/attachment.html
More information about the Mono-devel-list
mailing list