QMastor
8th January 2007 04:12 UTC

Using InetLoad Plugin With Port Number
Does anybody know if the InetLoad plugin takes exception to URLs that contain a port number?

eg. http://localhost:8080/index.html

I am attempting to use the plugin to test the validity of a user-provided URL, ensuring that it's pointing to a web service by POSTing to it, and checking the response.

So far, tests with a URL that does not contain a port number have worked successfully, but a URL that DOES contain a port number keeps returning "Server Error" messages. I tried opening the same URL in Internet Explorer (Because I know that the plugin uses IE behind the scenes), and it opened fine.

Below is a cut-down example of what I'm doing (With fake URLs), that includes a POST without a port number, and one with a port number. With actual URLs the first MessageBox will give an "OK" message, and the second an error.

!define NOPORT_URL "http://localhost/WebServicePath/Page.asmx"
!define PORT_URL "http://localhost:8080/WebServicePath2/Page.asmx"

Name "InetLoadTest"
OutFile "Test.exe"

!include "MUI.nsh"
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_LANGUAGE "English"

Section "Dummy Section" SecDummy
    ; Call the "Ping" method of the web service
    InetLoad::load /POST "" "${NOPORT_URL}/Ping" "$EXEDIR\TestURL.xml"
    Pop $1
    MessageBox MB_OK "$1"

    InetLoad::load /POST "" "${PORT_URL}/Ping" "$EXEDIR\TestURL2.xml"
    Pop $1
    MessageBox MB_OK "$1"
SectionEnd

Any help would be greatly appreciated.

Takhir
8th January 2007 07:38 UTC

Re-tested with Apache2 on port 8080

    InetLoad::load /post "login=ami&passwd=333" \
"http://localhost:8080/post.php?lg=iam&pw=44" "$EXEDIR\post.htm"
    Pop $0 # return value = exit code, "OK" if OK

- works correct, "OK" and post.htm content. "Server error" means connection to port was successfull, but server returned error and it is not 401...407. You can test it using Inetc::head to get raw http headers (but the same info should be in the server logs).
http://nsis.sourceforge.net/Inetc_plug-in

QMastor
8th January 2007 22:25 UTC

I will definitely do some more testing, but it seems a little strange that the second call is experiencing an error, when the two web services are basically the same (The same code, just running in two different places), and IE experiences no problems.

I had thought that it might be something to do with the way web services can sort of use Windows Integrated Security, but since both web services would be using it the same way, it didn't seem likely that only the second instance would error...

Anyway, I'll keep looking, and might be back.

QMastor
9th January 2007 02:49 UTC

OK, so far as I can determine, the discrepancy is actually being caused IIS. It would appear that a web service is allowed to accept standard URL-based (ie. No included data) POSTs from the same machine, but not from other machines.

This would be why the web service on my local machine (The one without a port number) worked correctly, but the one on another machine (Which just happened to have a port number) didn't.

Now my problem is working out how to send a valid SOAP request using the plugin, but hopefully somebody else has already worked out how to do this, and I can find it via some forum, Wiki, and/or Google searching. If not, I'll be back.

QMastor
10th January 2007 00:30 UTC

The InetLoad and inetc plugins are not SOAP-capable "as is", because they don't allow you to manually set the "Content-Type" header (Or in the case of SOAP 1.1, add a custom "SOAPAction" header).

I managed to get around this by downloading, modifying, and re-compiling the source code (Which is not as easy as it sounds since I'm not a C++ programmer), but ran into a slightly different problem relating to the use of Windows Authentication in the web service...

In order for the authentication to work, calls to the "InternetSetOption" function are required, passing values for "INTERNET_OPTION_USERNAME" and "INTERNET_OPTION_PASSWORD" (The username and password of the currently logged in user). The problem is, how do I go about getting these values? If I connect to the web service using IE it automatically sends these values for me, so presumably there must be some way of getting the information, but I can't seem to find it anywhere... :(

Takhir
13th January 2007 16:41 UTC

I added new option /header to Inetc, so now you can add or replace http request header. Also I reduces (a bit) flickering on plug-in exit - Backland' request.
Authentication - if server request this and login/pwd not defined in URL, plug-in should display common (IE) authentication popup and user can enter/confirm password. But this not work in silent mode. And you cannot get user's password as a text (I still hope :) ).