RE: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic Seems Flawed)

["Ron" <ron@xxxxxxxxxxxx>]

   Scott,



   A little further testing and research and I believe I have discovered
   the issue. You used the following declarations code to allow for your
   "tricky" technique.

        D getSA           PR         16384A   varying
        D                                     ExtProc('GETREALSA')
        D   peSoapAction                 2a   const
        D getRealSA       PR         16384A   varying
        D   peSoapAction                 2a

   Since the constant parameter was only defined as 2A anything passed
   that point was being truncated. I changed that code to



        D getSA           PR         16384A   varying
        D                                     ExtProc('GETREALSA')
        D   peSoapAction             16384a   Const
        D getRealSA       PR         16384A   varying
        D   peSoapAction                 2a



   and that seemed to address the truncation issue. I admit I rushed
   through this change as I have people waiting on this but I think the
   fix was a proper one.



   Regards,

   Ron
     _________________________________________________________________

   From: Ron [mailto:ron@xxxxxxxxxxxx]
   Sent: Monday, April 18, 2011 12:38 PM
   To: 'ftpapi@xxxxxxxxxxxxxxxxxxxxxx'
   Subject: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic Seems
   Flawed)

   Scott,



   We have the need to support a larger SOAP action that the original
   specification of 64A. After some research it appears that you had put
   in some "hooks" to allow that through the definition
   of HTTP_ORIG_SHORTFIELD. It appears to convert to a larger 16384A
   varying parameter. I made the assumption that all I had to do was
   undefine HTTP_ORIG_SHORTFIELD and the rest would be taken care off. So
   that is what I did and began to run into issues. The first thing I ran
   into was that the actual procedure parameters did not match the
   procedure definition in the include module. Seems the same conditional
   logic was not in HTTPAPIR4 that was in the header file HTTPAPI_H. So I
   had to go in manually and deal with them. Now everything compiles.



   However now when I actually execute the code there seems to be a flaw
   in the getRealSA procedure. It still thinks I'm using the "old style"
   short parameter and only returns the first two bytes of the variable
   that was passed into the up stream procedure as a 16384A varying const
   parameter. Jut to clarify. If I pass in the default content type for
   example of 'text/xml' the lower level procedures receive only the
   first two characters 'te'.



   To make things even more confusing it seems that SOAP action is
   defined as 32767A varying in some places internally where I was
   expecting it too match the parameter size of 16384A varying
   (http_persist_get for example).



   I am on the BETA release 1.24.



   Before I address these issues myself (by removing all the logic that
   allows compability with the old 64A parameter) I would like to see
   what guidance you would provide.



   Regards,

   Ron

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------