Hi all, I just entered AXIS2C-1484 - comments are very welcome. Rgds, tge
On Fri, 2010-06-18 at 11:53 +0200, Thomas Gentsch wrote: > BTW, just occurred to me: > > The network handler uses gethostbyname() which is not thread-safe. > If two threads concurrently use gethostbyname(), both calls may > overwrite each other the buffer internally used within gethostbyname() > and results may be complete rubbish. > > On UX you normally use gethostbyname_r() but is that available on > Windows too? > Or, even better, getnameinfo() ... > > > Normally, this is something for the dev list, I suppose, but might be > interesting to users, too, because it may explain strange behavior. > Right now, it applies (as it seems) to multi-threaded SOAP clients when > connecting to srvs. > > Rgds, > tge > > > On Fri, 2010-06-18 at 10:44 +0200, Thomas Gentsch wrote: > > Hi all! > > > > I have implemented this without major problems but have a few questions > > first: > > Process: > > - I'd open a jira entry in axis2c, describe the initial use case + the > > solution, attach the patches > > - now, which area is most appropriate? I looked at the existing ones > > and thought about "core.receivers" as it applies to http, tcp, ...? > > > > - I guess, the Axis2c dev mailing list is more appropriate ... ? > > > > Design + Implementation: > > - we have to extend axutil_network_handler_create_server_socket() > > which is being called (what I have found) > > > > axis2_http_server_start() > > axis2_http_svr_thread_create() > > axutil_network_handler_create_server_socket() > > > > (same for TCP and in addition there is one more reference > > in ./tools/tcpmon/src/session.c) > > > > - Now, normally I'd follow the goal to keep exposed APIs unchanged if > > possible - the APIs we'd need to change in any case are > > - axutil_network_handler_create_server_socket() > > - axis2_http_svr_thread_create() > > Question: Are these exposed and/or used by API programmers? > > > > - Second, how to configure the listen address? > > Ideally, I'd like to do it the same was as the server port: > > - by API, e.g. axis2_http_server_create() and/or > > - by axis2.xml > > > > - The axis2.xml-way is not a problem, but regarding the API-way I > > have another question: > > - we must not to change the existing axis2_http_server_create*() > > interfaces > > - therefore the only way would be to add 2 more calls, e.g. > > axis2_http_server_create_with_addr(env, repo, addr, port) > > which makes then 4 on them -> not very nice > > - Alternatively, what I have done now, is to add a function > > axis2_http_server_set_addr(transpRecv, addr, env) > > which, if not called, retains the current behavior. If called > > right after axis2_http_server_create() and before > > axis2_transport_receiver_start(), it does the trick > > > > - Now, which one do you believe is better? > > > > Example: > > > > server = axis2_http_server_create(env, repo, port); > > axis2_http_server_set_addr(server, "127.0.0.1", env); > > axis2_transport_receiver_start(server, env); > > > > Patch files are attached for a first review :-) > > I have done it for HTTP only in a first attempt, but TCP would be > > exactly the same. > > > > Finally, in network_handler.c are a few other functions which I saw also > > bind to hard-coded INADDR_ANY - however I did not check, where they are > > called from ... > > > > Rgds, > > tge > > > > > > PS: Yes, the use case is that I want to have the chance to restrict > > access to my SOAP server to local clients only (in a configurable way). > > A user of my app may want this ... > > > > > > On Mon, 2010-06-14 at 15:18 +0530, Damitha Kumarage wrote: > > > Thomas Gentsch wrote: > > > > Hi Damitha, > > > > > > > > many thx for your fast reply! Also, when re-reading my posting, it > > > > sounded a bit like a complaint - this was not my intention, sorry for > > > > that! > > > > > > > > Technically, yes, this would be for security reasons, to protect a > > > > server from remote access entirely. > > > > > > > This means you have a use case where you use the server internally > > > entirely? > > > > The advantages I see > > > > - very simple config + implementation (extending > > > > axutil_network_handler_create_server_socket should be no major problem, > > > > however I did not look at the calling code yet ... :-) > > > > - all config is in my own hands whereas setting up a firewall I have to > > > > ask other people (-> also a risk of breaking something) > > > > > > > > If I can formulate a wish, I'd prefer a way to set this programmatically > > > > similar to the port in axis2_http_server_create_*() but probably > > > > axis2.xml would be a nice place too (like "port"). > > > > > > > I think it is better to pass a server start parameter like -i (run > > > server internally) to do that. > > > > If you feel, this would help, I'm happy to contribute. > > > > > > > Please send a patch. > > > Thanks, > > > Damitha > > > > Many thx + best regards, > > > > tge > > > > > > > > On Mon, 2010-06-14 at 09:24 +0530, Damitha Kumarage wrote: > > > > > > > >> Thomas Gentsch wrote: > > > >> > > > >>> Hello there, > > > >>> > > > >>> I was trying to find out whether there is any way to set up a SOAP > > > >>> server to listen only at 127.0.0.1 instead of * but could not find any > > > >>> to do this. > > > >>> Even worse, looking at the source in > > > >>> axutil_network_handler_create_server_socket() which appears to be the > > > >>> place, where this would happen, it seems as is this is not possible at > > > >>> all. > > > >>> > > > >>> > > > >> The simple reason you need your server only listen to 127.0.0.1 must > > > >> be > > > >> security. > > > >> But you can configure firewall to prevent access to port on all IPs > > > >> other than 127.0.0.1. > > > >> If this option is necessary we can implement it in > > > >> axutil_network_handler_create_server_socket() > > > >> as you suggested. > > > >> > > > >> Thanks, > > > >> Damitha > > > >> > > > >>> Am I missing something? If this is really the case, are there any > > > >>> plans > > > >>> to add this? > > > >>> > > > >>> Many thx + regards, > > > >>> tge > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> --------------------------------------------------------------------- > > > >>> To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org > > > >>> For additional commands, e-mail: c-user-h...@axis.apache.org > > > >>> > > > >>> > > > >>> > > > >>> > > > >> > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org > > > > For additional commands, e-mail: c-user-h...@axis.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: c-user-unsubscr...@axis.apache.org For additional commands, e-mail: c-user-h...@axis.apache.org
