Hi If the change applies for Camel 2.0 only then I think it's okay to change the default behavior if we have stated it in the wiki documentation and release notes as well.
For 1.5.1 if we patch it, then a LOG WARN is fine, maybe on the endpoint creation, so you wont get the WARN on each message exchange. /Claus Ibsen Apache Camel Committer Blog: http://davsclaus.blogspot.com/ On Fri, Nov 14, 2008 at 7:40 PM, Roman Kalukiewicz <[EMAIL PROTECTED]> wrote: > One concern about this bug (I've already implemented a fix, so it is > almost there). > > I'm afraid that majority of people today have constructs like: > > from("jetty:http://localhost:1234/myPath";) > > while what they want is > > from("jetty:http://0.0.0.0:1234/myPath";) > > This way we may brake some routes that already exist. I believe it > deserves at least a warning in logs. > > My question is if we would like to preserve an old behavior as a > default one or maybe write a warning and behave in a proper way. > > What do you think? > > I personally would choose a warning only. > > Romek > > 2008/11/14 Claus Ibsen <[EMAIL PROTECTED]>: >> Hi Romek >> >> Could you check the camel-jetty component to see what needs to be >> changed to support the issue with localhost? >> So we could try to fix the issue if possible. >> >> /Claus Ibsen >> Apache Camel Committer >> Blog: http://davsclaus.blogspot.com/ >> >> >> >> On Fri, Nov 14, 2008 at 10:58 AM, Roman Kalukiewicz >> <[EMAIL PROTECTED]> wrote: >>> Hello Gert! >>> >>> In fact 0.0.0.0 address is specified in (RFC 1700) and it is correct. >>> On IPv6 network similar address is 0:0:0:0:0:0:0:0 (RFC 2373). Both of >>> them are used in C as constants INADDR_ANY and IN6ADDR_ANY (their >>> value are zeros). >>> >>> Of course I agree that if you specify localhost, it should bind to >>> local interface and so on in case of jetty, but MINA behaves OK. >>> >>> Romek >>> >>> 2008/11/14 Trevv <[EMAIL PROTECTED]>: >>>> >>>> >>>> Gert Vanthienen wrote: >>>>> >>>>> In the current implementation, camel-jetty already binds to all local >>>>> interfaces, even if you use localhost in the uri. >>>> >>>> Hmm, that sounds like a security vulnerability. When people specify >>>> that a serversocket should be bound to localhost, often it's because >>>> they are exposing a service that hasn't been "hardened" for exposure >>>> to the hostile Internet. >>>> >>>> If Camel is allowing connections from the outside world, when the >>>> person who defined the route indicated that connections should only >>>> be allowed from localhost... that's probably a bad idea. >>>> >>>> >>>> Are you experiencing any problems with this? >>>> >>>> I'm not experiencing a problem with the Jetty consumer, because I'm >>>> using it only in a "test harness," on a virtual machine which the >>>> world can't access. >>>> >>>> The problem I'm experiencing is with the Mina consumer: if I specify >>>> localhost, then clients can't connect to my server unless they are >>>> local clients. This is actually the correct behavior when you specify >>>> localhost, but this isn't the behavior that I want. The behavior >>>> that I want is the behavior that you get if you pass null as the >>>> address argument of the InetSocketAddress constructor, at line >>>> #124 of MinaComponent.java version 1.5.0. >>>> >>>> I have temporarily solved my problem by specifying 0.0.0.0 instead >>>> of localhost. It's working, but it's a kluge, because: (1) Sun's >>>> javadoc never says that you can use "0.0.0.0" as a substitute for >>>> null; and (2) I suspect that it may not work with IPv6. >>>> >>>> My recommendations, for both Jetty and Mina consumers: >>>> >>>> DO allow the user to specify the wildcard address. >>>> >>>> DO NOT bind to the wildcard address, when the user specifies localhost. >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Jetty-and-Mina%3A-how-to-bind-to-%22anylocal%22-AKA-%22wildcard%22-address--tp20475674s22882p20494645.html >>>> Sent from the Camel - Users mailing list archive at Nabble.com. >>>> >>>> >>> >> >
