[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.
Nick
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