|
Thanks. There is no proxy being used here, it's all internal. I would assume (maybe wrongly) that their IE apps don't have a proxy set up... I guess NAT is more of the norm these days. But I could ask. Brad On Mon, 29 Nov 2004 17:43:25 -0000 "Ian Patterson" <ian@xxxxxxxxxxxxxxxxxxxx> wrote: > Not sure if this helps, but when we were testing a > Windows based IP sockets > program connecting to the 'outside', the standard Windows > API's that handle > the routing (WinInet) take the defaults from IE. > So if a proxy setting existed in IE (say to use 8080) > this was also adopted > by our Windows program that wrote directly to sockets > using WinInet as the > comms API. > > > Regards > > Ian Patterson > > ian@xxxxxxxxxxxxxxxxx <mailto:ian@xxxxxxxxxxxxxxxxx> > > Grange IT Limited > tel 01947 880458 > www.grangesystems.com > > > > -----Original Message----- > From: midrange-l-bounces@xxxxxxxxxxxx > [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Brad > Stone > Sent: 29 November 2004 17:29 > To: Midrange Systems Technical Discussion > Subject: Re: Odd sockets problem? > > > 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 > -- > 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. > > > > -- > 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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.