Re: Some questions: peContentType and MFD encoder

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Thomas,

It would be nice if you could extend my existing MFD encoder to be more 
versatile.   But, I don't understand what you're suggesting is different 
about mine vs. what would be required for web service attachments?

Yes, the content-type parameter is too short.  (As is the SoapAction 
parameter).   In my opinion, this is a problem that needs to be fixed. 
But, I'm concerned about breaking backward compatibility.

My thinking is that I might do the following:

    D http_url_post   PR            10I 0 extproc('HTTP2_POST')
    D  peURL                     32767A   varying const options(*varsize)
    D  pePostData                     *   value
    D  pePostDataLen                10I 0 value
    D  peFilename                32767A   varying const options(*varsize)
    D  peTimeout                    10I 0 value options(*nopass)
    D  peUserAgent                  64A   const options(*nopass:*omit)
    D  peContentType             32767A   varying const
    D                                     options(*varsize:*nopass:*omit)
    D  peSoapAction              32767A   varying const
    D                                     options(*varsize:*nopass:*omit)

The general idea is that this new version of HTTP_url_post() actually 
calls a routine named HTTP2_POST under the covers.  (Note the EXTPROC). 
  This means that existing programs (unless they're recompiled) would 
call the existing HTTP_url_post().  When a program is recompiled, it'd 
use the new prototype.   The source shouldn't have to change (other than 
using the new prototype) since the same values you could pass to the old 
CotnentType and SoapAction fields should still be valid with this prototype.

That's what I'm thinking...   but, then again, I'd also like to remove 
the 'Timeout' and 'Useragent' parameters from the prototypes and make 
those be separate procedure calls.  They're not changed frequently, and 
I find having to specify them every time to be cumbersome -- but if I 
made THAT change, there's no way I could keep it backward compatible at 
the source level, you'd have to modify your code, or we'd have to use 
completely different procedure names (as we did with FTPAPI) which would 
be cumbersome as well.  So I may just keep those parameters intact....


thomas.raddatz@xxxxxx wrote:
> Hi Scott,
> 
> I am doing some tests regarding to web service attachments and now I got
> some questions that I want to ask you:
> 
> 
> 1. peContentType is too short to hold the information required for
> attachments. Is there some easy way to pass a longer "Content-Type" to
> HTTPAPI?
> 
> Content type of HTTPAPI encoder:
>    Content-Type: multipart/form-data;
> boundary=-httpapi-2008-05-16-14.12.10.864
> 
> Sample string needed for attachments:
>    Content-Type: multipart/related; type="text/xml"; start="<
> B2820000589318F0AF4C0004AC03A54A_wsdl2rpg@xxxxxxxxxxx>"; boundary="
> -httpapi-2008-05-16-14.12.10.864"
> 
> I probably found the answer for that: Exit point - HTTP_POINT_ADDL_HEADER
> 
> 
> 2. Since I cannot use your MFD encoder out of the box (wrong header
> information) I consider to write my own encoder based on your encoder. Do
> you agree with that or do you think we should change your encoder somehow?
> That might be reasonable in case that you already thought about to support
> different content types.
> 
> Your encoder:
> ---httpapi-2008-05-16-14.27.05.883
> Content-Disposition: form-data;
> name="B2820000589318F0AF4C0004AC03A54A_wsdl2rpg@tools400";
> filename="/home/Raddatz/ifs_test.txt"
> Content-Type: application/octet-stream
> 
> Hello World
> ---httpapi-2008-05-16-14.27.05.883--
> 
> Required:
> ---httpapi-2008-05-16-14.29.13.479
> Content-Type: text/xml; charset=UTF-8
> Content-Transfer-Encoding: binary
> Content-Id: <CCCAB00058C518F0AF4C0004AC03A54A_wsdl2rpg@xxxxxxxxxxx>
> 
> <soapenv:Envelope ...
> </soapenv:Envelope>
> ---httpapi-2008-05-16-14.29.13.479
> 
> 
> Regards,
> 
> Thomas.
> 
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------