I'm trying to send a vCard to my iOS using curl, but the vCard is not properly rendered in my iPhone.
EXCLAMATION_MARK='!'
curl -X POST https://api.twilio.com/2010-04-01/Accounts/<acc>/Messages.json \
--data-urlencode "Body=Test6$EXCLAMATION_MARK" \
--data-urlencode "MediaUrl=https://mighty-health-assets.s3.amazonaws.com/vcf/James.vcf" \
--data-urlencode "From=+14155926669" \
--data-urlencode "To=+14159108243" \
-u <acc>:<token>
I tried different Content-Type and Content-Disposition with my file.
For Content-Disposition:
inline; filename="James.vcf"
attachment; filename="James.vcf"
inline; name="James"
attachment; name="James"
For Content-Type:
text/vcard
text/x-vcard
text/vcard
text/vcard; charset=utf-8; name="fileName.vcf"
The result is always the same:
I'd like to have ideas on what to try next or if you already experienced the same issue before.
Troubleshooting problem
Turns out one of the configuration was correct, and the problem I was facing was a different one.
When Twilio receives a file for the first time, it caches
If you adjust the headers accordingly it won't impact the delivery of the VCF file, because it will use the cached version
There is a way to overcome that
Twilio Caching
To remove the caching on your files or to set the appropriate cache policy, read: https://support.twilio.com/hc/en-us/articles/360024716314-How-Can-I-Change-the-Cache-Behavior-or-Message-Media-Files-
Troubleshooting I figured out that Twilio don't change cache based only on filename for VCF files, but by the file content itself, so you have to modify your file in order for it to clear the cache, not just the name.
Correct configuration
In order to get the file properly parsed by an iOS phone, you can use the same file format as attached https://mighty-health-assets.s3.amazonaws.com/vcf/James+Li.vcf
Headers
The contact card on iOS can only display the same text as of your file, so name your file with the same filename header property on Content-Type and it should work accordingly
Content-Disposition: inline; filename="<You file name>.vcf"
Content-Type: text/x-vcard
Cache-Control: no-cache
Related
I use HTTPie to POST a
multipart/form-data request (passing the -f option). It includes a
file field (using a # option). The corresponding part of the
multipart request has a pseudo-header Content-Disposition, but does
not have a pseudo-header Content-Type.
How is it possible to add such a Content-Type for a specific file?
For completeness, here is what I send now (as shown by -p B):
--xyz
Content-Disposition: form-data; name="file"; filename="file.txt"
Hello, world!
This is the content of the file.
--xyz
but here is what I need to send:
--xyz
Content-Disposition: form-data; name="file"; filename="file.txt"
Content-Type: text/plain
Hello, world!
This is the content of the file.
--xyz
Or to put it another way, like the CURL equivalent option: -F "file=file.txt;type=text/plain".
This worked for me:
http -f POST :8080/submit-file metadata=#metadata.json files#file1.jpeg files#file1.jpeg
This documentation helped me: https://httpie.org/doc#file-upload-forms
The =# makes httpie send it with content type text/plain.
This isn't possible with httpie. There is an issue for it, with some pull requests to fix it, but none have been merged yet.
I have just noticed that the documentation for multipart/form-data now reads like the following (at the end):
When uploading files, their content type is inferred from the file
name. You can manually override the inferred content type:
$ http -f POST httpbin.org/post name='John Smith' cv#'~/files/data.bin;type=application/pdf'
I do not know when that happened, but it seems that now:
the "part Content-Type" is inferred automatically
it is possible to override it from the command line option
So all I was looking for! :-)
Ref: https://httpie.org/docs#file-upload-forms.
I have a COBOL batch program where I am able to send mail notification to an ID once my job is complete however, I also want to add an attachment in the mail of the processed file.
The following code attaches another mail as an attachment.
HELO SANTAANA
MAIL FROM:<abc#somting.com>
RCPT TO:<abc#something.com>
DATA
From: LandT P2P - LO <abc#something.com>
To: abc#something.com
Subject: File processed - Price_Change_10-27-15 07-08-44
MIME-VERSION: 1.0
CONTENT-TYPE: MULTIPART/MIXED;name="Price_Change_10-27-15.csv"
CONTENT-DISPOSITION: ATTACHMENT;
FILENAME="Price_Change_10-27-15 07-08-44.csv"
Note: I have also tried using SMTP and still does not work
Here is the sample of the mail i receive on running this code.
If you are generating the text of the email from within your Cobol program, which it sounds like, you would need to append another section, specify the Content-Type and Content-Disposition, filename and encoding, and then follow it with the properly encoded data, similar to this:
Content-Type: application/xml; name="Price_Change_10-27-15 07-08-44"
Content-Disposition: attachment; filename="Price_Change_10-27-15 07-08-44"
Content-Transfer-Encoding: base64
UEsDBBQABgAIAAAAIQDfrfoCnAEAAEcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
... and so on ...
I did notice that you had the content of those tags in upper case, that might be a problem. RFC1341 specifies those as "multipart/mixed" and "attachment" and so on. It is possible that your lack of mixed case is messing you up.
CONTENT-TYPE: MULTIPART/MIXED;name="Price_Change_10-27-15.csv"
CONTENT-DISPOSITION: ATTACHMENT;
FILENAME
Even easier than generating your own, have you looked into the excellent XMITIP package by Lyonel B. Dyck, it manages all that for you and you write a few config arms to control it, and you can easily call it from a Cobol program just like any other Rexx. Or you could add it to the end of your job stream as a separate step and make the task really easy.
I am using the Mail gem to send out emails with attachments from my application. Specifically, I have identical code living on my devbox and a server machine which is used to report a pdf file. However, pdfs sent as attachments from my devbox show up in Thunderbird and other clients fine, whereas attachments from the server show up only in SOME (not thunderbird) mail clients fine. I've opened the email source to compare the two and try to get some insight into the issue:
Devbox:
--_av-F3fhmdkLZDU59RCz4nm2gw--
--_av-ycGAp26idM_6kl-0lMcYmw
Content-Type: application/pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"
JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9MZW5ndGggNjc4L0ZpbHRlci9G
bGF0ZURlY29kZT4+c3RyZWFtCnic7Zhdb9owFIZ7S37FuZm0SZA53wkSF1Bg
...
MzBhN2RlZDE0ZmJkZDMwNzU1MzU2Y2ZhPjxlYTM0OTMzOTEwN2RmYzI1NTJh
NDE5NTJmNDhmN2MwMD5dL0luZm8gMzMgMCBSL1NpemUgMzQ+PgpzdGFydHhy
ZWYKNDE2NjQKJSVFT0YK
--_av-ycGAp26idM_6kl-0lMcYmw--
Server:
----==_mimepart_561d49a469c4d_33ee3fea57ad63b8624ae
Content-Type: application/pdf;
charset=UTF-8;
filename=report.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename=report.pdf
Content-ID: <561d49a46bc9f_33ee3fea57ad63b862596#autopilot-demo-east-web-1.mail>
JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9MZW5ndGggNjgwL0ZpbHRlci9G
bGF0ZURlY29kZT4+c3RyZWFtCnic7Zhdb9owFIZ7S37FuZm0SSVznJAPJC4o
oWs7qrVdql500xTAgNt8QGKg3a+fnQ5RbR3ttnYziQkR9jk+Pu95bEcKM+0V
nPjWcQ8WJMtpmjTBdI3RjQEnWcp9R/77tcfQbR19MW1u//Bxbe7RZH4Dpo51
..
N2I0MjdlNTE4ZTNmZGNmOGE5YzY1NTRjMzc+PGE1N2MzNmNkNTE0ZTQ1Mzlk
ZjY3OTU2ODZkY2M2ZDEzPl0vSW5mbyAzMyAwIFIvU2l6ZSAzND4+CnN0YXJ0
eHJlZgo0MTY2NgolJUVPRgo=
----==_mimepart_561d49a469c4d_33ee3fea57ad63b8624ae--
The simple line adding the attachment (Rails):
email.add_file filename: "sample.pdf", content: File.read("/public/sample.pdf")
Off the bat, the section identifiers are different (_av vs mimepart) and the way each attachment is encoded is also different after a few lines. My question is, what could be causing certain clients not to respect the "mimepart" sections as attachments? Beyond that, the next question would be why the same code would generate different output, but if I know the underlying issue I may be able to solve that myself. Thanks!
I'm trying to implement an odata consumer, specifically right now related to doing batch operations and change sets, following the odata documentation essentially loads to this sample multipart batch that I've used as a basis.
However when I actually run this batch code (via fiddler request builder for example) updated with my own entity paths and such, I receive the following error:
Error processing batch request. At the
start of every operation, exactly two
headers need to be specified:
'Content-Type' and
'Content-Transfer-Encoding'. Make sure
these headers are present and have the
correct values.
If I remove the Content-ID from the change set the change set works correctly, but obviously the later operations no longer work because they reference this Content-ID.
I've attempted to move the Content-ID header out of the change request multipart.. part headers, and into the actual part payload request headers, ie:
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 1
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
<AtomPub representation of a new Customer>
becomes
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
Content-ID: 1
Again this no longer complains about the change set having only headers, but still the later reference the content id fails with
HTTP 404, Resource not found for the segment '$1'
The request part which references this content-id looks something like this:
--changeset_7448d3fc-39f6-49bb-b822-30fa4a1676ce
Content-Type: application/http
Content-Transfer-Encoding: binary
POST http://example.org/test.svc/$1/$links/Resources HTTP/1.1
Content-Type: application/json
.. json ..
Assume that http://example.org/test.svc is the service root.
The documentation isn't very clear really about the format of the inner request locations, so the path reference may be incorrect.
Hopefully somebody has better understood this aspect and can advise, thanks in advance.
Stephen.
Turns out you cannot refer to a change set request if the operation in this way if the operation isn't a POST, this makes sense from the aspect that only POST methods really require this reference, but it would be useful to not need this branching logic.
Importantly however the path when referencing the Content-ID should not be absolute, but instead simply:
POST $1/$links/Resources HTTP/1.1
Content-Type: application/json
I am doing curl POST to a service with body containing some json data. I am getting the response as "request body was not mime-encoded as application/octet-stream". What does the response mean?
You probably need to supply a Content-Type header. Depending on what your web server is expecting, you might want to supply it either the mimetype "text/plain" or perhaps "application/x-www-form-urlencoded". In Curl, just include the argument:
-H "Content-Type: text/plain"
So your request will be something like:
curl -i -X POST --data-binary "#your.json" -H "Content-Type: text/plain"
Or substitute "text/plain" for the appropriate mime-type.
So, probably what's happening at the moment is that your web server is being given the content type application/octet-stream, and not understanding what to do with your plain text json content. If you run curl with "-v" it will give you a verbose description of the sent and received headers so you can see what Content-Type it's giving your server by default.
The input have to be a "application".
What you asking for is a mimetype.
Read more here: http://en.wikipedia.org/wiki/Internet_media_type
Please add more information for more informations.