[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emulate cURL file upload with HTTP API
Thanks for the reply Scott..
I can certainly understand why you designed it the way you did. Makes
perfect sense.
I my case, I'm uploading less than 1K and the data is coming from the
DB. The vendor just doesn't offer any other interface. I was hoping
to avoid creating two different temporary IFS files.
It be fun to add the support for doing it in memory; but I'll have to
come back to that challenge when I have a little more time.
Charles
On Mon, Mar 24, 2014 at 1:45 AM, Scott Klement <[1]sk@xxxxxxxxxxxxxxxx>
wrote:
Charles,
The multipart/form-data (MFD) encoder is typically used when you
have
entire files to upload, sometimes many files in a single batch.
(The
original issue I wrote it for had more than a dozen files,
totalling
hundreds of megabytes, in a single upload.) I didn't think it
made
sense to use a variable in memory for this due to the large sizes
that
were expected. While I know that teraspace storage is capable of
handling those extreme sizes, I didn't think it wise to have a
single
process using that much RAM. At least, that was my thought at
the
time.
This does not mean that HTTPAPI cannot be extended to do this in
memory
going forward. An option could be added for this. Or, you could
even
do it yourself outside of HTTPAPI using the 'raw' routines.
HTTPAPI is
designed to be flexible and extensible.
But, to me, the question is whether this will really make a big
enough
difference to warrant the work?
On 3/23/2014 10:09 PM, Charles Wilt wrote:
So I found the http_mfd_encoder_xxxx routines...
Looking into them they would appear to be what I'm looking for..
But unless I'm missing something, it appears my desire to avoid
writing
to the IFS is doubly shot. The http_mfd_encoder_xxxx routines write
to
there own temporary IFS file, plus I have to write my data out to an
IFS file before using the http_mfd_encoder_addstmf() procedure..
It doesn't seem to me that HTTP API will breakup the transfer on the
boundaries like cURL did...But I'd assume that's not going to be an
issue.
Charles
On Sun, Mar 23, 2014 at 7:37 PM, Charles Wilt
[1]<[1][2]charles.wilt@xxxxxxxxx> wrote:
All,
I'm trying to integrate with a web service where I was given the
following cURL example:
Curl --form request=batch --form orderfile=@orderfilename
[2][2][3]https://somitctest1.richmondanalytics.com/rtdc.php -b
cookie-file
I downloaded cURL for windows in order to see what was going on.
The
cURL trace shows
=> Send header, 275 bytes (0x113)
POST /rtdc.php H
TTP/1.1..User-Ag
ent: curl/7.35.0
..Host: mlsom.ri
chmondanalytics.
com..Accept: */*
..Cookie: PHPSES
SID=uudk76dak41h
jqec4i0mk9ojo4..
Content-Length:
378..Expect: 100
-continue..Conte
nt-Type: multipa
rt/form-data; bo
undary=---------
---------------3
243c9a6b3e4a2c9.
...
<= Recv header, 23 bytes (0x17)
HTTP/1.1 100 Con
tinue..
=> Send data, 245 bytes (0xf5)
----------------
----------3243c9
a6b3e4a2c9..Cont
ent-Disposition:
form-data; name
="request"....ba
tch..-----------
---------------3
243c9a6b3e4a2c9.
.Content-Disposi
tion: form-data;
name="orderfile
"; filename="ord
er.txt"..Content
-Type: text/plai
n....
=> Send data, 85 bytes (0x55)
0000001|023510|B
R6315421|2014-03
-23-18.46.47.039
000..1|006033891
28|1..2|59762371
903|2
=> Send data, 48 bytes (0x30)
..--------------
------------3243
c9a6b3e4a2c9--..
<= Recv header, 17 bytes (0x11)
HTTP/1.1 200 OK.
.
I'm trying to understand what I'd need to do with HTTP API to
emulate
this.
As an added bonus, I'd really prefer to do directly from a variable
in
RPG without actually writing out an IFS stream file to send.
I feel I understand what's going on, I'm just not enough of an
expert
with HTTP API to know what I need to do inside HTTP API.
Thanks!
Charles
References
1. [3]mailto:[4]charles.wilt@xxxxxxxxx
2. [4][5]https://somitctest1.richmondanalytics.com/rtdc.php
--------------------------------------------------------------------
---
This is the FTPAPI mailing list. To unsubscribe, please go to:
[5][6]http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
References
1. mailto:[1][7]charles.wilt@xxxxxxxxx
2. [8]https://somitctest1.richmondanalytics.com/rtdc.php
3. mailto:[9]charles.wilt@xxxxxxxxx
4. [10]https://somitctest1.richmondanalytics.com/rtdc.php
5. [11]http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
This is the FTPAPI mailing list. To unsubscribe, please go to:
[12]http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
References
1. mailto:sk@xxxxxxxxxxxxxxxx
2. mailto:charles.wilt@xxxxxxxxx
3. https://somitctest1.richmondanalytics.com/rtdc.php
4. mailto:charles.wilt@xxxxxxxxx
5. https://somitctest1.richmondanalytics.com/rtdc.php
6. http://www.scottklement.com/mailman/listinfo/ftpapi
7. mailto:charles.wilt@xxxxxxxxx
8. https://somitctest1.richmondanalytics.com/rtdc.php
9. mailto:charles.wilt@xxxxxxxxx
10. https://somitctest1.richmondanalytics.com/rtdc.php
11. http://www.scottklement.com/mailman/listinfo/ftpapi
12. 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
-----------------------------------------------------------------------