RE: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic SeemsFlawed)

["Ron" <ron@xxxxxxxxxxxx>]

All is well with the world now. I understand how the trick works and have
adjusted my code accordingly. The only inconsistency that remains is the
size of the internal variable versus the parameter but that is not an issue
during execution. As usual Scott had his bases covered.

Ron 

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs
Sent: Monday, April 18, 2011 3:05 PM
To: HTTPAPI and FTPAPI Projects
Subject: RE: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic
SeemsFlawed)

Did you try using the soapaction with a varying field first before
modifying? The magic occurs without changing anything in the service
program...which version of 1.24 are you on? BETA6 and later have the changes
you need.

Of course, maybe there are a few places that still need changing but others
have found happiness with this mod.


> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi- 
> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Ron
> Sent: Monday, April 18, 2011 1:03 PM
> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic 
> Seems Flawed)
> 
> 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
-----------------------------------------------------------------------

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