Re: Odd sockets problem?

Well, we figured it out.

For some reason the server required the HOST header to be
set with a port number in it... 

So, when making the request to server1 on port 8080, if the
HOST header was just server1, it didn't work properly (and
returned the request from port 8081).  If the host header
was set to server1:8080 then it DID work properly.

I've never seen this..  Maybe a bug in websphere?  I
suppose I could look closely at the HTTP RFC, but I've
never seen this before.

I am still investigating to find out if they are running
one server with virtual hosts, or if they are seperate
servers bound to specific IP/Ports (which is what I think
they are).

Anyone care to comment on this?  :)

On Mon, 29 Nov 2004 13:25:17 -0500
 Jeff Silberberg <jsilberberg@xxxxxxxxxxxxxx> wrote:
> 
> Brad,
> 
>         On the iSeries use telnet to open a connect to
> each remote 
> connection and see what comes back as raw data.  telnet
> host:port
> 
>         But no tracert will not help with the ports
> issue, only to 
> identify which boxes/gateways you are routing through.
> An then only if icmp is not blocked on any of them.   But
> if it works, you will at least know where to start.  By
> the way,
> usually PORT Mapping is done in the box closest to the
> source or target of the conversation.
> 
>         JMS..
> 
> At 12:29 PM 11/29/2004, you wrote:
> >That is my thought, but I'm not sure how to tell him how
> to
> >look for those types of issues.
> >
> >Are there ways to do trace routes to particular ports?
>  And
> >if I have him do it from windows (dos), would it be the
> >same as from his browser?  Or would IE have anything set
> up
> >with it that would cause this sort of problem?
> >
> >On Mon, 29 Nov 2004 12:15:18 -0500
> > Jeff Silberberg <jsilberberg@xxxxxxxxxxxxxx> wrote:
> >>
> >> Brad,
> >>
> >>         Could you have a Firewall / NAT server doing
> some
> >> port mapping on
> >> either end ? Trace Routes..
> >>
> >>         His workstation with a browser, may be being
> >> handled different
> >> than the IP address in the AS/iSeries box. Depending
> on
> >> the rules along the way..
> >>
> >>         JMS...
> >>
> >> At 12:05 PM 11/29/2004, you wrote:
> >> >Ok, here's the scoop.
> >> >
> >> >I have a customer using my GETURI utility to work
> with
> >> web
> >> >services.  He is testing on some IntrAnet services.
> >> >
> >> >He says he has 2 enviroments set up.  One on port
> 8080
> >> >which is a test environment, and one on ports 8081
> and
> >> 80
> >> >which are production.
> >> >
> >> >>From a web browser, if he specifies port 8080 or
> 8081,
> >> he
> >> >gets the right server.
> >> >
> >> >But from GETURI, he says if he uses port 8080 or port
> >> 8081,
> >> >he always gets a response back from the 8081 (prod)
> box.
> >> >
> >> >I had him place a static document on each server.
>  The
> >> test
> >> >one said TEST, the Prod one said PROD.  He tested
> with
> >> the
> >> >browser, and got the appropriate document.
> >> >
> >> >He then tested with GETURI, and always got the PROD
> >> >document no matter if he specified 8080 or 8081 for
> the
> >> >port number.
> >> >
> >> >I've tripled checked the source, debugged, and
> couldn't
> >> >find any way that the port could be getting changed.
> >> >
> >> >I also had him test on my web site on port 80 and
> port
> >> 8080
> >> >which should reveal different results.  Port 80
> worked
> >> >fine, port 8080 resulted in no connection, most
> likely
> >> >because their firewall is blocking that port (which
> then
> >> >proves that the port GETURI was using works fine).
>  He
> >> got
> >> >the same results on his browser.
> >> >
> >> >I'm really pulling my hair out on this one.  I've got
> >> >hundreds of users using this without this problem, so
> >> I'm
> >> >leaning towards some sort of odd web server config
> (they
> >> >are running all websphere servers) or networking
> >> problem.
> >> > But I'm running out of ideas on where to look.
> >> >
> >> >What would cause his browser and GETURI (which uses
> >> sockets
> >> >APIS) to act differently?    Thanks for any ideas...
>  I
> >> >know there are a lot out there with more netorking
> know
> >> how
> >> >than me that could offer possible ideas.
> >>
> >> Jeffrey Silberberg
> >> CompuDesigns, Inc.
> >> Atlanta, GA. 30350
> >>
> >> As soon as I know the answers
> >> They change the questions !
> >> --
> >> This is the Midrange Systems Technical Discussion
> >> (MIDRANGE-L) mailing list
> >> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> >> To subscribe, unsubscribe, or change list options,
> >> visit:
> >> http://lists.midrange.com/mailman/listinfo/midrange-l
> >> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> >> Before posting, please take a moment to review the
> >> archives
> >> at http://archive.midrange.com/midrange-l.
> >>
> >
> >Bradley V. Stone
> >BVS.Tools
> >www.bvstools.com
> >--
> 
> Jeffrey Silberberg
> CompuDesigns, Inc.
> Atlanta, GA. 30350
> (770) 399-9464
> As soon as I know the answers
> They change the questions !
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com