This is a migrated thread and some comments may be shown as answers.

ContentType always application/octet-stream

25 Answers 2338 Views

AsyncUpload

This is a migrated thread and some comments may be shown as answers.

25 Answers, 1 is accepted

answered on 24 Aug 2010, 09:51 PM

quickwatch.png

It's always coming up with "application/octet-stream". I've attached a screen print of the quick watch window so you can see what in the UploadFile class. The file I uploaded is a csv file and I am using IE8.

Here is the code I'm using to get the information:

foreach (Telerik.Web.UI.UploadedFile file in AsyncUpload.UploadedFiles)

{

OLT.SimpleCRM.BLL.Import.File.Item attachment = OLT.SimpleCRM.BLL.Import.File.Item.NewItem();

attachment.File.FileName = file.GetName();

attachment.File.MIME = file.ContentType;

attachment.File.FileData = util.Cast.FileToBytes(fileLoc + file.GetName());

}

answered on 26 Aug 2010, 02:16 PM

Hi Chris,

I've managed to reproduce the problem, it seems that the Flash module sends the uploaded files with hard-coded content type which is application/octet-stream. I've logged the issue into our bug tracking system and we will try to get it resolved as soon as possible. I've also updated your telerik points as a token of gratitude for the report.

A possible workaround might be to manually set the ContentType based on the extension of the file. A list with the most common content types can be found here.

Regards,
Genady Sergeev
the Telerik team

Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items

answered on 18 Nov 2010, 04:38 PM

Hello guys,

Indeed, the content type fix didn't make it for the Q3 release. Please accept our apologies for the delay. The good news are that we are now working on the problem and Q3 Service Pack 1 will have the issue resolved. Also, the Silverlight module is now a default one, therefore RadAsyncUpload will automatically start adorning the uploaded files with a correct content type as long as the Q3 SP1 release is out.

Best wishes,
Genady Sergeev
the Telerik team

Browse the vast support resources we have to jumpstart your development with RadControls for ASP.NET AJAX. See how to integrate our AJAX controls seamlessly in SharePoint 2007/2010 visiting our common SharePoint portal.

answered on 07 Jan 2011, 09:58 AM

Hi guys,

It turned out that it is not that trivial to implement such feature in the Flash/Silverlight modules. The problem is that there is no way to force Flash/Silverlight to determine the content type based on the meta data of the file. The only way we found to do it, was to scan the selected file name, and match its extension against a list of a known mime types. While this is a good for a workaround, we haven't yet implemented it, but the task is in progress. It should be ready for the upcoming SP2 release. However, If the issue is urgent for you, I can prepare a workaround that you can use immediately.

Regards,
Genady Sergeev
the Telerik team

Browse the vast support resources we have to jump start your development with RadControls for ASP.NET AJAX. See how to integrate our AJAX controls seamlessly in SharePoint 2007/2010 visiting our common SharePoint portal.

answered on 07 Jan 2011, 03:27 PM

Thanks for keeping us informed, much appreciated.

For my project(s), this is essential for implementing versioning. Currently, we have told our clients that it is a known issue and just have versioning "off" until it is fixed.

My main issue is that items can be uploaded using the single uploader in the file explorer or a bulk uploader based on the asyncUpload. The single uploader works as expected.

I took a stab myself at some process for reading the extension of the file and determining the file type based on some list I found on the internet. I was through the major types (office products and pdf) and then compared against the data gathered through the single uploader by Telerik. The types were very different which does not solve the disparity between the two upload methods. Again, the users can upload now, but as our database grows it will become more difficult for us to implement versioning.

For me (don't know about other users), I can wait on the service pack. I can also code up myself an extension checker if given a list of what the Telerik File Explorer uses to populate the file type field so there isn't the disparity between the two upload methods.

Again, thanks for staying on top of this.

answered on 07 Jan 2011, 04:23 PM

Basically, the workaround you have described was what I used to start with when I reported the problem in August. I have a SQL Server table that contains a list of file extensions. Once the file is uploaded, we grab the extension and look it up in the SQL table. This gives us the flexibility to add new extensions at any time.

We also save a FK reference to the extension table in the Attachment (where we save the File) table inside of SQL. If a file extension is not found in the table, it sets the FK reference of the attachment record to the "unknown" extension. This way we can query and see if any "new" file extensions have been uploaded to that we don't have in the table. Then a update can be done once we've added the extension.

Here is a link to an excel file with the file extensions we have in the table.
http://www.outerlimitstech.com/MIME_Extensions.xlsx

Chris Straw

answered on 12 Jan 2011, 04:36 PM

Thanks for the reply, some issues with the list:

It has several mime type for common extensions. For instance, for excel spreadsheets the supplied list has:

.xls	application/excel
.xls	application/vnd.ms-excel
.xls	application/x-excel
.xls	application/x-msexcel

So, there is no guarantee that if we use a method to match to a list for multi upload that we will now match what was done through the single uploader.

I am going to try something now that could introduce a small margin of error possibility. Currently I check MIMe type, folder location, and file name to determine if a file is duplicate. I will remove MIME type checking so it is done ONLY on location and file name. Will report back if this does it for me.

answered on 24 Apr 2011, 09:17 AM

Hello,

Im having this problem as well. I haven't tested every filetype but so far uploading a .xlsx or a .docx file with RadAsyncUpload results in the file having ContentType = null.

When can we expect this to be fixed? Is this the same problem Kellie is describing?

I have temporarily applied this fix. Does this seem like an appropriate fix?

if (file.ContentType != null)

{

document.MIME = file.ContentType;

}

else

{

if (file.FileName.EndsWith(".docx", StringComparison.InvariantCultureIgnoreCase))

{

document.MIME = "application/vnd.openxmlformats-officedocument.wordprocessingml.document";

}

if (file.FileName.EndsWith(".xlsx", StringComparison.InvariantCultureIgnoreCase))

{

document.MIME = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet";

}