Alaska Software Inc. - Re: Problem with WAA error handling in Xbase++ 2.0
Username: Password:
AuthorTopic: Re: Problem with WAA error handling in Xbase++ 2.0
Thomas BraunRe: Problem with WAA error handling in Xbase++ 2.0
on Wed, 08 Oct 2014 09:39:28 +0200
xpost & fup2 public.xbase++.support.en

Hi Andreas,

> Drawback is that the package sniffer does not work when the components
> (gateway and server) communicate via the loopback device, they must run
> on different machines.

I know - currently I don't have the time to set this up.

> I can not remember that anything was done with the buffer management
> of the WAA (which seems to be affected).

Not sure if that is the case - but obviously something changed...

> Any chance for a description on how to reproduce this.

Basically create a package that uses a custom subclass of the html3 class,
add a ::prgError() method to that class which returns a simple HTML page.

I created the following small sample that just works perfectly fine with
1.82.294, but not with 2.x

HTML3 class:
------------

CLASS ErrorTest FROM HTML3

   EXPORTED:

   METHOD prgError

ENDCLASS

Method ErrorTest:PrgError(oError, oContext)
LOCAL cTemplate := ""
   cTemplate := MEMOREAD("WAA1ERR.HTM")

   cTemplate := STRTRAN(cTemplate, "<%var=WAA_PACKAGE%>"       , ::GetVar("WAA_PACKAGE"))
   cTemplate := STRTRAN(cTemplate, "<%var=WAA_FORM%>"          , ::GetVar("WAA_FORM"))
   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_DESCRIPTION%>" , ConvToANSICP(oError:description))
   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_OPERATION%>"   , oError:operation)
   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_GENCODE%>"     , STR(oError:gencode))
   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_OSCODE%>"      , STR(oError:oscode) )

RETURN cTemplate

Form function:
--------------

FUNCTION Test(oH)
LOCAL aVars, nI

   aVars := oH:GetAllVars()
   FOR nI := 1 TO LEN(aVars)
      IF VALTYPE(aVars[nI,2,1]) = "C"
         oH:Put(aVars[nI,1] +": " + aVars[nI,2,1] + "/" )
         aVars[nI,2,1] := ConvertCharset(aVars[nI,2,1])
         oH:Put( oH:GetVar(aVars[nI,1] ) + "<br>" )
      ENDIF
   NEXT

    Uncomment the following line to get an error:
    nI := "5" + ASC("5")

RETURN .T.


HTML Form:
----------

<HTML>
  <HEAD>
  <TITLE>Package test</TITLE>

  </HEAD>

  <BODY>
    <FORM ACTION="/cgi-bin/waa1gate.exe" METHOD=POST>
      HTML3 Class:&nbsp; 
      <input TYPE="text" NAME="WAA_HTML3CLASS" VALUE="errortest" SIZE="15" MAXLENGTH="25"><br>
      Package:&nbsp; 
      <input TYPE="text" NAME="WAA_PACKAGE" VALUE="testP" SIZE="15" MAXLENGTH="25"><br>
      Form:&nbsp;
      <input TYPE="text" NAME="WAA_FORM" VALUE="test" SIZE="15" MAXLENGTH="25"><br><br>
      <input type=submit value="Submit" >
    </form>
  </BODY>
</HTML>
Andreas HerdtRe: Problem with WAA error handling in Xbase++ 2.0
on Wed, 08 Oct 2014 20:44:18 +0200
Hi Thomas,

Having digged into the issue to some extend, this seems not a problem of the 
WAA server.

What gateway are you using, is it the .exe or the .dll|.isa gateway?

Can you spend the time to test with a gateway from an earlier Xbase++ 
version?

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:138claid6bqnj.wzso7j7yzpbk$.dlg@40tude.net...
> xpost & fup2 public.xbase++.support.en
>
> Hi Andreas,
>
>> Drawback is that the package sniffer does not work when the components
>> (gateway and server) communicate via the loopback device, they must run
>> on different machines.
>
> I know - currently I don't have the time to set this up.
>
>> I can not remember that anything was done with the buffer management
>> of the WAA (which seems to be affected).
>
> Not sure if that is the case - but obviously something changed...
>
>> Any chance for a description on how to reproduce this.
>
> Basically create a package that uses a custom subclass of the html3 class,
> add a ::prgError() method to that class which returns a simple HTML page.
>
> I created the following small sample that just works perfectly fine with
> 1.82.294, but not with 2.x
>
> HTML3 class:
> ------------
>
> CLASS ErrorTest FROM HTML3
>
>   EXPORTED:
>
>   METHOD prgError
>
> ENDCLASS
>
> Method ErrorTest:PrgError(oError, oContext)
> LOCAL cTemplate := ""
>   cTemplate := MEMOREAD("WAA1ERR.HTM")
>
>   cTemplate := STRTRAN(cTemplate, "<%var=WAA_PACKAGE%>"       , 
> ::GetVar("WAA_PACKAGE"))
>   cTemplate := STRTRAN(cTemplate, "<%var=WAA_FORM%>"          , 
> ::GetVar("WAA_FORM"))
>   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_DESCRIPTION%>" , 
> ConvToANSICP(oError:description))
>   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_OPERATION%>"   , 
> oError:operation)
>   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_GENCODE%>"     , 
> STR(oError:gencode))
>   cTemplate := STRTRAN(cTemplate, "<%var=ERROR_OSCODE%>"      , 
> STR(oError:oscode) )
>
> RETURN cTemplate
>
> Form function:
> --------------
>
> FUNCTION Test(oH)
> LOCAL aVars, nI
>
>   aVars := oH:GetAllVars()
>   FOR nI := 1 TO LEN(aVars)
>      IF VALTYPE(aVars[nI,2,1]) = "C"
>         oH:Put(aVars[nI,1] +": " + aVars[nI,2,1] + "/" )
>         aVars[nI,2,1] := ConvertCharset(aVars[nI,2,1])
>         oH:Put( oH:GetVar(aVars[nI,1] ) + "<br>" )
>      ENDIF
>   NEXT
>
>   // Uncomment the following line to get an error:
>   // nI := "5" + ASC("5")
>
> RETURN .T.
>
>
> HTML Form:
> ----------
>
> <HTML>
>  <HEAD>
>  <TITLE>Package test</TITLE>
>
>  </HEAD>
>
>  <BODY>
>    <FORM ACTION="/cgi-bin/waa1gate.exe" METHOD=POST>
>      HTML3 Class:&nbsp;
>      <input TYPE="text" NAME="WAA_HTML3CLASS" VALUE="errortest" SIZE="15" 
> MAXLENGTH="25"><br>
>      Package:&nbsp;
>      <input TYPE="text" NAME="WAA_PACKAGE" VALUE="testP" SIZE="15" 
> MAXLENGTH="25"><br>
>      Form:&nbsp;
>      <input TYPE="text" NAME="WAA_FORM" VALUE="test" SIZE="15" 
> MAXLENGTH="25"><br><br>
>      <input type=submit value="Submit" >
>    </form>
>  </BODY>
> </HTML>
Thomas BraunRe: Problem with WAA error handling in Xbase++ 2.0
on Thu, 09 Oct 2014 09:50:11 +0200
Andreas Herdt wrote:

> Having digged into the issue to some extend, this seems not a problem of the 
> WAA server.

So you can't reproduce this?

> What gateway are you using, is it the .exe or the .dll|.isa gateway?

Locally I'm using Apache 2.2.19 with the EXE gateway.

> Can you spend the time to test with a gateway from an earlier Xbase++ 
> version?

First I was using the gateway from an earlier version (which I modified,
but unfortunately I think I lost the modified C source).

Initially I thought that might be the cause for the problem - but then I
also tested with the current gateway version.

Meanwhile, I set up a virtualized Apache 2.2 on a VMWare Win7 host and
managed to capture the traffic between WAA and the gateway.exe with
Wireshark.

I created two captures, one with the custom html3 class and one with the
default class - the difference is a missing content-type header (this is
what the Apache error log says as well) in the response that is sent back
to the gateway, so IMHO the cause must be on the WAA side.

Capture with custom class:
--------------------------

0000  00 0c 29 4d 14 2c e0 69  95 4d f6 61 08 00 45 00   ..)M.,.i .M.a..E.
0010  08 f6 3c c8 40 00 80 06  00 00 c0 a8 00 15 c0 a8   ..<.@... ........
0020  00 56 07 e8 c0 32 10 92  45 f6 78 82 09 9b 50 18   .V...2.. E.x...P.
0030  01 00 81 c2 00 00 ca 08  00 00 c9 00 00 00 3c 68   ........ ......<h
0040  74 6d 6c 3e 0d 0a 3c 68  65 61 64 3e 0d 0a 3c 6d   tml>


Capture without custom class:
-----------------------------

0000  00 0c 29 4d 14 2c e0 69  95 4d f6 61 08 00 45 00   ..)M.,.i .M.a..E.
0010  09 04 3f c5 40 00 80 06  00 00 c0 a8 00 15 c0 a8   ..?.@... ........
0020  00 56 07 e8 c0 35 1d 75  90 eb 2f fb de e1 50 18   .V...5.u ../...P.
0030  01 00 81 c2 00 00 d8 08  00 00 c9 00 00 00 43 6f   ........ ......Co
0040  6e 74 65 6e 74 2d 54 79  70 65 3a 20 74 65 78 74   ntent-Ty pe: text
0050  2f 68 74 6d 6c 0a 0a 3c  68 74 6d 6c 3e 0d 0a 3c   /html..< html>

Attached the two Wireshark capture files so you can compare it yourself,
the IP addresses are as follows:

192.168.0.21 - my physical machine that runs WAA
192.168.0.86 - the virtualized Apache 2.2 machine

regards
Thomas

WAA-Capture Custom error handler.pcap
WAA-Capture Default error handler.pcap
Andreas HerdtRe: Problem with WAA error handling in Xbase++ 2.0
on Thu, 09 Oct 2014 13:47:30 +0200
Hi Thomas,

The reason why the apache web server shows the error page is because
when the error message is is created in the error handler (:prgError) then
the resulting html is not completed with an HTTP header - the html is
written straight forward back to the server.

You can try writing a minimal HTTP header to the stream, then the content
should be properly processed by the Apache web server:

METHOD MyHtml3:prgError( oError, oContext )
   LOCAL cReturn, cTemplate := ""
   cTemplate := MEMOREAD("WAA1ERR.HTM")

   /* fill your template here */

    Add HTTP header
   cReturn := ""
   cReturn += "Content-Type: text/html" + Chr(13)+Chr(10)
   cReturn += Chr(13)+Chr(10)
   cReturn += cTemplate
RETURN(cReturn)

This also explains what you have seen using WireShark and it also explains
the apache log file.

I am now facing the problem that I can see the same behaviour when using
the WAA version 355. Also in this case no HTTP header is send to the
server and therefore the Apache runs into an error and the IIS shows a
blank page.

Would you please tell me what WAA version you are using?

With my best regards,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:vo291gqur1ck$.q6rbkgtqyqbo.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> Having digged into the issue to some extend, this seems not a problem of 
>> the
>> WAA server.
>
> So you can't reproduce this?
>
>> What gateway are you using, is it the .exe or the .dll|.isa gateway?
>
> Locally I'm using Apache 2.2.19 with the EXE gateway.
>
>> Can you spend the time to test with a gateway from an earlier Xbase++
>> version?
>
> First I was using the gateway from an earlier version (which I modified,
> but unfortunately I think I lost the modified C source).
>
> Initially I thought that might be the cause for the problem - but then I
> also tested with the current gateway version.
>
> Meanwhile, I set up a virtualized Apache 2.2 on a VMWare Win7 host and
> managed to capture the traffic between WAA and the gateway.exe with
> Wireshark.
>
> I created two captures, one with the custom html3 class and one with the
> default class - the difference is a missing content-type header (this is
> what the Apache error log says as well) in the response that is sent back
> to the gateway, so IMHO the cause *must* be on the WAA side.
>
> Capture with custom class:
> --------------------------
>
> 0000  00 0c 29 4d 14 2c e0 69  95 4d f6 61 08 00 45 00   ..)M.,.i .M.a..E.
> 0010  08 f6 3c c8 40 00 80 06  00 00 c0 a8 00 15 c0 a8   ..<.@... ........
> 0020  00 56 07 e8 c0 32 10 92  45 f6 78 82 09 9b 50 18   .V...2.. E.x...P.
> 0030  01 00 81 c2 00 00 ca 08  00 00 c9 00 00 00 3c 68   ........ ......<h
> 0040  74 6d 6c 3e 0d 0a 3c 68  65 61 64 3e 0d 0a 3c 6d   tml>
>
>
> Capture without custom class:
> -----------------------------
>
> 0000  00 0c 29 4d 14 2c e0 69  95 4d f6 61 08 00 45 00   ..)M.,.i .M.a..E.
> 0010  09 04 3f c5 40 00 80 06  00 00 c0 a8 00 15 c0 a8   ..?.@... ........
> 0020  00 56 07 e8 c0 35 1d 75  90 eb 2f fb de e1 50 18   .V...5.u ../...P.
> 0030  01 00 81 c2 00 00 d8 08  00 00 c9 00 00 00 43 6f   ........ ......Co
> 0040  6e 74 65 6e 74 2d 54 79  70 65 3a 20 74 65 78 74   ntent-Ty pe: text
> 0050  2f 68 74 6d 6c 0a 0a 3c  68 74 6d 6c 3e 0d 0a 3c   /html..< html>
>
> Attached the two Wireshark capture files so you can compare it yourself,
> the IP addresses are as follows:
>
> 192.168.0.21 - my physical machine that runs WAA
> 192.168.0.86 - the virtualized Apache 2.2 machine
>
> regards
> Thomas
Thomas BraunRe: Problem with WAA error handling in Xbase++ 2.0
on Thu, 09 Oct 2014 16:52:05 +0200
Andreas Herdt wrote:

> You can try writing a minimal HTTP header to the stream, then the content
> should be properly processed by the Apache web server:

Thanks - that works... well, that was easy! 

> I am now facing the problem that I can see the same behaviour when using
> the WAA version 355. Also in this case no HTTP header is send to the
> server and therefore the Apache runs into an error and the IIS shows a
> blank page.
> 
> Would you please tell me what WAA version you are using?

Oh - the version I'm using is quite old - 1.82.294... never bothered
updating until I needed to run on Windows server 2012 - never change a
running system 

So something seems to have changed in-between those versions.

The question is now how to proceed, I can see the following options:

- Fix it internally on the WAA side of things, e.g. add the header after
prgError returns to the code that internally handles WAA runtime errors.

I feel this is the correct way to fix this because every other method that
returns html code to the browser does not have to set any headers.

- Fix it in the user code - then you need to update the documentation
regarding :prgError() and mention the need to add that header - probably
adding a sample class with extended error handling would help a lot.

One more thing:

There is an (undocumented) iVar html3:cContentType which I'm also using to
change content types when I send back XML responses to Ajax-driven
websites... shouldn't this be used when sending the return of prgError back
to the gateway?

I'm asking because this iVar is set correctly, just checked it via
debugger.

regards
Thomas
Andreas HerdtRe: Problem with WAA error handling in Xbase++ 2.0
on Thu, 09 Oct 2014 19:25:13 +0200
Hi Thomas,

Reading messages in this newsgroup I never would have imagined that we need 
to deal with a difference between 1.82 and 2.00.....

Of course this wrong behaviour is a shortcoming of the WAA server and must 
be corrected. In the meantime you need to set the content-type header with 
the message to be send back by the error handling. As soon as we will have a 
fix here, the drawback is that your headers will be seen on the webpage 
presenting the error message.

One idea comes to my mind: Do not set any HTTP headers but start your html 
content with two CR+LF combinations. CRLFCRLF seperates the header from the 
body. The Apache should be able to deal with such a content. If this works, 
you are forward compatible and preparred when we add header information as 
your  CR and LF are ignored by the web browser then.

I am not sure if the WAA is allowed to respect the contenttype member 
variable of the HTML3 object in case of an error. If a runtime error occurs 
then the reason for the error is not clear - I am not sure if any state 
information of the package can be considered to be reliable information.

Using the contenttype member variable for normal processing is OK - it's the 
only way to make the browser display non-html data correctly. What is 
missing here is a documented interface allowing manipulation. I fear that we 
will not invest into that before we are extending the WAA to use HttpRequest 
and HttpResponse objects the same way as it is done with CXP today. We will 
offer the old interfaces too then, but I can not say in what manor they are 
extended.

I hope this helps,

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:5j2e41kihfc$.1y1bio3kp5qxa$.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> You can try writing a minimal HTTP header to the stream, then the content
>> should be properly processed by the Apache web server:
>
> Thanks - that works... well, *that* was easy! <g>
>
>> I am now facing the problem that I can see the same behaviour when using
>> the WAA version 355. Also in this case no HTTP header is send to the
>> server and therefore the Apache runs into an error and the IIS shows a
>> blank page.
>>
>> Would you please tell me what WAA version you are using?
>
> Oh - the version I'm using is quite old - 1.82.294... never bothered
> updating until I needed to run on Windows server 2012 - never change a
> running system :-)
>
> So something seems to *have* changed in-between those versions.
>
> The question is now how to proceed, I can see the following options:
>
> - Fix it internally on the WAA side of things, e.g. add the header after
> prgError returns to the code that internally handles WAA runtime errors.
>
> I feel this is the correct way to fix this because every other method that
> returns html code to the browser does not have to set any headers.
>
> - Fix it in the user code - then you need to update the documentation
> regarding :prgError() and mention the need to add that header - probably
> adding a sample class with extended error handling would help a lot.
>
> One more thing:
>
> There is an (undocumented) iVar html3:cContentType which I'm also using to
> change content types when I send back XML responses to Ajax-driven
> websites... shouldn't this be used when sending the return of prgError 
> back
> to the gateway?
>
> I'm asking because this iVar is set correctly, just checked it via
> debugger.
>
> regards
> Thomas
Thomas BraunRe: Problem with WAA error handling in Xbase++ 2.0
on Fri, 10 Oct 2014 09:17:15 +0200
Andreas Herdt wrote:

> Reading messages in this newsgroup I never would have imagined that we need 
> to deal with a difference between 1.82 and 2.00.....

Always expect the unexpected 

> I am not sure if the WAA is allowed to respect the contenttype member 
> variable of the HTML3 object in case of an error.

IMHO it must do so - the return of the prgError-method is not different
in any way to other HTML content that other WAA packages return - it is
HTML and so it must have proper headers to be working.

> If a runtime error occurs  then the reason for the error is not clear - I
> am not sure if any state  information of the package can be considered
> to be reliable information.

Good point.

But then the internal code that calls prgError, receives the return value
and finally sends it to the gateway must take care of that 

> Using the contenttype member variable for normal processing is OK - it's the 
> only way to make the browser display non-html data correctly. What is 
> missing here is a documented interface allowing manipulation.

Yes, that would be good - what also is important is documenting
:Resetcache(), because without that, returning XML does not work.

Another thing that I was asking for a looooong time ago is to distribute
WAA including the source code - AFAIK WAA is written in Xbase++ 

That way we could learn a lot about using the httprequest / httpresponse
objects.

BTW - why was the gateway source removed from the professional
subscription?

regards
Thomas
Andreas HerdtRe: Problem with WAA error handling in Xbase++ 2.0
on Fri, 10 Oct 2014 11:34:35 +0200
Hi Thomas,

>> Reading messages in this newsgroup I never would have imagined that we 
>> need
>> to deal with a difference between 1.82 and 2.00.....
>
> Always expect the unexpected 

Not so funny. This wasted some time on our side. I should have asked
for the version you are using. I should always ask for that nifty detail 

> Another thing that I was asking for a looooong time ago is to distribute
> WAA including the source code - AFAIK WAA is written in Xbase++
>
> That way we could learn a lot about using the httprequest / httpresponse
> objects.
>
> BTW - why was the gateway source removed from the professional
> subscription?

For these questions please get in contact with info@alaska-software.com

>> If a runtime error occurs then the reason for the error is not clear - I
>> am not sure if any state information of the package can be considered
>> to be reliable information.
>
> Good point.
>
> But then the internal code that calls prgError, receives the return value
> and finally sends it to the gateway must take care of that 

Exactly.

A fix will be available in one of the next updates. I am not sure If it can
make it to the next one.

  Andreas Herdt
  Alaska Software

--------------------------------------------------------------------

Technical Support:      support@alaska-software.com

News Server:            news.alaska-software.com
Homepage:               http://www.alaska-software.com
WebKnowledgeBase:       http://www.alaska-software.com/kbase.shtm

Fax European Office:    +49 (0) 61 96 - 77 99 99 23
Fax US Office:          +1 (646) 218 1281
--------------------------------------------------------------------

"Thomas Braun" wrote in message 
news:975ekswckpuf$.zwup4i1nlc51$.dlg@40tude.net...
> Andreas Herdt wrote:
>
>> Reading messages in this newsgroup I never would have imagined that we 
>> need
>> to deal with a difference between 1.82 and 2.00.....
>
> Always expect the unexpected <g>
>
>> I am not sure if the WAA is allowed to respect the contenttype member
>> variable of the HTML3 object in case of an error.
>
> IMHO it *must* do so - the return of the prgError-method is not different
> in any way to other HTML content that other WAA packages return - it is
> HTML and so it *must* have proper headers to be working.
>
>> If a runtime error occurs  then the reason for the error is not clear - I
>> am not sure if any state  information of the package can be considered
>> to be reliable information.
>
> Good point.
>
> But then the internal code that calls prgError, receives the return value
> and finally sends it to the gateway must take care of that :-)
>
>> Using the contenttype member variable for normal processing is OK - it's 
>> the
>> only way to make the browser display non-html data correctly. What is
>> missing here is a documented interface allowing manipulation.
>
> Yes, that would be good - what also is important is documenting
> :Resetcache(), because without that, returning XML does not work.
>
> Another thing that I was asking for a looooong time ago is to distribute
> WAA including the source code - AFAIK WAA is written in Xbase++
>
> That way we could learn a lot about using the httprequest / httpresponse
> objects.
>
> BTW - why was the gateway source removed from the professional
> subscription?
>
> regards
> Thomas