Re: [Boost-users] [asio] communication with a remote apache tomcat service

Subject: Re: [Boost-users] [asio] communication with a remote apache tomcat service
From: Bill Somerville (bill_at_[hidden])
Date: 2009-03-09 10:23:16

jmpulido wrote:
> Hello all:
>
> I'm working on a client program which needs to communicate with a
> remote server using an http based protocol ,which running a service
> (java servlet under apache tomcat).  I developed it using the example
> in http://www.boost.org/doc/libs/1_38_0/doc/html/boost_asio/example/http/client/sync_client.cpp
> as reference.
>
> When testing on a local server with apache tomcat deploying the
> service, (http://localhost:8084) it worked fine, since I established
> the communication with the server with these statements:
>     tcp::resolver resolver(io_service);
>     tcp::resolver::query query("127.0.0.1", 8084);
>     tcp::resolver::iterator endpoint_iterator = resolver.resolve
> (query);
>
> It worked all right with that connection string, but when we deployed
> the service in a commercial remote server with apache tomcat
> preinstalled, the connection string has becomed something like this:
> "http://urltomyserver:8080/ServiceName"
>
> The problem here seems to be that I only can use tcp::resolver::query
> when I have an specific ip or url, and a connection port both
> separated but, apparently, now I need to specify the port within in
> the connection string.
>   

tcp::resolver::query query("urltomyserver", 8080);

should work.

What you send in the http protocol header is a different matter, asio 
knows nothing of the http protocol, it's up to you to build correct 
headers and responses.

> I couldn't make this work, and   tcp::resolver::iterator
> endpoint_iterator = resolver.resolve(query) always either can't
> resolve the query or it gets timeout.
>
> Is there anyway I could use a connection string with the port
> specified within, like "http://urltomyserver:8080/ServiceName" and
> make it work with tcp::resolver::query? Do I need to find an
> alternative? The second option would be very expensive in developing
> time terms, so I'm hoping you could help me to make this work.
>
> Thanks a lot :)
>
> José Manuel Pulido
>   
HTH
--
Bill Somerville