Hello, I have one more thins to say about Warp. Warp provides self-socket-biding function called bindPort. This function tries to use IPv4 only. Is this intentional? Are their any reasons to not support IPv6 also? If this is not intentional, I would love to make a path to support both IPv4 and IPv6. P.S. To those who are not familiar to IPv6: If we can create a listing socket of IPv6 and if IPV6_V6ONLY is false, the socket can magically handle both IPv4 and IPv6. IPV6_V6ONLY is false by default on Linux and Mac. It is true by default on BSD. So, my hack would change Warp's behavior on BSD. That is, it can accept IPv6 only. I think that this behavior should be fixed in the network library. And I have already sent a pull request. https://github.com/haskell/network/pull/13 --Kazu
No, this is not intentional behavior. I just borrowed the code for
bindPort from elsewhere. If you have a better implementation, I'd be
happy to pull it. But I think that at least until the network package
change happens we should conditionally compile to make sure Warp
always listens on IPv4 by default.
On Wed, Jul 20, 2011 at 5:07 AM, Kazu Yamamoto
Hello,
I have one more thins to say about Warp.
Warp provides self-socket-biding function called bindPort. This function tries to use IPv4 only. Is this intentional? Are their any reasons to not support IPv6 also?
If this is not intentional, I would love to make a path to support both IPv4 and IPv6.
P.S.
To those who are not familiar to IPv6: If we can create a listing socket of IPv6 and if IPV6_V6ONLY is false, the socket can magically handle both IPv4 and IPv6.
IPV6_V6ONLY is false by default on Linux and Mac. It is true by default on BSD.
So, my hack would change Warp's behavior on BSD. That is, it can accept IPv6 only. I think that this behavior should be fixed in the network library. And I have already sent a pull request.
https://github.com/haskell/network/pull/13
--Kazu
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
No, this is not intentional behavior. I just borrowed the code for bindPort from elsewhere. If you have a better implementation, I'd be happy to pull it. But I think that at least until the network package change happens we should conditionally compile to make sure Warp always listens on IPv4 by default.
OK. Here is a patch. Please fetch it at your own convenience. https://github.com/kazu-yamamoto/warp/commit/02c1396c86e3fceb48cbe7df58cb631... I'm using runSettingsSocket with my own dual-stack socket. So, I can wait. --Kazu
On Wed, Jul 20, 2011 at 7:39 AM, Kazu Yamamoto
No, this is not intentional behavior. I just borrowed the code for bindPort from elsewhere. If you have a better implementation, I'd be happy to pull it. But I think that at least until the network package change happens we should conditionally compile to make sure Warp always listens on IPv4 by default.
OK.
Here is a patch. Please fetch it at your own convenience.
https://github.com/kazu-yamamoto/warp/commit/02c1396c86e3fceb48cbe7df58cb631...
I'm using runSettingsSocket with my own dual-stack socket. So, I can wait.
Thank you, I've pulled this commit along with your connection header changes and release Warp 0.4.3. Michael
participants (2)
-
Kazu Yamamoto -
Michael Snoyman