In my ASP.NET application, I'd like to set limits on the maximum size of an \nuploaded file. Normally I'd just \n\nset the maxRequestLength of the httpRuntime element in web.config. But in \nthis case, I have a few different \n\naspx pages and I want the limit set differently for each. Yes, I could put \neach in its own folder, each with \n\nits own web.config, but that is rather awkward for this application.\n\nAlternatively, I could leave the limit set in web.config to the largest \nlimit, and then in the other pages, \n\ndo my own checking, throwing an error if the ContentLength was too large. \n\nBut if the goal here is preventing a DOS attack on my server by someone who \nis uploading lots of giant files, \n\nmaybe this is too late. That is, by the time my code gets to run, maybe the \ncontent is already all uploaded \n\nand has consumed the server resources. I'd rather be able to stop things \nearlier in the process.\n\nLooking at some Reflector code, it appears that the method \nRequest.GetEntireRawContent is actually doing the \n\nreading of the input stream, and this is called very early in page handling, \nby the first reference to the \n\nForm contents. But I'm not sure I'm reading this correctly. If I look at \nRequest.InputStream at PageLoad \n\ntime, it says that it is still at position 0. Does that mean that the \ncontent really hasn't been streamed in \n\nyet? \n\nAlso I wonder what I can trust. The simple thing is just to check \nRequest.ContentLength, but I assume that a \n\nbad guy can just fake that to be a small number. Is the InputStream length a \nreal number that can be trusted?\n\nAny suggestions would be appreciated.