Re: [Mono-dev] HttpListener stops accepting requests
I have to research a bit more and get a local build of mono building but there are definitely some places here: https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointListener.cs#L85 That can break the async loop causing the entire lsitener to stop accepting requests until its restarted. Cheers, Greg On Wed, Mar 2, 2016 at 4:58 PM, Greg Youngwrote: > We have found a situation where HttpListener on mono (reproduced in > linux/OSX) will permanently stop accepting requests. > > The issue involves ulimit. Basically if you get a connection flood > greater than ulimit the server will stop accepting all requests until > it is restarted. > > After the connection flood you can see the connections were all > properly killed (I won't put all the ones that were there during the > flood!): > > greg@clown:~$ lsof -p 16651 > lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing > Output information may be incomplete. > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > eventstor 16651 greg cwdDIR8,2 4096 2105316 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0 > eventstor 16651 greg rtdDIR8,2 40962 / > eventstor 16651 greg txtREG8,2 37443029 2105361 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/eventstored > eventstor 16651 greg memREG8,2 92504 12849525 > /lib/x86_64-linux-gnu/libgcc_s.so.1 > eventstor 16651 greg memREG8,2 51736 12845148 > /lib/x86_64-linux-gnu/libnss_files-2.21.so > eventstor 16651 greg memREG8,2 47616 12845159 > /lib/x86_64-linux-gnu/libnss_nis-2.21.so > eventstor 16651 greg memREG8,2 97224 12845153 > /lib/x86_64-linux-gnu/libnsl-2.21.so > eventstor 16651 greg memREG8,2 35688 12845149 > /lib/x86_64-linux-gnu/libnss_compat-2.21.so > eventstor 16651 greg memREG8,2 8464208 9444549 > /usr/lib/locale/locale-archive > eventstor 16651 greg memREG8,2 1869392 12845162 > /lib/x86_64-linux-gnu/libc-2.21.so > eventstor 16651 greg memREG8,2142080 12845083 > /lib/x86_64-linux-gnu/libpthread-2.21.so > eventstor 16651 greg memREG8,2 14592 12845158 > /lib/x86_64-linux-gnu/libdl-2.21.so > eventstor 16651 greg memREG8,2 31680 12845075 > /lib/x86_64-linux-gnu/librt-2.21.so > eventstor 16651 greg memREG8,2 1084840 12845161 > /lib/x86_64-linux-gnu/libm-2.21.so > eventstor 16651 greg memREG8,2154376 12845156 > /lib/x86_64-linux-gnu/ld-2.21.so > eventstor 16651 greg memREG 0,21 4096 88 /dev/shm/mono.16651 > eventstor 16651 greg0u CHR 136,1 0t04 /dev/pts/1 > eventstor 16651 greg1u CHR 136,1 0t04 /dev/pts/1 > eventstor 16651 greg2u CHR 136,1 0t04 /dev/pts/1 > eventstor 16651 greg3r 0,11 0 7966 anon_inode > eventstor 16651 greg4u REG8,2 8 2624038 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/writer.chk > eventstor 16651 greg5u REG8,2 8 2624039 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chaser.chk > eventstor 16651 greg6u REG8,2 8 2624040 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/epoch.chk > eventstor 16651 greg7u REG8,2 8 2624041 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/truncate.chk > eventstor 16651 greg8r CHR1,9 0t0 11 /dev/urandom > eventstor 16651 greg9u REG8,2 268435712 2624042 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 > eventstor 16651 greg 10r REG8,2 268435712 2624042 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 > eventstor 16651 greg 11r REG8,2 268435712 2624042 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 > eventstor 16651 greg 12r REG8,2 268435712 2624042 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 > eventstor 16651 greg 13r REG8,2 268435712 2624042 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 > eventstor 16651 greg 14r REG8,2 268435712 2624042 > /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 > eventstor 16651 greg 15u IPv4 279150 0t0 TCP > localhost:1113 (LISTEN) > eventstor 16651 greg 16u 0,11 0 7966 anon_inode > eventstor 16651 greg 17u IPv4 278173 0t0 TCP > localhost:2113 (LISTEN) > > > My guess is that the too many files kills the asynchronous loop around > the accept in the httplistener code and will take a look there. > Perhaps someone else has some ideas. > > Cheers, > > Greg > > -- > Studying for the Turing test -- Studying for the Turing test ___
[Mono-dev] HttpListener stops accepting requests
We have found a situation where HttpListener on mono (reproduced in linux/OSX) will permanently stop accepting requests. The issue involves ulimit. Basically if you get a connection flood greater than ulimit the server will stop accepting all requests until it is restarted. After the connection flood you can see the connections were all properly killed (I won't put all the ones that were there during the flood!): greg@clown:~$ lsof -p 16651 lsof: WARNING: can't stat() tracefs file system /sys/kernel/debug/tracing Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME eventstor 16651 greg cwdDIR8,2 4096 2105316 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0 eventstor 16651 greg rtdDIR8,2 40962 / eventstor 16651 greg txtREG8,2 37443029 2105361 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/eventstored eventstor 16651 greg memREG8,2 92504 12849525 /lib/x86_64-linux-gnu/libgcc_s.so.1 eventstor 16651 greg memREG8,2 51736 12845148 /lib/x86_64-linux-gnu/libnss_files-2.21.so eventstor 16651 greg memREG8,2 47616 12845159 /lib/x86_64-linux-gnu/libnss_nis-2.21.so eventstor 16651 greg memREG8,2 97224 12845153 /lib/x86_64-linux-gnu/libnsl-2.21.so eventstor 16651 greg memREG8,2 35688 12845149 /lib/x86_64-linux-gnu/libnss_compat-2.21.so eventstor 16651 greg memREG8,2 8464208 9444549 /usr/lib/locale/locale-archive eventstor 16651 greg memREG8,2 1869392 12845162 /lib/x86_64-linux-gnu/libc-2.21.so eventstor 16651 greg memREG8,2142080 12845083 /lib/x86_64-linux-gnu/libpthread-2.21.so eventstor 16651 greg memREG8,2 14592 12845158 /lib/x86_64-linux-gnu/libdl-2.21.so eventstor 16651 greg memREG8,2 31680 12845075 /lib/x86_64-linux-gnu/librt-2.21.so eventstor 16651 greg memREG8,2 1084840 12845161 /lib/x86_64-linux-gnu/libm-2.21.so eventstor 16651 greg memREG8,2154376 12845156 /lib/x86_64-linux-gnu/ld-2.21.so eventstor 16651 greg memREG 0,21 4096 88 /dev/shm/mono.16651 eventstor 16651 greg0u CHR 136,1 0t04 /dev/pts/1 eventstor 16651 greg1u CHR 136,1 0t04 /dev/pts/1 eventstor 16651 greg2u CHR 136,1 0t04 /dev/pts/1 eventstor 16651 greg3r 0,11 0 7966 anon_inode eventstor 16651 greg4u REG8,2 8 2624038 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/writer.chk eventstor 16651 greg5u REG8,2 8 2624039 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chaser.chk eventstor 16651 greg6u REG8,2 8 2624040 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/epoch.chk eventstor 16651 greg7u REG8,2 8 2624041 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/truncate.chk eventstor 16651 greg8r CHR1,9 0t0 11 /dev/urandom eventstor 16651 greg9u REG8,2 268435712 2624042 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 eventstor 16651 greg 10r REG8,2 268435712 2624042 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 eventstor 16651 greg 11r REG8,2 268435712 2624042 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 eventstor 16651 greg 12r REG8,2 268435712 2624042 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 eventstor 16651 greg 13r REG8,2 268435712 2624042 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 eventstor 16651 greg 14r REG8,2 268435712 2624042 /home/greg/Downloads/EventStore-OSS-Ubuntu-14.04-v3.5.0/data/chunk-00.00 eventstor 16651 greg 15u IPv4 279150 0t0 TCP localhost:1113 (LISTEN) eventstor 16651 greg 16u 0,11 0 7966 anon_inode eventstor 16651 greg 17u IPv4 278173 0t0 TCP localhost:2113 (LISTEN) My guess is that the too many files kills the asynchronous loop around the accept in the httplistener code and will take a look there. Perhaps someone else has some ideas. Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Since we're talking about the HttpListener..Any thoughts on making HttpListener more friendly to longer running, blocked tasks.? Such as Event Queues. Almost all of these edge cases involve reading the input stream for paths/queryparams/etc, blocking the thread while doing some work or waiting some amount of time, then servicing the response. With the current HTTPListener this leads to lots of precious threadpool threads blocked and not doing anything but also counting against the mono threadpool thread limit. The simplest way that this can be done is simply decoupling the HttpListener threads from the threadpool thread limit.. that way the threadpool threads are limited separately. The more complicated way could be to allow some sort of thread sleep call that puts the IO streams for the http requests into a pool of streams managed by a single worker thread while they're waiting and then restores them to it's own thread once the work is done to send the response. I have previously done the second method with a third party HttpListener replacement and it saved a lot of threads which freed them up to do other useful things in a highly parallel server without forcing the end user to manually specify a larger mono maximum threadpool thread limit. Regards Teravus On Tue, May 19, 2015 at 2:28 PM, Greg Young gregoryyou...@gmail.com wrote: Yes exactly my intention. The problem is I am only given http prefixes in that code. Consider the case I have an interface 192.168.1.1 and an interface 10.114.1.112 Given a http prefix of http://my.elasticip:8080 which interface should it pick? As you can see here the prefixes are being used for both: https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L77 as well as some odd error conditions which I imagine are to match MS implementation but would need to verify that. If there was a separation between which interface to pick vs which http prefixes to use this would solve the problem and is essentially what I was talking about putting in as an overload. I know mono is as a whole a bit reluctant to add mono specific overloads (which is completely understandable). I just find kind any other reasonable way here of handling the windows/mono differences. https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpListener.cs#L269 leads to https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L48 I could do this in a couple of ways (add state to HttpListener is an obvious one + an overload that only changes behaviour if its used). Greg On Wed, May 20, 2015 at 12:18 AM, Miguel de Icaza mig...@xamarin.com wrote: Shouldn't we bind on the interface based on the IP address? Would that not solve the problem? miguel On Tue, May 19, 2015 at 4:00 PM, Greg Young gregoryyou...@gmail.com wrote: I was thinking a basic code api that allowed the specification of interface to bind to separately from which prefixes to accept to start with. The biggest issue here is that the ms api is basically using httpprefix to mean two very different things. On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza mig...@xamarin.com wrote: Well, it might be best if you explain what you have in mind, before we waste time with a pull request. But either way works. On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com wrote: Miguel, Would it be best to just take a stab at an alternative interface and send a PR for discussion? Greg On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com wrote: This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS
Re: [Mono-dev] HttpListener
Yes exactly my intention. The problem is I am only given http prefixes in that code. Consider the case I have an interface 192.168.1.1 and an interface 10.114.1.112 Given a http prefix of http://my.elasticip:8080 which interface should it pick? As you can see here the prefixes are being used for both: https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L77 as well as some odd error conditions which I imagine are to match MS implementation but would need to verify that. If there was a separation between which interface to pick vs which http prefixes to use this would solve the problem and is essentially what I was talking about putting in as an overload. I know mono is as a whole a bit reluctant to add mono specific overloads (which is completely understandable). I just find kind any other reasonable way here of handling the windows/mono differences. https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/HttpListener.cs#L269 leads to https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L48 I could do this in a couple of ways (add state to HttpListener is an obvious one + an overload that only changes behaviour if its used). Greg On Wed, May 20, 2015 at 12:18 AM, Miguel de Icaza mig...@xamarin.com wrote: Shouldn't we bind on the interface based on the IP address? Would that not solve the problem? miguel On Tue, May 19, 2015 at 4:00 PM, Greg Young gregoryyou...@gmail.com wrote: I was thinking a basic code api that allowed the specification of interface to bind to separately from which prefixes to accept to start with. The biggest issue here is that the ms api is basically using httpprefix to mean two very different things. On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza mig...@xamarin.com wrote: Well, it might be best if you explain what you have in mind, before we waste time with a pull request. But either way works. On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com wrote: Miguel, Would it be best to just take a stab at an alternative interface and send a PR for discussion? Greg On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com wrote: This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test -- Studying for the Turing test -- Studying for the Turing test -- Studying for the Turing test ___
Re: [Mono-dev] HttpListener
Miguel, Would it be best to just take a stab at an alternative interface and send a PR for discussion? Greg On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com wrote: This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Well, it might be best if you explain what you have in mind, before we waste time with a pull request. But either way works. On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com wrote: Miguel, Would it be best to just take a stab at an alternative interface and send a PR for discussion? Greg On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com wrote: This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Shouldn't we bind on the interface based on the IP address? Would that not solve the problem? miguel On Tue, May 19, 2015 at 4:00 PM, Greg Young gregoryyou...@gmail.com wrote: I was thinking a basic code api that allowed the specification of interface to bind to separately from which prefixes to accept to start with. The biggest issue here is that the ms api is basically using httpprefix to mean two very different things. On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza mig...@xamarin.com wrote: Well, it might be best if you explain what you have in mind, before we waste time with a pull request. But either way works. On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com wrote: Miguel, Would it be best to just take a stab at an alternative interface and send a PR for discussion? Greg On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com wrote: This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
I was thinking a basic code api that allowed the specification of interface to bind to separately from which prefixes to accept to start with. The biggest issue here is that the ms api is basically using httpprefix to mean two very different things. On Tue, May 19, 2015 at 10:58 PM, Miguel de Icaza mig...@xamarin.com wrote: Well, it might be best if you explain what you have in mind, before we waste time with a pull request. But either way works. On Tue, May 19, 2015 at 3:50 PM, Greg Young gregoryyou...@gmail.com wrote: Miguel, Would it be best to just take a stab at an alternative interface and send a PR for discussion? Greg On Sun, Apr 26, 2015 at 4:43 PM, Greg Young gregoryyou...@gmail.com wrote: This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
This is the code handling the prefixes its here https://github.com/mono/mono/blob/master/mcs/class/System/System.Net/EndPointManager.cs#L43 There is quite a bit of odd code around this in general. I understand much of it is trying to reach compliance with MS but ... On Sun, Apr 26, 2015 at 4:40 PM, Miguel de Icaza mig...@xamarin.com wrote: Hello Greg, Is that in HttpListener, or somewhere else? Miguel On Fri, Apr 24, 2015 at 12:41 PM, Greg Young gregoryyou...@gmail.com wrote: Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpListener
I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Here is some of the code in question: IPAddress addr; if (host == *) addr = IPAddress.Any; else if (IPAddress.TryParse(host, out addr) == false){ try { IPHostEntry iphost = Dns.GetHostByName(host); if (iphost != null) addr = iphost.AddressList[0]; else addr = IPAddress.Any; } catch { addr = IPAddress.Any; } } On Fri, Apr 24, 2015 at 7:29 PM, Greg Young gregoryyou...@gmail.com wrote: I have been going through a bunch of this code lately after seeing many ... interesting behaviours. I understand that much of the derp in this code is due to not having IIS and MS having an IIS centric API but wow. Some gems I have found... 1) synchronous dns calls being made... 2) I want to listen on 192.168.0.1:1234 but I want to support a host header of whateverdomain can't resolve whatever domain then bind listeners to all ips on machine. 3) Same as above but dns entry has multiple ips it resovles to [0] doesnt match see #2 4) Anything at all to do with elastic ips 5) Exceptions thrown to calling code with http status codes in them (I think this is ms legacy but is a pretty biog wtf) 6) failure parsing ip address says bind all interfaces on machine (huh?) Perhaps it makes sense to expose a Microsoft Http Compatibility Layer and then have a Sane API if you want to use it I dont mind putting some time in on these but is this even worthwhile or is the plan to just burn this code with fire and move to something sane in general? Cheers, Greg -- Studying for the Turing test -- Studying for the Turing test ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
push coming. I learned the lesson the hard way long ago to never ever hold a lock when issuing a call to unknown code. This ended up biting us as some work was being done on the callback and the accepting of a new request was being blocked :( I might have 2-3 more as I try to figure out the bottlenecks in our http stuff so will try to get them together into one push. On Thu, Dec 6, 2012 at 3:43 AM, Andres G. Aragoneses kno...@gmail.comwrote: Hey Rodrigo, by looking at https://github.com/mono/mono/**commit/** 04c641a21c2ba92c3262948ed1b68e**b22c643b11https://github.com/mono/mono/commit/04c641a21c2ba92c3262948ed1b68eb22c643b11as you point out, it would make sense to find the call to GetContextFromQueue() inside the lock, but maybe ares.Complete() can be outside for better performance? (And then inside again when adding it to the wait_queue again.) Which is maybe what Greg meant. On 05/12/12 14:05, Rodrigo Kumpera wrote: Did you look at the git history for those changes to see why those changes have been made? 04c641a21c2ba92c3262948ed1b68e**b22c643b11 seens relevant. On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.com mailto:gregoryyoung1@gmail.**com gregoryyou...@gmail.com wrote: CheckDisposed (); if (!listening) throw new InvalidOperationException (Please, call Start before using this method.); ListenerAsyn __**_ Mono-devel-list mailing list Mono-devel-list@lists.ximian.**com Mono-devel-list@lists.ximian.com http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list __**_ Mono-devel-list mailing list Mono-devel-list@lists.ximian.**com Mono-devel-list@lists.ximian.com http://lists.ximian.com/**mailman/listinfo/mono-devel-**listhttp://lists.ximian.com/mailman/listinfo/mono-devel-list -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Actually, scratch my comment. There are two locks in there. Look more carefully at the change... Sadly the bug that it says to fix is private so one cannot extract a regression/stress test from it. On 06/12/12 08:08, Greg Young wrote: push coming. I learned the lesson the hard way long ago to never ever hold a lock when issuing a call to unknown code. This ended up biting us as some work was being done on the callback and the accepting of a new request was being blocked :( I might have 2-3 more as I try to figure out the bottlenecks in our http stuff so will try to get them together into one push. On Thu, Dec 6, 2012 at 3:43 AM, Andres G. Aragoneses kno...@gmail.com mailto:kno...@gmail.com wrote: Hey Rodrigo, by looking at https://github.com/mono/mono/__commit/__04c641a21c2ba92c3262948ed1b68e__b22c643b11 https://github.com/mono/mono/commit/04c641a21c2ba92c3262948ed1b68eb22c643b11 as you point out, it would make sense to find the call to GetContextFromQueue() inside the lock, but maybe ares.Complete() can be outside for better performance? (And then inside again when adding it to the wait_queue again.) Which is maybe what Greg meant. On 05/12/12 14:05, Rodrigo Kumpera wrote: Did you look at the git history for those changes to see why those changes have been made? 04c641a21c2ba92c3262948ed1b68e__b22c643b11 seens relevant. On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.com mailto:gregoryyou...@gmail.com mailto:gregoryyoung1@gmail.__com mailto:gregoryyou...@gmail.com wrote: CheckDisposed (); if (!listening) throw new InvalidOperationException (Please, call Start before using this method.); ListenerAsyn _ Mono-devel-list mailing list Mono-devel-list@lists.ximian.__com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/__mailman/listinfo/mono-devel-__list http://lists.ximian.com/mailman/listinfo/mono-devel-list _ Mono-devel-list mailing list Mono-devel-list@lists.ximian.__com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/__mailman/listinfo/mono-devel-__list http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpListener
I was in looking at some code today in httplistener and didn't understand some of the stuff going on (was hitting a performance penalty due to it). In particular I was a bit confused when looking at Begin and EndGetContext (included below).. It would seem harmful to call ares.Complete below while holding a lock to wait_queue. I just wanted to see what someone may have been thinking before spending time on a patch public IAsyncResult BeginGetContext (AsyncCallback callback, Object state) { CheckDisposed (); if (!listening) throw new InvalidOperationException (Please, call Start before using this method.); ListenerAsyncResult ares = new ListenerAsyncResult (callback, state); // lock wait_queue early to avoid race conditions lock (wait_queue) { lock (ctx_queue) { HttpListenerContext ctx = GetContextFromQueue (); if (ctx != null) { ares.Complete (ctx, true); return ares; } } wait_queue.Add (ares); } return ares; } public HttpListenerContext EndGetContext (IAsyncResult asyncResult) { CheckDisposed (); if (asyncResult == null) throw new ArgumentNullException (asyncResult); ListenerAsyncResult ares = asyncResult as ListenerAsyncResult; if (ares == null) throw new ArgumentException (Wrong IAsyncResult., asyncResult); if (!ares.IsCompleted) ares.AsyncWaitHandle.WaitOne (); lock (wait_queue) { int idx = wait_queue.IndexOf (ares); if (idx = 0) wait_queue.RemoveAt (idx); } HttpListenerContext context = ares.GetContext (); context.ParseAuthentication (SelectAuthenticationScheme (context)); return context; // This will throw on error. } -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Did you look at the git history for those changes to see why those changes have been made? 04c641a21c2ba92c3262948ed1b68eb22c643b11 seens relevant. On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.com wrote: CheckDisposed (); if (!listening) throw new InvalidOperationException (Please, call Start before using this method.); ListenerAsyn ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
I did see it (and comment). Thought there might be something more to it. On Wed, Dec 5, 2012 at 4:05 PM, Rodrigo Kumpera kump...@gmail.com wrote: Did you look at the git history for those changes to see why those changes have been made? 04c641a21c2ba92c3262948ed1b68eb22c643b11 seens relevant. On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.comwrote: CheckDisposed (); if (!listening) throw new InvalidOperationException (Please, call Start before using this method.); ListenerAsyn -- Le doute n'est pas une condition agréable, mais la certitude est absurde. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener
Hey Rodrigo, by looking at https://github.com/mono/mono/commit/04c641a21c2ba92c3262948ed1b68eb22c643b11 as you point out, it would make sense to find the call to GetContextFromQueue() inside the lock, but maybe ares.Complete() can be outside for better performance? (And then inside again when adding it to the wait_queue again.) Which is maybe what Greg meant. On 05/12/12 14:05, Rodrigo Kumpera wrote: Did you look at the git history for those changes to see why those changes have been made? 04c641a21c2ba92c3262948ed1b68eb22c643b11 seens relevant. On Wed, Dec 5, 2012 at 8:52 AM, Greg Young gregoryyou...@gmail.com mailto:gregoryyou...@gmail.com wrote: CheckDisposed (); if (!listening) throw new InvalidOperationException (Please, call Start before using this method.); ListenerAsyn ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener https bug?
Many thanks, now i know the problem and will find a way for that. I found this simple app useful: http://www.codeproject.com/KB/IP/HTTPSDebuggingProxy.aspx -- View this message in context: http://mono.1490590.n4.nabble.com/HttpListener-https-bug-tp2527913p2535559.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener https bug?
On Wed, 2010-09-08 at 18:10 -0700, salar2k wrote: Guess it doesn't needed because the issue occurs even with your peace of program. And yes i'm working on kind of proxy software. (is that important?) Yes. The way the browser tries to set up a https connection through the proxy is by using the CONNECT method over an unencrypted connection that is later turned into an encrypted one (tunneled through the proxy). HttpListener is expecting a TLS connection and the browser is sending plain text data... That's why the connection is being reset. You would need to listen with http://*:9667/ and then handle the CONNECT method appropriately. -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener https bug?
On Tue, 2010-09-07 at 22:56 -0700, salar2k wrote: Thanks for the reply. I've done the way you did and it works. But that was not my issue. Try to set browser's proxy to localhost:9667 and browse https://mail.google.com/mail/ . You will see it doesn't work and connection resets. This happens only when you're using https in listener. Change l.Prefixes.Add (https://*:9667/;); to l.Prefixes.Add (http://*:9667/;); and browse http://www.google.com it works as expected with a message Hello world!. You didn't mention any proxy before. Why don't you send the code of your listener? -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener https bug?
Guess it doesn't needed because the issue occurs even with your peace of program. And yes i'm working on kind of proxy software. (is that important?) I'm not sure but I guess the destination website (any ssl enabled website) doesn't trust the proxy's certificate to communicate with it. -- View this message in context: http://mono.1490590.n4.nabble.com/HttpListener-https-bug-tp2527913p2532247.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener https bug?
I've followed the steps in http://www.mono-project.com/UsingClientCertificatesWithXSP to create a root certificate and a client certificate (instead of generating a .p12, I created a .pvk and a .cer) and then used the client certificate as my server's. Then I created a small program (attached hl.cs) and run **Mono's** httpcfg to associate the certificate with port 9667. Everything worked just fine with Mono (and on .NET, since I didn't use their httpcfg, you get a connection reset error. See the screenshot at http://gonzalo.name/tmp/httplistener2.png -Gonzalo On Sun, 2010-09-05 at 22:11 -0700, salar2k wrote: I'm trying to use Mono HttpListener but after some test I'm running into an issue with HttpS. The project works well with simple http requests but just doesn't serve https. Here is what I've done to use it (win7), first try to create certificate files: makecert -r -pe -n CN=SALARPC -b 01/01/2000 -e 01/01/2040 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp Microsoft RSA SChannel Cryptographic Provider -sy 12 -sv local.pvk local.cer (this is microsoft makecert application) I've create certifications without password. and registration of files to the port: httpcfg -add -port 9667 -pvk local.pvk -cert local.cer All is done successfully. Unfortunately it doesn't response to https port. (note: actually httpcfg copies cer and pvk files for port 9667 to here: C:\Users\USERNAME\AppData\Roaming\.mono\httplistener) Second try with openssl and pvktool: openssl genrsa -des3 -out localhost.pem 2048 openssl rsa -in localhost.pem -out localhost.pem.nopass openssl req -new -key localhost.pem.nopass -out localhost.csr pvk -in localhost.pem.nopass -topvk -nocrypt -out localhost.pvk httpcfg -del -port 9667 httpcfg -add -port 9667 -pvk localhost.pvk -cert localhost.crt Still no luck with httplistener and https! Debugging the mono code I realize that it throws internally an exception during reading the request (HttpConnection.cs) which says The authentication or decryption has failed.: System.IO.IOException was caught Message=The authentication or decryption has failed. Source=Mono.HttpListener StackTrace: at Mono.Security.Protocol.Tls.SslStreamBase.EndRead(IAsyncResult asyncResult) at Mono.Net.HttpConnection.OnRead(IAsyncResult ares) InnerException: Mono.Security.Protocol.Tls.TlsException Message=A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. Source=Mono.HttpListener Am I doing something wrong! What's the problem? Or this is a bug? [Mono-2.6.7 - windows 7] using System; using System.IO; using System.Net; namespace ConsoleApplication1 { class Class1 { static void Main () { HttpListener l = new HttpListener (); l.Prefixes.Add (https://*:9667/;); l.Start (); l.BeginGetContext (OnGetContext, l); Console.ReadLine (); } static void OnGetContext (IAsyncResult ares) { HttpListener l = ares.AsyncState as HttpListener; if (l == null) return; try { HttpListenerContext ctx = l.EndGetContext (ares); Console.WriteLine (Got request); l.BeginGetContext (OnGetContext, l); using (StreamWriter writer = new StreamWriter (ctx.Response.OutputStream)) writer.Write (Hello world!); ctx.Response.Close (); Console.WriteLine (Sent request); } catch (Exception e) { Console.WriteLine (e); Environment.Exit (1); } } } } ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener https bug?
Thanks for the reply. I've done the way you did and it works. But that was not my issue. Try to set browser's proxy to localhost:9667 and browse https://mail.google.com/mail/ . You will see it doesn't work and connection resets. This happens only when you're using https in listener. Change l.Prefixes.Add (https://*:9667/;); to l.Prefixes.Add (http://*:9667/;); and browse http://www.google.com it works as expected with a message Hello world!. I've made trusted that certificate to be sure if maybe browser is strict about that. (I've installed the cer file in windows Trusted Root Certification Authorities so now it's trusted). -- View this message in context: http://mono.1490590.n4.nabble.com/HttpListener-https-bug-tp2527913p2530819.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener hangs with r106513
Hey Casey, Miguel prepared a fix for this issue (committed by Martin in r107127), and I've added a unit test based on your repro. Gert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Casey Marshall Sent: woensdag 25 juni 2008 1:05 To: mono-devel Subject: [Mono-dev] HttpListener hangs with r106513 I've noticed that it recent SVN mono snapshots (r106513) using HttpListener and WebRequest in the same process hangs. This doesn't hang with 1.9.1, and didn't with less recent snapshots. I haven't tried having the client and server in different processes, and don't know if it reproduces there. Test case: using System; using System.IO; using System.Net; using System.Threading; class simplehttp { public static void Main(string[] argv) { simplehttp sh = new simplehttp(); Thread srv = new Thread(new ThreadStart(sh.ServerMain)); srv.Name = HttpServer; srv.Start(); for (;;) { HttpWebRequest req = (HttpWebRequest) WebRequest.Create (http://localhost:/foobar/;); req.ServicePoint.Expect100Continue = false; req.ServicePoint.UseNagleAlgorithm = false; req.Method = POST; StreamWriter w = new StreamWriter(req.GetRequestStream()); w.WriteLine(Hello, server!); w.Close(); HttpWebResponse resp = (HttpWebResponse) req.GetResponse(); StreamReader r = new StreamReader(resp.GetResponseStream()); System.Console.WriteLine(client reads: {0}, r.ReadToEnd()); r.Close(); } } private void ServerMain() { HttpListener listener = new HttpListener(); listener.Prefixes.Add(http://*:/foobar/;); listener.Start(); while (true) { HttpListenerContext ctx = listener.GetContext(); ThreadPool.QueueUserWorkItem(new WaitCallback(HandleConnection), ctx); } } private void HandleConnection(object state) { HttpListenerContext ctx = (HttpListenerContext) state; HttpListenerRequest req = ctx.Request; StreamReader r = new StreamReader(req.InputStream); System.Console.WriteLine (server reads {0}, r.ReadToEnd()); HttpListenerResponse resp = ctx.Response; StreamWriter o = new StreamWriter(resp.OutputStream); o.WriteLine(Hello, world!); o.Close(); } } Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener hangs with r106513
On Thu, 2008-07-03 at 10:44 +0200, Gert Driesen wrote: Hey Casey, Miguel prepared a fix for this issue (committed by Martin in r107127), and I've added a unit test based on your repro. Works fine now, both in the test case and the real app. Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener hangs with r106513
On Thu, 2008-07-03 at 10:44 +0200, Gert Driesen wrote: Miguel prepared a fix for this issue (committed by Martin in r107127), and I've added a unit test based on your repro. Yeah, I run into the same issue yesterday and Miguel and me finally figured it out. Closing the output stream did not close the HttpResponse, so the connection never shut down. -- Martin Baulig - [EMAIL PROTECTED] Novell GmbH, Düsseldorf GF: Volker Smid, Djamel Souici; HRB 21108 (AG Düsseldorf) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpListener hangs with r106513
I've noticed that it recent SVN mono snapshots (r106513) using HttpListener and WebRequest in the same process hangs. This doesn't hang with 1.9.1, and didn't with less recent snapshots. I haven't tried having the client and server in different processes, and don't know if it reproduces there. Test case: using System; using System.IO; using System.Net; using System.Threading; class simplehttp { public static void Main(string[] argv) { simplehttp sh = new simplehttp(); Thread srv = new Thread(new ThreadStart(sh.ServerMain)); srv.Name = HttpServer; srv.Start(); for (;;) { HttpWebRequest req = (HttpWebRequest) WebRequest.Create (http://localhost:/foobar/;); req.ServicePoint.Expect100Continue = false; req.ServicePoint.UseNagleAlgorithm = false; req.Method = POST; StreamWriter w = new StreamWriter(req.GetRequestStream()); w.WriteLine(Hello, server!); w.Close(); HttpWebResponse resp = (HttpWebResponse) req.GetResponse(); StreamReader r = new StreamReader(resp.GetResponseStream()); System.Console.WriteLine(client reads: {0}, r.ReadToEnd()); r.Close(); } } private void ServerMain() { HttpListener listener = new HttpListener(); listener.Prefixes.Add(http://*:/foobar/;); listener.Start(); while (true) { HttpListenerContext ctx = listener.GetContext(); ThreadPool.QueueUserWorkItem(new WaitCallback(HandleConnection), ctx); } } private void HandleConnection(object state) { HttpListenerContext ctx = (HttpListenerContext) state; HttpListenerRequest req = ctx.Request; StreamReader r = new StreamReader(req.InputStream); System.Console.WriteLine (server reads {0}, r.ReadToEnd()); HttpListenerResponse resp = ctx.Response; StreamWriter o = new StreamWriter(resp.OutputStream); o.WriteLine(Hello, world!); o.Close(); } } Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] HttpListener and basic auth
Maciej Paszta wrote: Hello Guys, I'm developing standalone service provider that uses HttpListener to serve appropriate requests. I'm having difficulty using Basic Authentication (not to say that it doesn't work at all). I'm using Mono 1.2.6 and the following testcase was performed on Windows, MacOS and Linux: The expected result is that browser shows login window when one can enter username and password. Unfortunately it doesn't. Method AuthenticationSelector is not called at all and the program throws NullReference exception in line 52. The following code was tested on .NET 2.0 and there it works as supposed. Report the bug and attach the testcase: http://www.mono-project.com/Bugs Thanks, Andres -- ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] HttpListener and basic auth
Hello Guys, I'm developing standalone service provider that uses HttpListener to serve appropriate requests. I'm having difficulty using Basic Authentication (not to say that it doesn't work at all). I'm using Mono 1.2.6 and the following testcase was performed on Windows, MacOS and Linux: Program.cs Description: Binary data The expected result is that browser shows login window when one can enter username and password. Unfortunately it doesn't. Method AuthenticationSelector is not called at all and the program throws NullReference exception in line 52. The following code was tested on .NET 2.0 and there it works as supposed. Best regards, Maciej Paszta ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list