Re: [Mono-dev] HttpListener stops accepting requests

[Greg Young]

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

Re: [Mono-dev] HttpListener

[Teravus Ovares]

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

[Greg Young]

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

[Greg Young]

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

[Miguel de Icaza]

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

[Miguel de Icaza]

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

[Greg Young]

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

[Miguel de Icaza]

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

[Greg Young]

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

Re: [Mono-dev] HttpListener

[Greg Young]

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

[Greg Young]

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

[Andres G. Aragoneses]

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

Re: [Mono-dev] HttpListener

[Rodrigo Kumpera]

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

[Greg Young]

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

[Andres G. Aragoneses]

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?

[salar2k]

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?

[Gonzalo Paniagua Javier]

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?

[Gonzalo Paniagua Javier]

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?

[salar2k]

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?

[Gonzalo Paniagua Javier]

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?

[salar2k]

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

[Gert Driesen]

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

[Casey Marshall]

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

[Martin Baulig]

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

Re: [Mono-dev] HttpListener and basic auth

[Andrés G. Aragoneses]

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