What causes this invalid length for a Base-64 char array

Question

I have very little chance of going here. I can’t reproduce this locally, but when users get an error, I get an automatic email exception notification:

Invalid length for a Base-64 char array. at System.Convert.FromBase64String(String s) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState) at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) at System.Web.UI.HiddenFieldPageStatePersister.Load() 

I tend to think that there is a problem with the data that is assigned to the viewstate. For example:

 List<int> SelectedActionIDList = GetSelectedActionIDList(); ViewState["_SelectedActionIDList"] = SelectedActionIDList; 

It is impossible to guess the source of the error without being able to reproduce the error locally.

If someone had experience with this error, I would really like to know what you learned.

Answer 1

I saw this error caused by a combination of a good viewstate and aggressive content filtering devices / firewalls (especially when working with K-12 schools).

We worked on this by storing Viewstate in SQL Server. Before going along this route, I would recommend trying to limit your use of the viewstate by not storing anything big in it and turning it off for all controls that it doesn't need.

Links for storing ViewState in SQL Server:
MSDN - PageStatePersister Review
ASP Alliance - An easy way to store viewstate in SQL Server
Project Code - ViewState Provider Model

Answer 2

After urlDecode processes the text, it replaces all the "+" characters with "" ... thus, an error. You just need to call this statement so that it is compatible with base 64 again:

  sEncryptedString = sEncryptedString.Replace(' ', '+'); 

Answer 3

I assume that something is too often encoded or decoded - or that you have text with multiple lines.

Base64 strings must be a multiple of 4 characters in length - every 4 characters represent 3 bytes of input. Somehow, the view state data sent by ASP.NET is corrupted - the length is not a multiple of 4.

Do you register a user agent when this happens? Interestingly, somewhere a bad browser? Another possibility is that the proxy does naughty things. Similarly, try to record the length of the content of the request so that you can see if this only happens with large requests.

Answer 4

 int len = qs.Length % 4; if (len > 0) qs = qs.PadRight(qs.Length + (4 - len), '='); 

where qs is any base64 encoded string

Answer 5

Try the following:

 public string EncodeBase64(string data) { string s = data.Trim().Replace(" ", "+"); if (s.Length % 4 > 0) s = s.PadRight(s.Length + 4 - s.Length % 4, '='); return Encoding.UTF8.GetString(Convert.FromBase64String(s)); } 

Answer 6

As mentioned above, this may be because some firewalls and proxies prevent access to pages that contain large amounts of ViewState data.

ASP.NET 2.0 introduced ViewState Chunking , which breaks the ViewState into manageable chunks, allowing the ViewState to pass through the proxy / firewall without any problems.

To enable this feature, simply add the following line to the web.config file.

 <pages maxPageStateFieldLength="4000"> 

This should not be used as an alternative to reducing the size of the ViewState, but it can be an effective backdoor for the "Invalid length for Base-64 char array" error caused by aggressive proxies, etc.

Answer 7

Take a look at your HttpHandlers. Over the past few months after implementing the compression tool (RadCompression from Telerik), I noticed some strange and completely random errors. I noticed errors like:

• System.Web.HttpException: Unable to validate data.

• System.Web.HttpException: Client disconnected .---> System.Web.UI.ViewStateException: Invalid view state.

and

• System.FormatException: Invalid base-64 char array length.

• System.Web.HttpException: The client is disconnected. ---> System.Web.UI.ViewStateException: Invalid view state.

I wrote about this on my blog.

Answer 8

This is due to the huge state of the performance. In my case, I was lucky since I did not use the viewstate. I just added enableviewstate="false" to the form tag, and the view state went from 35k to 100 characters

Answer 9

This is not an answer, unfortunately. After a break in the intermittent error, and finally annoyed enough to try to fix it, I still have to find a fix. However, I have identified a recipe for reproducing my problem, which may help others.

In my case, this is TOTALLY a localhost problem on my dev machine, which also has an application database. This is a .NET 2.0 application that I am editing using VS2005. On a 64-bit Win7 machine, VS2008 and .NET 3.5 are also installed.

This will generate an error from many forms:

• Download a new copy of the form.
• Enter some data and / or postback using any of the form controls. Until there is a significant delay, repeat whatever you like and there will be no errors.
• Wait a bit (1 or 2 minutes, maybe no more than 5), and try another reverse gear.

A minute or two of delays are “Waiting for the local host”, and then “Connection was reset” by the browser and global.asax application error trap traps:

 Application_Error event: Invalid length for a Base-64 char array. Stack Trace: at System.Convert.FromBase64String(String s) at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState) at System.Web.UI.HiddenFieldPageStatePersister.Load() 

In this case, it is not the SIZE of the viewstate, but something like caching the page and / or viewstate, which seems to bite me. Setting <pages> enableEventValidation="false" and viewStateEncryption="Never" in Web.config did not change the behavior. Also did not set maxPageStateFieldLength something modest.

Answer 10

During the initial testing for Memberhip.ValidateUser with SqlMembershipProvider, I use the hash algorithm (SHA1) in combination with the salt, and if I changed the length of the salt to a length not divisible by four, I got this error.

I have not tried any corrections above, but if the salt changes, it may help someone to identify this as the source of this particular error.

Answer 11

In addition to the @jalchr solution that helped me, I found that when you call ATL::Base64Encode from a C ++ application to encode the content you pass to the ASP.NET webservice, you also need something else. In addition to

 sEncryptedString = sEncryptedString.Replace(' ', '+'); 

from @jalchr, you also need to make sure that you are not using the ATL_BASE64_FLAG_NOPAD flag on ATL::Base64Encode :

  BOOL bEncoded = Base64Encode(lpBuffer, nBufferSizeInBytes, strBase64Encoded.GetBufferSetLength(base64Length), &base64Length,ATL_BASE64_FLAG_NOCRLF/*|ATL_BASE64_FLAG_NOPAD*/); 

Answer 12

As John Skeet said, a string must be a multiple of 4 bytes. But I was still getting the error.

At least he retired in debug mode. Place a breakpoint on Convert.FromBase64String() , then execute the code. Miraculously, the error went away for me :) This is probably due to view states and similar other issues that others have reported.