| Re: strange behaviour of SOCKET [message #62024] |
Thu, 21 August 2008 06:23 |
pgrigis
Messages: 436
Registered: September 2007
|
Senior Member |
|
|
Allan Whiteford wrote:
> pgrigis@gmail.com wrote:
>> Hi folks,
>>
>> for some mysterious reasons, socket is not working anymore
>> for me. I can access files in my own internet domain (i.e.
>> harvard.edu)
>> but I cannot access files [i.e. readf on the unit given by socket
>> hangs]
>> outside that domain (using HTTP GET commands).
>> I tried spawn, 'wget ...' from the same command line and this can get
>> files from everywhere.
>> Notice that "socket" itself and printf,unit both work (or at least
>> do not give troubles), is only readf,unit that hangs.
>>
>> So the question is: how is socket different than wget?
>> If this is a firewall issue, what settings are causing this?
>>
>
> wget will use an environment variable called http_proxy. Try:
>
> echo $http_proxy
Thanks for your suggestions.
I checked and no such variable is defined, therefore I may not
be going through a proxy of that kind.
>
> and see what you get. If they recently introduced a web proxy then the
> above could have been set system-wide by your system admin.
>
> Assuming you can figure out what the proxy is, you can *probably* just
> ask socket to connect to this proxy and then ask for your file in the
> normal way. i.e. connect to your webproxy but send it a GET command
> containing a full URL at another domain.
>
>> I know this is not much information to go on, but this issue
>> seems pretty hard to track down, so I just though I could ask
>> here before trying more desperate measures...
>
> Another issue could be that the proxy is transparent and it's recently
> been updated and doesn't like the form of your GET commands. There is
> all sorts of extra rubbish you're supposed to supply (check the RFC) but
> that aren't usually necessary. Your proxy maybe just got a bit more
> picky - you'd expect an error message to come back from your read if
> this was the case but who knows.
I'll check with my sysadmins....
Ciao,
Paolo
>
> You can also just try using telnet:
>
>> telnet www.google.com 80
> Trying 216.239.59.99...
> Connected to www.google.com (216.239.59.99).
> Escape character is '^]'.
> GET http://www.google.com/
>
> which will cut IDL out of the loop but pretty much simulate what socket
> is trying to do.
>
> Thanks,
>
> Allan
>
>>
>> Ciao,
>> Paolo
>>
|
|
|
|
| Re: strange behaviour of SOCKET [message #62029 is a reply to message #62024] |
Thu, 21 August 2008 03:05  |
Allan Whiteford
Messages: 117
Registered: June 2006
|
Senior Member |
|
|
pgrigis@gmail.com wrote:
> Hi folks,
>
> for some mysterious reasons, socket is not working anymore
> for me. I can access files in my own internet domain (i.e.
> harvard.edu)
> but I cannot access files [i.e. readf on the unit given by socket
> hangs]
> outside that domain (using HTTP GET commands).
> I tried spawn, 'wget ...' from the same command line and this can get
> files from everywhere.
> Notice that "socket" itself and printf,unit both work (or at least
> do not give troubles), is only readf,unit that hangs.
>
> So the question is: how is socket different than wget?
> If this is a firewall issue, what settings are causing this?
>
wget will use an environment variable called http_proxy. Try:
echo $http_proxy
and see what you get. If they recently introduced a web proxy then the
above could have been set system-wide by your system admin.
Assuming you can figure out what the proxy is, you can *probably* just
ask socket to connect to this proxy and then ask for your file in the
normal way. i.e. connect to your webproxy but send it a GET command
containing a full URL at another domain.
> I know this is not much information to go on, but this issue
> seems pretty hard to track down, so I just though I could ask
> here before trying more desperate measures...
Another issue could be that the proxy is transparent and it's recently
been updated and doesn't like the form of your GET commands. There is
all sorts of extra rubbish you're supposed to supply (check the RFC) but
that aren't usually necessary. Your proxy maybe just got a bit more
picky - you'd expect an error message to come back from your read if
this was the case but who knows.
You can also just try using telnet:
>telnet www.google.com 80
Trying 216.239.59.99...
Connected to www.google.com (216.239.59.99).
Escape character is '^]'.
GET http://www.google.com/
which will cut IDL out of the loop but pretty much simulate what socket
is trying to do.
Thanks,
Allan
>
> Ciao,
> Paolo
>
|
|
|
|
| Re: strange behaviour of SOCKET [message #62032 is a reply to message #62029] |
Thu, 21 August 2008 00:12 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
pgrigis@gmail.com writes:
> Hi folks,
>
> for some mysterious reasons, socket is not working anymore
> for me. I can access files in my own internet domain (i.e.
> harvard.edu)
> but I cannot access files [i.e. readf on the unit given by socket
> hangs]
> outside that domain (using HTTP GET commands).
> I tried spawn, 'wget ...' from the same command line and this can get
> files from everywhere.
> Notice that "socket" itself and printf,unit both work (or at least
> do not give troubles), is only readf,unit that hangs.
>
> So the question is: how is socket different than wget?
> If this is a firewall issue, what settings are causing this?
>
> I know this is not much information to go on, but this issue
> seems pretty hard to track down, so I just though I could ask
> here before trying more desperate measures...
Sounds like maybe you are behind a web proxy, but I don't know how to
work around it. :-S
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@REMOVEcow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
