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

Tue Sep 29 17:34:34 EDT 2009

Nick Berardi wrote:
> Hi guys,
Hey Nick,

> I looked in to this more and there are a couple issues that popped up 
> when trying to implement the following method:
> 
> public void TransferRequest(string path, bool preserveForm, string 
> method, NameValueCollection headers)
> 
> My major hurdle that I wasn't able to over come is the following, 
> probably because I don't know how the actual server was implemented.
> 
> /TransferRequest is suppose to kick off a new request in the application 
> life cycle, which means that it needs to create a new request which runs 
> all the way through from BeginRequest to EndRequest in the 
> HttpApplication, after it has killed off the current request. /
> 
> I don't know how I can do this in the Mono code base, because everytime 
> I called Response.End() the request was transmitted back to the client.  
> Which is by design of Response.End(), however I need a way to end the 
> current request life cycle and start a new one giving the path, headers, 
> method, and content body, and not have it transmit back to the client 
> until this second request is done.
You can try one of two things:

1. Easier (and imho, enough to emulate IIS7 behavior) - just redirect the request
2. If you want to play with it more, you can emulate a new request by first acquiring a new 
HttpApplication instance for the current application (see HttpRuntime.Process for info on how to do 
that), then start asynchronous request on the instance (again, look in Process as above) and after 
it is started, end the current request.

best regards,

marek

> Can either of you guys give me a clue on how to get this implemented, or 
> any code to look at that does something similar?  I am trying to get 
> this in the next code release of mono for my users, so if you could help 
> me out that would be great.
> 
> Nick
> 
> On Fri, Sep 25, 2009 at 5:32 AM, Marek Habersack 
> <grendel at twistedcode.net <mailto:grendel at twistedcode.net>> wrote:
> 
>     Chuck Esterbrook wrote:
>      > On Thu, Sep 24, 2009 at 1:20 PM, Marek Habersack
>      > <grendel at twistedcode.net <mailto:grendel at twistedcode.net>> wrote:
>      >>> Nick Berardi wrote:
>      >>> 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?
>      >
>      > Marek, if you can't do it now because you're busy with other things,
>      > then it's easy to imagine that Nick can't do it now because he's also
>      > busy. Also, Nick probably has less knowledge about ASP.NET
>     <http://ASP.NET> internals
>      > which raises the cost of implementation for him.
>     This is the obstacle all of us contributing to Mono encountered at
>     some point. I think Nick and I
>     came to a conclusion regarding the issue. If Nick doesn't have time
>     to implement them, I will - but
>     not right away and not now. This is an opensource project, created
>     and developed by community -
>     usually people submit patches in areas they are interested in, and
>     that works best - as everybody
>     will do their best to implement code as good as they can, because
>     they themselves are going to use
>     it and they themselves know the context in which they are using it.
> 
>      > I would think a simple patch that avoids MissingMethodExceptions
>     would
>      > be a good thing and easy to accept.
>     On surface, yes, in reality - no. We really try to avoid stubbed
>     methods committed for the sake of
>     having them but with no functionality. It is very likely that after
>     comitting, the stubs will remain
>      unimplemented for unknown time, thus providing a false ilussion
>     that Mono supports this or that
>     API, which will cause (for instance) MOMA reports to show false
>     positives etc. etc. NOT accepting
>     stubs has also the effect that people (including ourselves in the
>     team) are motivated to actually
>     implement the code, IMHO.
> 
>     best regards,
> 
>     marek
> 
>      >
>      > -Chuck
>      > _______________________________________________
>      > 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
>     <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