Web Services and Proxy Servers

[Neil Pate]

Hi All,

 

I have an application which uses a Web Service to talk to a LabVIEW based server, somewhere on the internet. The application works very well under normal circumstances, but I am having some trouble getting any comms through for one particular customer. The difference for this customer is that I know they use a proxy server for all web traffic. I have not had much exposure to proxy servers, but my understanding is that if I just prepend the proxy server IP address (or name) to the "address" of any http type requests everything should work fine.

 

So in other words, if I normally call http://mywebservice/testmethod then to get this to work with a proxy server I would just need to re-direct my request to http://myproxyserver/mywebservice/testmethod

 

Is this correct? If so there must be something else going on as I have tried this and still cannot get any comms going. The IT guy I am working with says none of the requests even get to the proxy server.

 

Has anybody done any work with Web Services and proxy servers?

 

 

[ShaunR]

Is this correct?

 

No.

What you are describing is merely prepending a sub domain name. Whilst sometimes people put a proxy on a sub domain, it's not a requirement. Besides, you may need to authenticate with the proxy.

 

Under normal conditions, the GET request URI is usually a relative path (doesn't have to be but is usually the case) and the HOST field of the HTTP header contains the domain of the target page. It's is slightly different with a Proxy.

 

The GET URI is the full URI of the target page (including the http:// and the domain name of the target page). The HOST field is the domain name of the proxy server and you connect to the proxy server, not the server that has the page.

 

A proxy may also require authentication and these parameters are also sent in the HTTP header fields (see section 2).

 

I don't believe any of the LabVIEW web oriented VIs support Forwarding Proxies (the sort I think you are describing) out of the box. I may be wrong and they added them in later versions, but  I haven't come across any. You might try Rolfs HTTP VIs, I can't remember off-hand if they support proxies and the OpenG site is down ATM so can't check, Apart from that I expect you will have to hand craft these headers and handle the responses the old fashioned way (and you will be stuffed if it is SSL/TLS).

[Neil Pate]

No.

What you are describing is merely prepending a sub domain name. Whilst sometimes people put a proxy on a sub domain, it's not a requirement. Besides, you may need to authenticate with the proxy.

 

Under normal conditions, the GET request URI is usually a relative path (doesn't have to be but is usually the case) and the HOST field of the HTTP header contains the domain of the target page. It's is slightly different with a Proxy.

 

The GET URI is the full URI of the target page (including the http:// and the domain name of the target page). The HOST field is the domain name of the proxy server and you connect to the proxy server, not the server that has the page.

 

A proxy may also require authentication and these parameters are also sent in the HTTP header fields (see section 2).

 

I don't believe any of the LabVIEW web oriented VIs support Forwarding Proxies (the sort I think you are describing) out of the box. I may be wrong and they added them in later versions, but  I haven't come across any. You might try Rolfs HTTP VIs, I can't remember off-hand if they support proxies and the OpenG site is down ATM so can't check, Apart from that I expect you will have to hand craft these headers and handle the responses the old fashioned way (and you will be stuffed if it is SSL/TLS).

 

Thanks for the insight Shaun. I do recall seeing Rolf's HTTP VIs, and this is what in fact lead me to believe I could just prepend the proxy, but probably I just misunderstood. I don't really know enough about this stuff so I guess it is time to learn something!

[ShaunR]

Thanks for the insight Shaun. I do recall seeing Rolf's HTTP VIs, and this is what in fact lead me to believe I could just prepend the proxy, but probably I just misunderstood. I don't really know enough about this stuff so I guess it is time to learn something!

Good news.Rolfs HTTP library does support Proxies! (without authentication).

The parser doesn't include the HOST in the header, though, so you should add that (trivial change). Servers have tightened up their security in recent years and the Host field is mandatory on most servers nowadays...

Edited June 8, 2014 by ShaunR

[Neil Pate]

Good news.Rolfs HTTP library does support Proxies! (without authentication).

The parser doesn't include the HOST in the header, though, so you should add that (trivial change). Servers have tightened up their security in recent years and the Host field is mandatory on most servers nowadays...

Cool! I will take a look at this a bit later today.

 

Thanks for your help

[Rolf Kalbermatter]

Good news.Rolfs HTTP library does support Proxies! (without authentication).

The parser doesn't include the HOST in the header, though, so you should add that (trivial change). Servers have tightened up their security in recent years and the Host field is mandatory on most servers nowadays...

 

Just a small note: I was only marginally involved in this library. The main developers were Jim and to some degree Heiko. I had at some point made my own version and likely posted them on some forum but if anything it only served as some inspiration for this library. 

 

Looking through my archives I found this library which is already quite old and not very well tested if I remember correctly. But it did implement the HTTP1.1 protocol including the HOST field. 

 

The top level VI is meant to be HTTP Site Downloader but I never got around to implement the actual parsing of the HTML document and adding its contained links to the download queue. But it serves as a good idea how the HTTP Parse URL and HTTP Download Link are meant to be used.

 

And yes it does not implement authentication either. I find basic authentication useless and the digest was a little bit complicated although I meant to get around to implement that eventually. 

 

It's LabVIEW 6.1 but should still be loadable by LabVIEW 2013.

HTTP.zip

[Neil Pate]

Hi Rolf.

 

I have cherry picked some of the good bits out of your library and put together a very simple application that uses the TCP prims (rather than the NI HTTP library) to do my Web Service query. It works fine from my PC (no proxy server), so now I need to wait and see if it works for my client.

 

Thanks!