6

This past Monday we pushed out a new ASP.NET website to our production server for use by the public. One section of the site provides a wizard type interface, each step requesting a fairly small amount of input from the user. Each step of the wizard is it's own user control. As the user moves through the steps, their input is saved to the viewstate, the current control is hidden, and the next is made visible. They of course can go back if need be.

Overall, everything is running smooth given the amount of use we're seeing, but we have had two users call in to say that as they tried to move from one step to the next, they were given the message "Request Entity Too Large". I gathered all of their input, and went through myself trying to recreate the problem.

In both cases I went through several times, and everything worked without issue. During another test run, I got a phone call, and was sidetracked for about 5 minutes. When I went to pick up where I left off, I then got the same error. I then tried again, purposely waiting for a few minutes at one step in the process, and got the error again. This was a different step then where I had paused the last time.

I'm wondering if inactivity can actually contribute to the problem, and if increasing the "uploadReadAheadSize" value in IIS is the correct solution, or if we can somehow correct the problem in the application itself. Thanks.

Afz
  • 57
  • 1
  • 16
user1919569
  • 63
  • 1
  • 3

1 Answers1

8

We experienced a similar problem recently, and we made the following changes:

  1. Increased the uploadReadAheadSize (as you mentioned)
  2. Updated IIS7 SSL Settings to Ignore the Client Certificate.
Josh Mein
  • 26,372
  • 12
  • 72
  • 84
  • 3
    Thank you! Everything I had read so far, only made mention of increasing the uploadReadAheadSize value. In our case, simply setting the Client Certificate to "ignore" seems to have solved the problem. That setting was somehow set to "accept" on our new site. We compared to all of our existing websites, one of which has some very similar functionality and no problems, and found all other sites were set to "ignore". Since changing the setting in IIS, we cannot reproduce this error again. – user1919569 Dec 20 '12 at 20:17