Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>To recap, I was creating a URL that used a base-64 encoded parameter which was itself a Triple DES encrypted string. So the URL looked like http://[Domain_Name]/SDN1S2JkeXpyVW890 The link referenced a controller action on an MVC web site.</p> <p>The URL was then inserted into an HTML formatted email. Looking at the error log, we saw that around 5% of the public users that responded to the link were throwing an "invalid base-64 string error". Most, but not all, of these errors were related to the IE6 user agent.</p> <p>After trying many possible solutions based around character and URL encoding, it was discovered that somewhere in the client's process the url was being converted to lower-case - this, of course, broke the base-64 encoding (as it is uses both upper and lower case encoding characters).</p> <p>Whether the case corruption was caused by the client's browser, email client or perhaps local anti-virus software, I have not been able to determine.</p> <p><strong>The Solution</strong> Do not use any of the standard base-64 encoding methods, instead use a base-32 or zBase-32 encoding instead - both of which are case-insensitive.</p> <p>See the following links for more details</p> <p><a href="http://en.wikipedia.org/wiki/Base32" rel="nofollow">Base-32 - Wikipedia</a></p> <p><a href="http://mytenpennies.wikidot.com/blog%3abase-32-encoder" rel="nofollow">MyTenPennies Base-32 .NET Implementation</a></p> <p>The moral of the story is, Base-64 URL encoding can be unreliable in some public environments. Base-32, whilst slightly more verbose, is a better choice.</p> <p>Hope this helps.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload