files.create with string : bad contentType,

[jacquarg]

In MyAccount, I've got a file as a base64 string (extracted froma XML field from an API), and I wish to create a File with it, using nodeJS.
I use the "contentType" option, with value application/pdf, but, the created file isn't readable, my pdf reader complaining that the contentType is text/plain : https://github.com/jacquarg/cozy-konnector-libs/blob/83b44bc935910f82707c7cb3bed1360f993ebaa4/models/file.js#L39

I can give you easily some code to reproduce if you want.

[enguerran]

Thank you for the report.
There is something to trace in that part of code: https://github.com/cozy/cozy-client-js/blob/master/src/files.js#L29

[jacquarg]

I put some log around, and I don't detect any troubles in cozy-client-js : there : https://github.com/cozy/cozy-client-js/blob/master/src/files.js#L46 ; the contentType var has the expected value ( application/pdf ).

The problem come from the stack ? As the data are sent "as is" ( https://github.com/cozy/cozy-client-js/blob/master/src/files.js#L59 ) to the stack ; I imagine that the stack perform similar tests on "data" nature.

[ptbrowne]

What's the status on this issue ? It is blocking for the EDF app.

[nono]

@ptbrowne do you have some logs of the request?

[ptbrowne]

No I haven't tested yet, I wanted to know if there was some progress on this issue, if someone was working on it or not. I can take a look next week :)

[jacquarg]

@nono , I get some log on requests with wireshark :

POST /files/8455c0fd4044c0d58d1b373335003116?Name=201603_edf.pdf&Type=file&Executable=false HTTP/1.1
content-type: application/pdf
content-md5: 
date: 
if-match: 
authorization: Bearer eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJhY2Nlc3MiLCJpYXQiOjE0OTQ2MDczMDgsImlzcyI6ImNvenkudG9vbHM6ODA4MCIsInN1YiI6Ijg0NTVjMGZkNDA0NGMwZDU4ZDFiMzczMzM1MDAxOWE2Iiwic2NvcGUiOiJpby5jb3p5LmFjY291bnRzIGlvLmNvenkuYmlsbHMgaW8uY296eS5maWxlcyBvcmcuZmluZy5tZXNpbmZvcy5jbGllbnQgb3JnLmZpbmcubWVzaW5mb3MuY29udHJhY3Qgb3JnLmZpbmcubWVzaW5mb3MucGF5bWVudHRlcm1zIG9yZy5maW5nLm1lc2luZm9zLmhvbWUgb3JnLmZpbmcubWVzaW5mb3MuY29uc3VtcHRpb25zdGF0ZW1lbnQifQ.lpIfeBTH2Fy2X2hneoFQ52jaR4kg0AYXWqQ8ZtiaKKQNcnjNzHQuMJQdxrPjmE8mtL8I-AbQylMFyaojCNsnGQ
accept-encoding: gzip,deflate
user-agent: node-fetch/1.0 (+https://github.com/bitinn/node-fetch)
connection: close
accept: */*
content-length: 423876
Host: cozy.tools:8080

JVBERi0xLjQKJeLjz9MNCjEgMCBvYmoNCjw8DQovUjEwIDIgMCBSDQovUjEyIDMgMCBSDQo+Pg0KZW5kb2JqDQoyIDAgb2JqDQpbIC9TZXBhcmF0aW9uIC9QQU5UT05FIzIwMTcyIzIwQyAvRGV2aWNlQ01ZSyA0IDAgUiBdDQplbmRvYmoNCjQgMCBvYmoNCjw8

I truncate most of the pdf data, at the end.

[nono]

I tried to reproduce with curl: the content-type was rightfully set to application/pdf, not text/plain.

Can you try to fetch the metadata of the document that you have uploaded?

[ptbrowne]

The problem is that the content of the PDF is still in base64.

$ cat /tmp/201607_edf.pdf | base64 --decode > /tmp/tutu.pdf
$ open tutu.pdf

works well.

The connector needs to send the binary data to the stack.

[jacquarg]

Thank's @nono , @ptbrowne , as soon as I found one second, I apply these fixes in the EDF konnector, and I will close this issue !

Finally (and hopefully) it looks that everything works as expected with the Cozy.
I get fooled by the on drive files.