Radi Atanassov

SharePoint MCM, MVP, MCT and owner of OneBit Software

Fun with HTTP Handlers, Security Validations, FormDigest, AllowUnsafeUpdates, jQuery, AJAX and POST parameters in SharePoint

Ever seen this error message?

System.Exception: Microsoft.SharePoint.SPException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.

It is usually related to a missing SharePoint FormDigest control, or updates to the DB on an HTTP GET request. You might hear people saying you should set AllowUnsafeUpdates to true, but in the case of a POST request that is not the best thing you could do. The best resource that you could ever read on the topic is written a while back (in 2008!) by a good friend of mine and ex colleague - Hristo Pavlov. These two posts are your best starting point if you want to understand what these items are for and how they achieve their purpose.

What You Need To Know About AllowUnsafeUpdates (Part 1)

What You Need To Know About AllowUnsafeUpdates (Part 2)

Generally speaking, AllowUnsafeUpdates = true on POST shouldn’t be required at all. I was working with my team on an HTTP Handler living in the SharePoint Layouts folder and it was failing with the security validation exception. In a typical ASPX web page you would include the SharePoint FormDigest control and SharePoint will handle it from there onwards:

<SharePoint:FormDigest runat="server"/>


You will notice the output of this control is a hidden <input> like this one:


<input name="__REQUESTDIGEST" id="__REQUESTDIGEST" type="hidden" value="0xDA527A96…A23,22 Apr 2011 14:17:06 -0000"/>


SharePoint will use this control (in particular the parameter __REQUESTDIGEST) and validate the “FormDigest”. You can explicitly call the SPUtility.ValidateFormDigest() helper method achieves the same. (See Hristo’s blog posts for more info on how it works). It basically takes the __REQUESTDIGEST value and validates it on the request object.


But in an HTTP Handler you don’t have the <SharePoint:FormDigest /> control as there is no ASPX. Developers can get the handler working by setting AllowUnsafeUpdates on the SPWeb object, but this should be avoided when it could (see Hristo’s post on why it is not good). If you are making a POST request, pass in the __REQUESTDIGEST and make sure you call the SPUtility.ValidateFormDigest() method before you do any DB updates.


If you want to call your handler asynchronously with AJAX, lets say with jQuery, this adds another level of complexity. You have to pass in the __REQUESTDIGEST parameter for SPUtility.ValidateFormDigest() to succeed. I personally found documentation on the $.ajax jQuery method quite poor, but here is a JavaScript example on how to use it and pass the __REQUESTDIGEST <input/> value:

function UploadFileAsync() {

    var listId = $("input[id$='hdnListID']").val();



        type: "POST",

        url: "/_layouts/Handlers/FileUpload.ashx?ListID=" + listId,

        contentType: "application/x-www-form-urlencoded",

        data: "__REQUESTDIGEST=" + $("#__REQUESTDIGEST").val(),

        timeout: 30000,

        success: function (response) {



        error: function (x, t, m) {

            if (t === "timeout") {

                alert("got timeout");


            else {






A few things are important and worth mentioning. In the “data” parameter I get the value of __REQUESTDIGEST and pass it in the POST request. (NOTE: you may want to improve the $(“#__RE..”) selector to get only input/hidden elements and be better performing). This will allow SPUtility.ValidateFormDigest() to pass successfully. If ever in doubt, open the request with Fiddler and validate the contents, you should see something like this:


The other important point is the contentType parameter. For me this did not work when set to “text/plain; charset=utf8”. I didn’t have enough time to figure out why, but “application/x-www-form-urlencoded” succeeded successfully.

Hope this helps!

Custom Upload Controls and the Maximum File Upload Size

If you’re creating a custom page or control that uploads files from a users PC (or somewhere else) you may get this error if the file is too big:

System.Web.HttpException: Maximum request length exceeded.

This is an ASP.NET error before the request is being handled by SharePoint (you can follow the stack trace to understand it a bit more). The challenge developers are facing is handling the exception and producing a nice & customized error message to users. You can easily overcome the problem by modifying the web.config of the Web Application, but that is not good practice and you have to worry about reproducing the modification for scalability and backup/restore purposes.

In a typical custom solution there is a nice solution to this problem. If you use Application Pages (those ASPX files that live in {SharePoint Root}\Templates\Layouts) you can place a web.config in your solution folder within the Layouts folder. Your web.config will go in:


Here’s what you need in the web.config:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>


  <location path="CustomUploadPage.aspx">


      <httpRuntime maxRequestLength="2097151" />




web.config’s are very flexible and the location element lets you apply your change exactly on the file that you need. This will work even if you are using an ASCX control located in the _CONTROLTEMPLATES folder. It is also a great approach as it can be packed into WSP’s and be part of an enterprise solution.

The number 2097151 is 2GB (boundary), the maximum SharePoint supported file size. It may be good to reduce this depending on your example.

The next point worth mentioning here is that the above setting alone won’t let you upload files over 50MB unless you configure the Web Application to allow it.


If the Web Application setting is below your file size you will get this exception:

Microsoft.SharePoint.SPException: The specified file is larger than the maximum supported file size.
NOTE: it has an ErrorCode of 2147024872

The good news is that you can handle the above exception with a simple Try…Catch, and that is all you need to facilitate a friendly, customized error message.

Hope this helps!