New Install: Stones app submits fail

[Windowless]

I installed WebBatch 2012 on IIS 7 using the instructions in the help file
I can start the stones.web page and it looks normal
When I click Take Stones, the WebBatch license page is displayed instead of the stones page
Any idea on what I need to configure?

[td]

Enter your WebBatch license information? You should have either a temporary or purchased license that is sent to you by email.

[Windowless]

It already is licensed.  It says this copy of WebBatch is licensed to...

[Windowless]

This may be due to the WebCGI user not having been added to Local Security Policy\Local Policies\User Rights Assignment:
    Adjust memory quotas for a process
    Create a token object

I'll have an admin add the user to those items in group policy for the server and we'll see what happens.

[td]

I have a version of Windows 2012 R2 running IIS 8.5 displayed on my other monitor as I type and the stones games works just fine.  Same is also true for Windows 2012 and IIS 8.0 I tried a bit ago.  Neither required adjustments to the IIS_IUSER privileges as set by default. 

Generally, if the stones game is working your installation is correct.  When you click on a the Take Stones button all you are doing is running the stones.web file again with a parameter.   The link that runs stones.web is on about line 14 of the stones.web file and should look something like the following:

Code (winbatch) Select Expand

WebOut('<FORM ACTION="/webcgi/webbatch.exe?stones/stones.web+%stones%" METHOD=POST>',1)

You might want to take a peek at it.  Someone or something may fiddled with the file.  Also note that calling WebBatch.exe without a script as a parameter will cause the WebBatch version (license) page to appear.

[Windowless]

Well, the User Rights Assignments had no effect.  We had gotten those from someone at WindowWare years ago because we run in a secure environment where the default policies are highly modified.  It would have been on the old board.

The url is http://<server>/webcgi/webbatch.exe?stones/stones.web+28
however, what displays is the license page.

We've seen this problem before but I don't recall what we had to change to get it to work.

[td]

IIS can be a pain...  Since you were able to run the script once, it didn't seem likely that the user rights you change should have an effect.  Although you never know for sure.  Often, this type of problem is the result of folder or file permissions.  But again, the browser is able to read the file once so why not the second time?   We will do some searching to see if we can find any information that might relate to a possible cause. 

[td]

You might want to take a look at the server log files for the site.  I may contain something useful.

[Windowless]

Environment:
Windows Server 2008/IIS 7
WebBatch installed to I:\Webs\anon\webbatch
Web Application created using an Application pool called WebCGI with an Identity using an unprivileged domain account
Authentication anonymous with anonymous impersonating the Application Pool
Confirmed that WebBatch starts under the impersonated identity when running stones.web
Confirmed that there are no ACCESS DENIED messages in ProcMon
Failed Request Tracing is enabled
No Failed Request Trace is created unless I force 200 to trace, then I get two identical files for the stones.web call
AND I get two more identical files for the Take stones post, which seems unusual. 
The browser only sees the initial stones app and then the license page on submission in Fiddler.

The main difference between the 200 trace files (besides the license content in the submission response) is that the first call is obviously a GET and the second is a POST

So, it would be helpful if WebBatch reported the failure that it is seeing internally that causes the license data to display.  I'm not suggesting there is a bug in WebBatch so much as w/o some sort of error message I don't know where the problem is.  It could be in the configuration of IIS.

[td]

If you would like to see the Stones game working on Windows 2008 and IIS 7.0 go to the following website (WebBatch's website):

http://webbatch.winbatch.com/webcgi/webbatch.exe?budu/stoneweber.web

WebBatch is installed in the manor describe in the Help file except that it is also using FastCGI although this is not necessary.  All WindowWare WebBatch based sites do use FastCGI.


WebBatch has several mechanisms for reporting error information.   Checkout the 'The Error Log file', 'WebBatch INI', and the 'Special Paramters' topic in the WebBatch help file.

The POST vs. GET difference may be the key but I would expect an error showing up in your browser, if it is.  You may want to check your handler mappings verbs by going to  IIS -> Sites ->your.site -> Handler Mappings -> Edit the CGI handler handling your requests -> Request Restrictions -> Verbs tab and make sure 'All verbs' is dotted.

Also note that IIS stores a record of every transaction in the <drive letter>:\inetpub\logs\LogFiles\W3SVC*  (* = site number) directory by default when logging is enabled.

[Windowless]

>> If you would like to see the Stones game working on Windows 2008 and IIS 7.0 go to the following website (WebBatch's website):

I've seen the sample app work before and it works on our other server.  This doesn't have to do with the stones app at all -- my web files do the same thing in response to a post: they show the license page.  The GETs all work fine.

>> You may want to check or handler mappings verbs...

It's already set to "All Verbs"

>> Also note that IIS stores a record of every transaction in the <drive letter>:\inetpub\logs\LogFiles\W3SVC*

An HTTP 200 response is "OK" response, so there won't be any useful information in the web log, which is why I ran the trace.

I see from old emails that there was someone name Marty Williams that helped me in the past.  Is he still there?
Also, is the old WebBatch forum still operational?  The answer may be there.

[td]

I've seen the sample app work before and it works on our other server.  This doesn't have to do with the stones app at all -- my web files do the same thing in response to a post: they show the license page.  The GETs all work fine.

It is obvious that it is not jut the Stones script but perhaps I didn't make the suggestion explicit enough.  You may be able to use your man-in-the-middle-tool to see what a working exchange looks like.

It's already set to "All Verbs"

Good.

An HTTP 200 response is "OK" response, so there won't be any useful information in the web log, which is why I ran the trace.

The logs contain a lot more information than just the simple text response by default and you can configure it to add even more information.

I see from old emails that there was someone name Marty Williams that helped me in the past.  Is he still there?
Also, is the old WebBatch forum still operational?  The answer may be there.

No and no.

We would like to help but since it is apparent that you are dissatisfied with the assistance offered as evidenced by the fact that you seem not to have tried some of the suggested problem solving strategies, you might want to try performing a Web search on IIS, CGI  and post vs. get.  Or something similar.

[Windowless]

Here is the W3 log data with all columns except cookies provided:

Code Select Expand

#Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
2016-02-05 23:09:28 W3SVC1 TEST 10.0.0.10 GET /webcgi/webbatch.exe stones/stones.web 80 - 10.0.0.18 HTTP/1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko - test 200 0 0 2728 7975 258
2016-02-05 23:09:28 W3SVC1 TEST 10.0.0.10 GET /webcgi/webbatch.exe dumpgif+stones/stone.gif 80 - 10.0.0.18 HTTP/1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko http://test/webcgi/webbatch.exe?stones/stones.web test 200 0 0 578 8058 154
2016-02-05 23:09:30 W3SVC1 TEST 10.0.0.10 POST /webcgi/webbatch.exe stones/stones.web+23 80 - 10.0.0.18 HTTP/1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko http://test/webcgi/webbatch.exe?stones/stones.web test 200 0 0 1423 8142 178
2016-02-05 23:09:30 W3SVC1 TEST 10.0.0.10 GET /webcgi/WEBBATCH.exe dumpgif+wblogo.dll 80 - 10.0.0.18 HTTP/1.1 Mozilla/5.0+(Windows+NT+6.1;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko http://test/webcgi/webbatch.exe?stones/stones.web+23 test 200 0 0 11116 8055 155


Here is the client log:

Code Select Expand


# Result Protocol Host URL Body Caching Content-Type Process Comments Custom
1 200 HTTP test /webcgi/webbatch.exe?stones/stones.web 1,901 text/html iexplore:3552
2 200 HTTP test /webcgi/webbatch.exe?dumpgif+stones/stone.gif 138 image/gif iexplore:3552
3 200 HTTP test /webcgi/webbatch.exe?stones/stones.web+18 983 text/html iexplore:3552
4 200 HTTP test /webcgi/WEBBATCH.exe?dumpgif+wblogo.dll 10,674 image/gif iexplore:3552


The client to server interaction is not a problem.  I can see the correct URLs are being sent/received on both the client and the server.  The server (webbatch.exe) is not responding to the POST correctly.  It seems to me that there are (only) two possibilities:
    1) IIS is not passing the POST through to WebBatch.exe
    2) WebBatch.exe is receiving the POST but is not processing it correctly

I'm not dissatisfied and don't know where you got that idea.
I don't believe that you have been explicit enough.  What have I not tried?

[td]

You haven't made any mention of using any of WebBatch and WIL error logging.  WebBatch error logging was mentioned several posts up in this topic and WIL error logging using DebugTrace is obviously also available. However, after reviewing your server log, I am not sure you could learn anything except to confirm what is already apparent.  IIS is not sending WebBatch anything on the command line, e.g., all the stuff after the question mark (?). 

The last server log entry is an indicator that something is grievously wrong because the WebBatch executable name is in all capitals but it is not in other lines of the log file.  WebBatch creates an all capital version of its name when it can't put the name using the Win32 API for some reason. 

I can't offer any additional advice at this time other than to delete your site in IIS and start over.  This sometimes actuallyt works because either the IIS UI or command line configuration tool does not always clear old settings after you change them. 

[Windowless]

I have reinstalled WebBatch 3 times and have recreated the app in IIS at least 3 times, so I'm going to assume that this is an IIS configuration problem with the POST verb.  There seem to be a lot of complaints in Google, but primarily with CGI/PHP GDI/Perl and the like.  All of the cases I have looked at so far are not promising, since they all had typical sorts of configuration problems.

I also downloaded the latest version of WebBatch and got a temporary license so that I could try an install on a newer OS/IIS.

FYI:
Regarding the IIS config not be saved, I have run into that before.  There is a documented issue where the restart IIS option should not be used because sometimes it will terminate IIS before the configuration changes have been saved.  The workaround is to stop the service from the Services management console and then to wait for it to stop before restarting the service.  As long as I have been using that approach, I have not had any issues with lost configurations.

[Windowless]

I shut down the IIS Admin and WWW services and manually scanned through applicationHost.config file looking for webbatch and found that I had a script-mapping that pointed to webbatch.exe.  I removed the line and POSTs started to work.  So, the gist is that one should not be tempted to enter an exe path in the Executable (optional) blank in the CGI module mapping.  Doing so causes the Module Mapping to turn into a Script Mapping, which makes the POSTs not work.  I don't know why this is the case, but all is good now.  Thanks for your help!

[td]

FYI:
Regarding the IIS config not be saved, I have run into that before.  There is a documented issue where the restart IIS option should not be used because sometimes it will terminate IIS before the configuration changes have been saved.  The workaround is to stop the service from the Services management console and then to wait for it to stop before restarting the service.  As long as I have been using that approach, I have not had any issues with lost configurations.

I have found several instances were were stopping and starting the service from either the Service applet or the IIS manager has not worked.   In these cases I have simply deleted the Web site (not just removed WebBatch CGI) and re-entered the information to fix a problem.  Of course a direct modification of the config file would also work.  But having used the UI to configure a site so many times, recreating a site that way seem trivial.

[td]

I shut down the IIS Admin and WWW services and manually scanned through applicationHost.config file looking for webbatch and found that I had a script-mapping that pointed to webbatch.exe.  I removed the line and POSTs started to work.  So, the gist is that one should not be tempted to enter an exe path in the Executable (optional) blank in the CGI module mapping.  Doing so causes the Module Mapping to turn into a Script Mapping, which makes the POSTs not work.  I don't know why this is the case, but all is good now.  Thanks for your help!

Glad you found a solution.  You see script mapping often used with php and to lesser extent Perl.  I have never been able to get it to work with WebBatch either.  It is most likely because IIS changes the way it communicates with CGI but have never taken the time to explore it.