Correct the proxy support for scriptrepository

[Gesner Passos]

#7438 introduced a bug in linux machines inside ISIS. The problem is that if the scriptrepository finds the http_proxy variable it will try to connect through this proxy. This is ok for external machines, but fails for internal machines because the proxy does not serve local addresses.

So, it is necessary to try to connect without proxy as well as a fall-back mechanism.

For windows this problem does not occur because we have used the function that investigate for an specific url wich proxy to use.

Tester: go directly to comment:6 (the others were reverted)

[Gesner Passos]

Fallback mechanism to connection through proxy

Try to connect to the server without proxy when the proxy fails.

It is related to downloading, uploading and deleting files inside the repository

(a bug was found as well, delete was not using the proxy).

re #7571

Changeset: 9811f773cedcec9492e47356b54807a80ad3962c

REMOVED

[Gesner Passos]

I could not try to test the upload and deleting right now. Only the download was tested.

As I have to go, I will test more tomorrow. But, if any one want's to have a go... it is already available to test. (I did not closed just because I did not perform more tests....)

[Gesner Passos]

Improve the implementation of the proxy for linux

Attempt to reproduce the same behaviour found in windows, where the proxy is defined to connect the remote_url. So, now, after finding the proxy setup in linux, it tries to connect to the remote_url server. If it fails, it means, that the proxy cannot be used to connect to the server. This attempt is done just one time. And the system knows wich proxy or no-proxy to use to connect to the script repository.

re #7571

Changeset: 75c3a3d1f123f00f6addf23e7bf407992c4caa26

REMOVED

[Gesner Passos]

Proxy support for delete

Correct what lack from #7438

re #7571

Changeset: 164345ec1d32cfa564c8065984e3579789a9e4ea

[Gesner Passos]

Correct the definition of the proxy required from HTTPClientSession

It was found that the error was that the HTTPClientSession required from setProxy only the host, passing the 'http::<host>' caused it to fail.

Now, the host and the port are being queried indirectly through Poco::URI, and this solves the issue. But, we considered that it was a good practice to test the connection, given that it will be tested only once in the startup of mantid and will be available afterwards.

re #7571

Changeset: 96159ec9b65f223a0a6a29152f43422475cca46e

[Gesner Passos]

Tester: (must be using linux/mac machines)

for code review, consider only the commits on comment:6 and comment:7. The others were removed. The branch is called: bugfix/7571_scriptrepo_proxy

If you have the scriptrepository installed and your are able to open Mantid and see these lines:

UpdateScriptRepository started
UpdateScriptRepository successful, Duration 0.19 seconds

This means that you were able to connect to the server and to download one file, wich means that the connection through proxy is working.

You may want to change the logger option to debug and restart Mantid to see if you are using or not proxy.

From my machine (internal to ISIS so does not need proxy), in order to simulate a connection that requires proxy, I changed ScriptRepository inside the properties file to point to an external server (www.google.com for example).

The error that I got from Mantid was not related to connecting through proxy but trying to download an existing file. (so, the proxy was ok). If you think this was a sane test, you may try it as well.

[Samuel Jackson]

Merge remote-tracking branch 'origin/bugfix/7571_scriptrepo_proxy'

[Stuart Campbell]

This ticket has been transferred to github issue ​8416