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

[Nick Berardi]

Hi guys,

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.

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>wrote:

> Chuck Esterbrook wrote:
> > On Thu, Sep 24, 2009 at 1:20 PM, Marek Habersack
> > <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 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
> > 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/1b75d1a8/attachment.html