Do not trust server-provided content type for attachments

* Fixes a bug that caused some attachments to be labeled with the
  wrong content type and thus unable to be opened by local apps.
* When the attachment code was written, MimeTypeMap had very few
  entries, so we tried to get the mime type of Exchange attachments
  from the stream when the file was read off the server.  It turns
  out that the server's idea of mime type is unpredictable
* In the meantime, MimeTypeMap has been fleshed out, so we really
  do know the type in the vast majority of cases (and including all
  common document types)
* The fix is to remove the lines related to reading the mime
  type from the attachment stream
* Content type is set (properly) when attachment record is created.  See
  EasEmailSyncParser.getMimeTypeFromFileName() for details.

Fixes bug http://b/2182955

Change-Id: Iebb3de529df4548327d7112e1dedb3bd448462a4
This commit is contained in:
Andrew Stadler 2009-10-13 21:09:40 -07:00
parent 4e424a33c2
commit dee4e25320

View File

@ -299,7 +299,6 @@ public class EasSyncService extends AbstractSyncService {
if (status == HttpStatus.SC_OK) {
HttpEntity e = res.getEntity();
int len = (int)e.getContentLength();
String type = e.getContentType().getValue();
InputStream is = res.getEntity().getContent();
File f = (req.destination != null)
? new File(req.destination)
@ -338,7 +337,6 @@ public class EasSyncService extends AbstractSyncService {
: "file://" + f.getAbsolutePath();
ContentValues cv = new ContentValues();
cv.put(AttachmentColumns.CONTENT_URI, contentUriString);
cv.put(AttachmentColumns.MIME_TYPE, type);
att.update(mContext, cv);
doStatusCallback(msg.mId, att.mId, EmailServiceStatus.SUCCESS);
}