Hello Simon,
My colleague Patrick is in vacation ... so I give some little more info.
I have not (yet) upgraded to new Firmware 13.1PR, and I used a 6 Kbyte image for this example to avoid known filesize issue.
We need to upload images to google bucket/cloud storage from an Ewon.
Choice 1:
https://cloud.google.com/storage/docs/js...art-upload
Choice 2 :
https://cloud.google.com/storage/docs/js...ple-upload
So far we didn't succeed in any of these choices.
for Choice 1, here I stand today:
StringBuffer headersBuf = new StringBuffer();
headersBuf.append("Authorization=Bearer ").append(accessToken);
StringBuffer urlBuf = new StringBuffer();
urlBuf.append("https://www.googleapis.com/upload/storage/v1/b/");
urlBuf.append(bucketName);
urlBuf.append("/o?uploadType=multipart/related");
urlBuf.append("&name=").append(pictureName);
StringBuffer fileFieldsBuf = new StringBuffer();
fileFieldsBuf.append("file=[$dtUF $uf");
fileFieldsBuf.append("/usr/index2.json");
fileFieldsBuf.append(" $fn").append(pictureName).append(".json]");
fileFieldsBuf.append("&file=[$dtUF $uf");
fileFieldsBuf.append(fileName);
fileFieldsBuf.append(" $fn").append(pictureName).append(".jpg]");
status = ScheduledActionManager.RequestHttpX(urlBuf.toString(), "POST", headersBuf.toString(), "", fileFieldsBuf.toString(), fileAnswer);
this more or less builds the content that almost matches google requirements, but not fully.
I capture the POST with tcpdump (used a local server instead of google as target) and we can see
a couple of issues :
1/ the top-level Content-Type is "
multipart/form-data" while Google expects "multipart/related"
2/ the two parts have also innacurate content type :
Content-Type: application/octet-stream
for google, should be :
Content-Type: application/json; charset=UTF-8 (for the JSON file)
Content-Type: image/jpeg (for the image)
3/ The file contents in the POST are OK (good news, we get the data we expected from the filesystem). but for json part should also be in plain text, as per google requierements.
So the question is how can we set the parts content type to match google expectations and actual MIME types of files we selected ?
Frame 67: 195 bytes on wire (1560 bits), 195 bytes captured (1560 bits)
Ethernet II, Src: ActL_46:4a:2a (00:03:27:46:4a:2a), Dst: HewlettP_61:37:da (e4:11:5b:61:37:da)
Internet Protocol Version 4, Src: 10.35.108.66, Dst: 10.35.108.77
Transmission Control Protocol, Src Port: 46593, Dst Port: 80, Seq: 6809, Ack: 1, Len: 129
[7 Reassembled TCP Segments (6937 bytes): #55(315), #57(187), #59(1448), #61(1448), #63(1448), #65(1962), #67(129)]
[Frame: 55, payload: 0-314 (315 bytes)]
[Frame: 57, payload: 315-501 (187 bytes)]
[Frame: 59, payload: 502-1949 (1448 bytes)]
[Frame: 61, payload: 1950-3397 (1448 bytes)]
[Frame: 63, payload: 3398-4845 (1448 bytes)]
[Frame: 65, payload: 4846-6807 (1962 bytes)]
[Frame: 67, payload: 6808-6936 (129 bytes)]
[Segment count: 7]
[Reassembled TCP length: 6937]
[Reassembled TCP Data: 504f5354202f75706c6f61642f73746f726167652f76312f...]
Hypertext Transfer Protocol
POST /upload/storage/v1/b/test-eric-altran/o?uploadType=multipart/related&name=index2 HTTP/1.1\r\n
Host: 10.35.108.77\r\n
Connection: TE, close\r\n
TE: trailers\r\n
Authorization: Bearer toto\r\n
Pragma: no-cache\r\n
Content-Type:
multipart/form-data; boundary=---------------------------7d624e177018a\r\n
Transfer-Encoding: chunked\r\n
\r\n
[Full request URI:
http://10.35.108.77/upload/storage/v1/b/...ame=index2]
[HTTP request 1/1]
[Response in frame: 69]
HTTP chunked response
Data chunk (179 octets)
Chunk size: 179 octets
Data (179 bytes)
Data: 2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d...
[Length: 179]
Chunk boundary: 0d0a
Data chunk (6298 octets)
Chunk size: 6298 octets
Data (6298 bytes)
Data: 2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d...
[Length: 6298]
Chunk boundary: 0d0a
Data chunk (116 octets)
Chunk size: 116 octets
Data (116 bytes)
Data: 6ba99e169b5b4828888f3bf6adbc388ad5ff000ae7ff004a...
[Length: 116]
Chunk boundary: 0d0a
End of chunked encoding
\r\n
File Data: 6593 bytes
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "---------------------------7d624e177018a"
[Type: multipart/form-data]
First boundary: -----------------------------7d624e177018a\r\n
Encapsulated multipart part: (application/octet-stream)
Content-Disposition: form-data; name="file"; filename="index2.json"\r\n
Content-Type: application/octet-stream\r\n\r\n
Data (22 bytes)
Data: 7b20226e616d65223a20226d794f626a65637422207d
[Length: 22]
Boundary: \r\n-----------------------------7d624e177018a\r\n
Encapsulated multipart part: (application/octet-stream)
Content-Disposition: form-data; name="file"; filename="index2.jpg"\r\n
Content-Type: application/octet-stream\r\n\r\n
Data (6212 bytes)
Data: ffd8ffe000104a46494600010100000100010000ffdb0084...
[Length: 6212]
Last boundary: \r\n-----------------------------7d624e177018a--\r\n
The other question is why changing the top level content type breaks everything ???
I justd added 1 line of code to better match google's requirements on top headers :
headersBuf.append("&Content-Type=multipart/related");
and the output is now :
Frame 31: 311 bytes on wire (2488 bits), 311 bytes captured (2488 bits)
Ethernet II, Src: ActL_46:4a:2a (00:03:27:46:4a:2a), Dst: HewlettP_61:37:da (e4:11:5b:61:37:da)
Internet Protocol Version 4, Src: 10.35.108.66, Dst: 10.35.108.77
Transmission Control Protocol, Src Port: 46597, Dst Port: 80, Seq: 1, Ack: 1, Len: 245
Hypertext Transfer Protocol
POST /upload/storage/v1/b/test-eric-altran/o?uploadType=multipart&name=index2 HTTP/1.1\r\n
Host: 10.35.108.77\r\n
Connection: TE, close\r\n
TE: trailers\r\n
Authorization: Bearer toto\r\n
Content-Type: multipart/related\r\n
Pragma: no-cache\r\n
Content-Length: 0\r\n
[Content length: 0]
\r\n
[Full request URI:
http://10.35.108.77/upload/storage/v1/b/...ame=index2]
[HTTP request 1/1]
[Response in frame: 33]
there is no more files uploaded.
Please tell us what can be done better with choice 1. Looks to me there are several issues at least on the MIME types which should be better handled by Ewon.
Now about choice 2, what are our options ?
From my attempts, as soon as we set the top header content type to anything, the whole file information is skipped by requestHttpX().
So do we need to read the file by ourselves in JAVA and provided this as the body String in requestHttpX() ?
I had a quick look to
https://techforum.ewon.biz/thread-217.htmlas an alternative, but it seems this will not work with HTTPS ?
AS you said :
Quote:If your Flexy/CD is connected to Talk2M, you can use the Custom HttpClient and the M2U service to convert HTTP to HTTPS (See https://developer.ewon.biz/content/https-m2u).
If not, you can use the functions com.ewon.ewonitf.ScheduledActionManager.GetHttp(...) or PutHttp(..) which support HTTPS but not the header customization.
If none of the solutions fit your application, let me know.
I guess we're exactly at this boundary .... none of the solution fits our application ... I'm not sure sending requests to google, with an Oauth bearer as identification through VPN/M2U is a good idea. this really adds complexity and one more service in the already complex stuff.
I'd really prefer that requestHttpX() helps us better formatting our requests so they can be accepted by google.
Thanks for your feedback.
Laurent
