RE: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic Seems Flawed)

[Mike Krebs <mkrebs@xxxxxxxxxxxxxxxxxx>]

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
-----------------------------------------------------------------------