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

Nick Berardi nberardi at zigamorph.com
Tue Sep 29 19:39:25 EDT 2009

Hi Marek,
I don't really like #1, because this TransferRequest is used for rewriting
in most cases.  So doing a 302 redirect would be the wrong approach IMO.  I
will try #2, because that sounds like what I am looking for.


On Tue, Sep 29, 2009 at 5:34 PM, Marek Habersack <grendel at twistedcode.net>wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090929/04445bc0/attachment-0001.html 

More information about the Mono-devel-list mailing list