Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <20575883.post@talk.nabble.com>
Date: Wed, 19 Nov 2008 00:59:29 -0800 (PST)
From: Trevv <456@safe-mail.net>
To: camel-user@activemq.apache.org
Subject: Re: Hmm, that sounds like a security vulnerability.
In-Reply-To: <f1c427510811180443x9ef20fcmceb7f1fc8c175a64@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <20475674.post@talk.nabble.com>
 <5380c69c0811122315r8004126q4d72e8290e18606e@mail.gmail.com>
 <20477096.post@talk.nabble.com> <491C1FB8.30100@skynet.be>
 <20494645.post@talk.nabble.com>
 <f1c427510811140158l654b29dbo676aca7a508e33cf@mail.gmail.com>
 <20536134.post@talk.nabble.com>
 <f1c427510811170954t7cbd02cfv241fc21948cab8a6@mail.gmail.com>
 <20556161.post@talk.nabble.com>
 <5380c69c0811180138vcdbd033t5eff5afe41cf2f40@mail.gmail.com>
 <f1c427510811180217y22e5c4caycb2f501764ba9732@mail.gmail.com>
 <3BEE72B5-71ED-46B6-ABCF-2A2197EE22DE@gmail.com>
 <f1c427510811180443x9ef20fcmceb7f1fc8c175a64@mail.gmail.com>


I agree that Claus's idea would solve the problem.  "Anylocalhost"
isn't quite right, but I think "anylocal" or "anylocaladdress" or
"allinterfaces" would be good.

RomKal wrote:
> But if you can address an endpoint (I believe you can) exposed with
> jetty:http://0.0.0.0:80/ with IPv6 then flag is not needed so
> definitely -1.
> 
> If someone knows it already, lets respond. Otherwise I'll try to
> verify it soon at home (as here I don't have IPv6 at all).
I don't think this is something that you can verify by testing,
because it might be implemented differently in different operating
systems.  I did a quick Web search, and the most relevant comment
that I found was this one, by an OS engineer at Sun:

Kacheong Poon wrote:
> 
> To make it easy for porting application from using IPv4 to IPv6,
> an interesting feature was introduced.  An IPv6 socket is allowed
> to receive both IPv4 and IPv6 traffic by default.  For example, an
> IPv6 TCP listening socket bind() to unspecified address and port
> x can receive connection requests from both IPv4 and IPv6 remote
> hosts to port x.  While porting is made easier, this is actually
> not "strictly correct."  Logically, IPv4 and IPv6 port spaces for
> transport protocols should be separate, hence this check in the
> code.
> 
> 
> http://mail.opensolaris.org/pipermail/networking-discuss/2005-November/011586.html
> [networking-discuss] Solaris socket bind() behavior 

In other words... it's complicated.  That's why I think that the
smartest thing to do, if you just want a normal serversocket, is
to leave the bind address as null, and let Sun's Java engineers
decide what to do, instead of trying to find a non-null string
that you think will have the same effect that null would have.

On the other hand... having to specify both 0.0.0.0 and [::] is
unfortunate, but not a disaster.  So I don't really need a fix.
-- 
View this message in context: http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20575883.html
Sent from the Camel - Users mailing list archive at Nabble.com.