When I'm adding html file to the MFMailComposeViewController instance as an attachment the final email is generated with this attachment as embedded image on iOS7, however it worked fine on previous versions (iOS4, 5, 6).
[mailController addAttachmentData: fileData mimeType: #"text/html; Charset=utf-8" fileName:#"file.html"];
Final .eml content
<div><br><br>
<img src="cid:C7BFF544-754D-4322-A71C-12345667789" id="C7BFF544-754D-4322-A71C-12345667789"></div></body></html>
Content-Type: text/html; charset=utf-8;
name=file.html
Content-Disposition: attachment;
filename=file.html
Content-Transfer-Encoding: quoted-printable
Content-Id: <C7BFF544-754D-4322-A71C-12345667789>
When it is opened in gmail this attachment is displayed as 'not found' image.
It looks like native mail client treats this document as an embedded image however it's not.
I've tried to use different content-type combinations (application/pdf, charset-8/16) and it doesn't works. Only changing filename extension to for example '.shtml' resolves this issue. However changing filename is inapplicable for me.
Any thoughts?
Note: this application is built with iOS 6 SDK and XCode 4.
Do you have a signature being added to your email, like "Sent from my iphone" etc.?
Remove it and resend the email and attachment and see if the attachment suddenly appears.
There seems to be a problem with Apple Main and Outlook where Outlook will strip out attachments if there is any text added after the attachment has been added.
Sorry for the later response but shortly after posting I found an answer. Apple and Exchange have some issues and in order to fix this problem I had to make sure that all of the PDF docs I was adding to the message had more than one page. Simply removing the signature would work but was not valid solution. I appreciate the response and I hope this might help you as well. Just make sure the attachment has more then one page and everything will work great.
Related
There are some old questions regarding this topic, but the issue I'm facing is just some days old so thought to create a new thread.
I am using the content-disposition inline combined with filename to open a PDF file directly in Browser.
content-disposition: inline; filename="MyFile.pdf"
Until a couple of days ago it was working fine in Chrome and Firefox, (I know that in old IE versions the filename parameter wouldn't work in inline), PDF was opening in browser with the correct (provided) filename.
Now it seems like the filename parameter isn't working anymore even for Chrome and Firefox. The PDF is opened correctly but created with a name from the last part of the URL, which in my case is just pdf (https://.../pdf).
If I switch to attachment instead of inline the filename works fine, file gets downloaded with the correct filename. Issue is that I need to open the file in browser and not download it.
Is inline with filename not anymore possible in Chrome and Firefox?
I am facing very similar problem lately.
Strangely, when making a POST request for PDF document, the filename is ignored. But if I make a GET request, everything works like before. PDF is shown correctly and SaveAs also works with correct filename.
I ended up making a redirect on the server side, so the last request is a GET.
Another thing I noticed is, when the user clicks on the Download (Save As) button in the browser's PDF viewer, the server gets another request for the document and serves the content again. The Print command however does not make another request and prints the content already in the PDF viewer.
Hope this info helps, even if only to let you know, you're not the only one with this problem.
Edit:
It turned out, that POST and GET requests did not have anything to do with the problem. The problem was Cache-Control: no-store header that prevented the browser to store the PDF content and forced it to make another request for the PDF content at Save As command. The POST command was not formed correctly the second time which resulted in "Network Error".
I removed no-store from the header and now everything works fine.
The new header looks like this:
Cache-Control: no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0
I have found that in my environment, URLs containing basic authentication do not allow inline display of pdfs.
I'm sending an HTML email with linked images, like:
<img src="https://www.test.com/image.jpg">
When I open them on my iPhone Mail app it doesn't show the images, even though I have Mail set to auto-load images. Every other email I open auto-loads images. When I open them on my Mac Mail client they do load. Is there anything special I have to do in my HTML to get the images to load? I looked at my source compared to emails that I can see the images and they appear to be doing the same thing. Any ideas?
Thanks
It turns out this occurs if you use "HTTPS" for image links. Once I changed them to HTTP the images loaded fine. Thanks
My AMP pages are passing validation, but some images are 404'ing. When accessing the pages from my site, the images load correctly. However, when the pages are loaded from Google's AMP CDN (I believe they cache all the pages) certain images return 404s.
In the network tab, I noticed that the image GET requests are correct when on my site (content-type: image/png). Google's cached pages, on the other hand, make a GET request with content-type "text/html" for the images that don't load. The GET response is a basic HTML page indicating a 404.
It should be noted that several images do load successfully. They're stored in both an image folder, and remotely on a parse-server. Both image locations have successfully provided pictures, just not all the time; and I can't seem to find any inconsistencies that could cause some to respond 200, others 404.
I would greatly appreciate any tips for figuring this one out!
edit: Is it possible that Google hasn't cached the images yet? The page itself is definitely cached.
The problem is that you're using a relative path to the image instead of an absolute path. So the following <amp-img> tag,
<amp-img ... src="/images/city_images/633_Image.png">
needs to be
<amp-img ... src="https://chargehub.com/images/city_images/633_Image.png">
That should fix your issue.
When loading your sample link, I get a 404 for https://cdn.ampproject.org/ii/w1000/s/chargehub.com/images/city_images/633_Image.png. When I request the corresponding original image from your server, I see a Cache-Control: no cache header:
% HEAD https://chargehub.com/images/city_images/633_Image.png | grep Cache-Control
Cache-Control: no-cache
While I don't have any guesses about why other images that are also served with Cache-Control: no cache, like https://chargehub.com/logos/ChargeHub-Logo.png, do get cached, I would try instructing your web server to not set this header to see if that helps.
Problem located! The images were originally pulled off of Google's Image API. The API allowed me to specify a file format (I wanted .png's). Unfortunately, if the image Google had was a JPEG, they simply added a .png extension to it and returned it to me.
Basically, if the AMP-IMG was expecting example.png, it only works if example.png is truly png encoded (you can tell the encoding by opening the file in a text editor, PNG will have a "png" near the top).
In my case, example.png was actually example.jpg RENAMED to example.png (jpeg encoding still). Google's caching service doesn't like this, and returned a 404.
I simply renamed all my photos to .jpg extension, and then batch converted them to true .png's using Photoshop. Hope this helps if anyone else is stuck!
We have a web application which offers a file named L_2804071.key for download. The download works fine in Internet Explorer and FireFox but in Chrome it "loses" the filename and chrome does not seem to recognize the filename in the content-disposition header.
Here is the full header (identical in both browsers):
content-disposition: attachment; =?utf-16le?B?ZmlsZW5hbWU9TF8yODA0MDcxLmtleQ==?=
I don't know if this helps but if you decode =?utf-16le?B?ZmlsZW5hbWU9TF8yODA0MDcxLmtleQ==?= you get Wfilename=L_2804071.key which looks weird. Not sure where the "W" comes from but IE seems to work with it and downloads a file named L_2804071.key.
Fix the web application to return a Content-Disposition header field that follows the spec, your example is invalid (for starters, there's no "filename" parameter). Note that your example appears to use RFC2047-style encoding, which in general isn't used in Content-Disposition.
See http://greenbytes.de/tech/webdav/rfc6266.html for details.
I am a rookie. Recently, there is a weird thing happens to my site built on AWS. If I access it from my desktop, everything looks fine. However, when I switched to my mobile browser or other persons'= computers, it just displayed the source-code. Please save my ass from this annoying situation. Thanks in advance.
Try setting the Content-type as a actual response header:
res.setHeader('Content-type', 'text/html; charset=utf-8');
The <meta http-equiv> will only be parsed if the browser at least tries to read the file as text/html. If it opts to skip such a trial, as at least a few seem to do, then it'll just print out the file as text/plain.