[Mono-dev] Problem in SvcHttpHandler.cs ?
Alan McGovern
alan.mcgovern at gmail.com
Tue Jul 6 04:10:49 EDT 2010
The reason why there are no synchronous calls in silverlight is (I
believe) because you can easily deadlock the plugin by attempting a
synchronous call when using the browser http stack. For the web
request to be completed, the browser has to be able to iterate and if
a plugin is blocking, there's nothing the browser can do.
If I remeber correctly there is an explanation of this on msdn
somewhere.
Alan
On 6 Jul 2010, at 05:08, Atsushi Eno <atsushieno at veritas-vos-liberabit.com
> wrote:
> Hello Thiago,
>
> Thanks, there's a lot of major and minor missing functionalities all
> around. Our class status
> describes large part of those missing stuff (primarily in
> System.ServiceModel.dll):
> http://go-mono.com/status/
>
> Right now we have no plan to build "mono specific" WCF libraries. IMO
> libraries like
> what you said should be released cross platform, at places like
> codeplex.
> Instead you might have some useful code that could be used in our own
> core WCF
> assemblies (imagine if you have implemented WS-AtomicTransaction aside
> TransactionFlowBindingElement, and we don't have working code now.)
>
> Atsushi Eno
>
> On 2010/07/05 21:27, Thiago Padilha wrote:
>> Hi Atsushi,
>>
>> I have started messing with WCF last week but I'm very interested in
>> learning, If you need help with anything just send me a message.
>> Also, today I'm starting to develop an http binding/channel to allow
>> REST syncronous programming of WCF Services/Clients(compatible with
>> moonlight/silverlight 2/3). I know syncronous service calls aren't
>> officially supported by Silverlight, but(correct me if I'm wrong) I
>> don't see why that should'nt work if I extend at channel level. If
>> you
>> want to integrate my source code in the Mono specific libraries I'd
>> be
>> happy to send you.
>>
>> On Fri, Jul 2, 2010 at 3:54 PM, Atsushi Eno
>> <atsushieno at veritas-vos-liberabit.com> wrote:
>>
>>> Hi,
>>>
>>> Right, thanks for the analysis, that should be fixed, and I have
>>> an idea.
>>> Though I am now rewriting ASP.NET channel support based on our new
>>> HTTP
>>> (non-ASP.NET) channel stack and it does not use the code path you
>>> mentioned,
>>> I'd rather finish the rewrite first and then fix the actual issue.
>>>
>>> The idea above is to use Uri comparison using UriComponents based on
>>> HostNameComparisonMode value (which is ignored so far).
>>>
>>> Atsushi Eno
>>>
>>> On 2010/06/29 21:46, Thiago Padilha wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm hosting a WCF service using asp.net/mono from trunk
>>>> (r159644)
>>>> but encountered a problem when accessing the service from a virtual
>>>> machine :
>>>>
>>>> "
>>>> The argument HTTP context did not match any of the registered
>>>> listener manager (could be mismatch in URL, method etc.)
>>>> http://172.16.122.2:8080/Person.svc
>>>>
>>>> Description: HTTP 500. Error processing request.
>>>>
>>>> Stack Trace:
>>>>
>>>> System.InvalidOperationException: The argument HTTP context did not
>>>> match any of the registered listener manager (could be mismatch in
>>>> URL, method etc.) http://172.16.122.2:8080/Person.svc
>>>> at
>>>> System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
>>>> (System.Web.HttpContext ctx) [0x00120] in
>>>>
>>>> /home/thiago/monotrunk/mcs/class/System.ServiceModel/
>>>> System.ServiceModel.Channels/SvcHttpHandler.cs:141
>>>> at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
>>>> (System.Web.HttpContext context) [0x0000d] in
>>>>
>>>> /home/thiago/monotrunk/mcs/class/System.ServiceModel/
>>>> System.ServiceModel.Channels/SvcHttpHandler.cs:156
>>>> at System.Web.HttpApplication+<Pipeline>c__Iterator2.MoveNext ()
>>>> [0x00ce5] in
>>>> /home/thiago/monotrunk/mcs/class/System.Web/System.Web/
>>>> HttpApplication.cs:1344
>>>> at System.Web.HttpApplication.Tick () [0x00000] in
>>>>
>>>> /home/thiago/monotrunk/mcs/class/System.Web/System.Web/
>>>> HttpApplication.cs:914
>>>> "
>>>>
>>>> I think this happened because I tried to access the service trough
>>>> the "172.16.122.0" network which is the virtual network for my VMs.
>>>> The service works well if I access it on the local machine using
>>>> the
>>>> "http://127.0.0.1:8080/Person.svc" Url, but fails with the same
>>>> error
>>>> if I use "http://localhost:8080/Person.svc". After looking into the
>>>> source code I think the problem may be on the following
>>>> conditionals
>>>> (method 'FindBestMatchListener') :
>>>>
>>>> "
>>>> if (l.Uri.Equals (ctx.Request.Url)) {
>>>> best = l;
>>>> break;
>>>> }
>>>> //
>>>> if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
>>>> StringComparison.Ordinal))
>>>> continue;
>>>> "
>>>>
>>>> Maybe it should check the Uris for all the network interfaces?(I
>>>> have
>>>> no idea on how to do that).
>>>> _______________________________________________
>>>> 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
More information about the Mono-devel-list
mailing list