Async Upload Encoding Error

Albert Shenker

From time to time I see the following error caught in our system's error logs:

The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or a non-white space character among the padding characters.
at System.Convert.FromBase64String(String s)
at Telerik.Web.UI.CryptoService.Decrypt(String encryptedString, String password)
at Telerik.Web.UI.AsyncUploadHandler.GetConfiguration(String rawData)
at Telerik.Web.UI.AsyncUploadHandler.EnsureSetup()
at Telerik.Web.UI.AsyncUploadHandler.ProcessRequest(HttpContext context)
at Telerik.Web.UI.HandlerRouter.ProcessHandler(String handlerKey, HttpContext context)
at Telerik.Web.UI.WebResource.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I haven't been able to tie it t any specific input or activity. Any idea what might be causing it?

Nencho

Such issue is probably caused by the fact that on some operating systems like MAC OS and Linux it is possible to have file names, which are invalid for the Windows File System. Files names can contain special characters or just don't follow the Microsoft's Naming Convention. Hence the encountered issue and the inability to upload a file occurs. Please refer to the following documentation article, which demonstrates how this behavior could be overcame:

Nencho

Implementing such extension of the functionality of the RadAsyncUpload will be unnecessary in most scenarios. This is why, we grant our customers with the ability to extend the functionality of the control using the approach, demonstrated in the previously referenced article.

Regards,
Nencho
Telerik

Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

Albert Shenker

I appreciate the fact that developers have a way to extend the Telerik controls and fix the issue. I'm not sure I understand why this isn't something that you guys would build into your controls, especially, since it looks like it would be very easy to do and doesn't appear like it will cause any breaking changes on your part. You're telling me that an entire universe of Mac users may run into this problem if their file names happen to have characters that Windows doesn't like. I'm sure this is not something that happens all the time, but still, the fact that it happens at all and may potentially affect a very large number of people, makes it seem like something that should be on your radar as a fix. The fact that you have a help file titled.. "How to upload files from Mac or Linux" is kind of startling to me. You guys go to great lengths to make your controls look and function right on different browser platforms, right out of the box. But you seem hesitant to take simple steps to make sure they work on different operating systems without developer intervention. Why is that?

Nencho

It was mymistake, failing toclarify another important reason for our decision, regarding the implementation of this functionality. With the demonstrated workaround, we provide our clients with the ability to escape the characters in question in a desirable manner, which won't be possible if we had hard-coded certain approach in escaping characters.

Regards,
Nencho
Telerik

Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

Albert Shenker

Your workaround is for developers to create a new handler class and override the ChangeOriginalFileName function. Developers can STILL do this if your internal implementation does not meet their needs. The fact is, right now you have NO internal implementation and a large segment of end-users are susceptible to errors. So, it is your position that, instead of fixing your internal code to avoid errors, it is better to leave it as is and allow end-users to experience errors, forcing developers to spend unnecessary time hunting for solutions in your help files and forums? I don't understand the thought process that leads to this conclusion.

Nencho

We understand your concerns and this is why I would suggest you to submit you suggestion in our public portal below, where it can be vote for and eventually implemented:
http://feedback.telerik.com/Project/108

Regards,
Nencho
Telerik

Check out the Telerik Platform - the only platform that combines a rich set of UI tools with powerful cloud services to develop web, hybrid and native mobile apps.

Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.