[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SOAPAction Expansion Issues (HTTP_ORIG_SHORTFIELD Logic Seems Flawed)



Hi Ron,

Unless you changed the code, version 1.24 should allow up to 16k for 
SoapAction out of the box.  No need to change anything, or define or 
undefine anything...

The /define stuff is some tricks that I coded in order to preserve 
backward compatibility.  So existing callers can use HTTPAPI without 
recompiling, and they'll still work.

Don't mess with it.  Just use it as-is, and it will work.


On 4/18/2011 12:37 PM, Ron wrote:
>
>     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
-----------------------------------------------------------------------