So I have recently run into this on a site I am working on and I have seen a number of posts about the problem but very few decent solutions.  There is a decent post describing the problem here (http://choosing-a-blog-url-sucks.blogspot.com/2008/01/screen-bug-in-ie-with-aspnet.html#_ftn1_3541).  I have personally found deciding on an appropriate and secure workaround somewhat frustrating as most of the posts on the problem have not been terribly helpful.  I am going to try to outline the issues as best I can and give my personal solutions for people to comment on.  I want to start by saying I am neither an ISS or web security expert by any means so I would appreciate any critisims or corrections any of you have.

 Basically, what happens is if you have a website with SSL and "Accept Client Certificates" enabled HTTP requests are limited to the UploadReadAheadSize of the site.  If you go over the server returns a 413 error and the browser displays a blank page because IIS does not have a 413 error message page by default.  Overall I have found the responses and suggestions to the bug pretty ridiculous but lets start with a few things that are surprising about it.

1. <div mce_keep="true">The fact that this problem is tied into the UploadReadAheadSize and obscure server variable that requires you to run Admin Scripts to change it and is set by default to 48k</div>
2. <div mce_keep="true">The 48k limit is particularly comical since you can actually find single webpages that will violate this and cause the error.  Given how common SSL protected websites are you would think this would come up more often than it does</div>
3. <div mce_keep="true">The lack of any 413 error message for the client browser is also surprising, espeicially given how many posts I have seen regarding this error.</div>

 Moving past these obvious shortcommings there have been several solutions suggested to work around this.  The most common approach is to increase the size of UploadReadAheadSize.  The problem is that I want clients to be able to upload files as large as 10MB and >10MB seems far to large a valure for UploadReadAheadSize and will potentially open the server to some pretty serious DoS attacks as described in the blog link above.  This also has the unfortunate effect of still giving the client no useful error message when they go over the 10MB (or whatever I set UploadReadAheadSize to) limit.  This is pretty much where the suggestions stop though, there isn't much else that can be done to work around this.  I looked at several free FileUpload controls including NeatUploader (http://www.brettle.com/neatupload) but even that succumbed to this problem.

 So looking at the problem I different way I decided to set "Ignore Client Certificates" in ISS just for the two pages that handle the File Upload.  Bingo, problem solved, couldn't believe I didn't just try that in the first place.  The question is does this create any sort of security problem for the site now.  As I understand it (and I don't)  client certificates are not really important in most situations.  I mean clients typically do not have their own verified CA certificates right?  But then why was this problem occurring in the first place.  If the browsers I was using to test did not have special client certificates installed why were they acting as if they did?

 Anyways that is my solution to the problem, just setting "Ignore Client Certificates" on the aspx files that handle file uploads.  I am curious if anyone thinks there are any problems with this approach or if anyone can explain why client certificates are important in the first place.

Thanks,

Chris