ASP .Net Core 6 / IIS Server File Upload Restriction ?

Liyanage, Rangajeewa 25 Reputation points
2025-10-30T15:16:54.2866667+00:00

I’m running a .NET Core 6 web application hosted on IIS 10 on a Windows Server. One of the key features involves uploading Excel files via an <input type="file"> element, which are then saved to the application server.

However, I’ve encountered a puzzling issue: files smaller than 65 KB upload successfully, but larger files consistently fail. I’ve already configured the following settings in web.config to allow larger uploads:

  • maxAllowedContentLength (set well above the default 30 MB)
  • maxRequestLength
  • MaxJsonDeserializerMembers

Despite these configurations, the issue persists. Is there any other setting—either in IIS, ASP.NET Core, or the OS—that could be silently enforcing a lower file size limit and overriding these values?

Developer technologies | ASP.NET | ASP.NET Core
{count} votes

Answer accepted by question author
  1. SurferOnWww 4,951 Reputation points
    2025-10-31T23:29:56.2633333+00:00

    error : "Object reference not set to an instance of an object"

    When submitting formData to the server, I observed that if the total size of the uploaded files exceeds approximately 65 KB, the IList<IFormFile> files parameter is received as null on the server side.

    I’m unable to upload the full code at the moment

    If you cannot show the complete code which can reproduce your issue, please investigate by yourself why IList<IFormFile> is null.

    First, please investigate if the form data are properly sent from the client to tha server. To do so, please use the Fiddler or equivalent tool to capture the data sent from the client to the server. For example when the following data are sent using ajax,

    const form = new FormData();
    form.append('my_field', 'my value');
    form.append('my_buffer', new Blob([1,2,3]));
    form.append('my_file', fileInput.files[0]);
    

    the contents captured by the Fiddler look like below:

    enter image description here

    Please obtain the captured result by yourself and verify if the data are properly sent.

    1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
  1. Bruce (SqlWork.com) 82,061 Reputation points Volunteer Moderator
    2025-10-30T15:48:15.24+00:00

    .net core 6 (out of support) does not honor any web.config settings. the hosting module does, but the only relevant setting is the request timeout:

    https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config?view=aspnetcore-9.0

    for asp.net core, you configure hosting setting in code.

    https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/options?view=aspnetcore-9.0

    1 person found this answer helpful.
    0 comments No comments

  2. Danny Nguyen (WICLOUD CORPORATION) 5,405 Reputation points Microsoft External Staff Moderator
    2025-10-31T09:07:01.3533333+00:00

    Hi,

    A hard cutoff around 64–65 KB almost means maxAllowedContentLength isn't the issue ( as its default is ~30 MB). That tiny ceiling typically points to one of these two causes:

    1. IIS pre‑read buffer too small (uploadReadAheadSize, default 48 KB).
    2. A code or attribute limit set to 65536 bytes (MaxRequestBodySize = 65536 or [RequestSizeLimit(65536)]), or reduced multipart limits.

    Try these steps:

    1. Confirm placement: show just the <system.webServer> block with requestLimits.
    2. Search your codebase for any 64 KB cap: RequestSizeLimit, MaxRequestBodySize, MultipartBodyLengthLimit, 65536. Remove or raise if found.
    3. If no code limit found, add a diagnostic uploadReadAheadSize (keep it modest):
      
      	<system.webServer>
      
      		<security>
      
      			<requestFiltering>
      
      				<requestLimits maxAllowedContentLength="104857600" />
      
      			</requestFiltering>
      
      		</security>
      
      		<serverRuntime uploadReadAheadSize="1048576" /> <!-- 1 MB test -->
      
      	</system.webServer>
      
      
    4. Ensure you’re using a plain multipart/form-data upload (not Base64 in JSON).
    5. Retest a >70 KB file; if it now succeeds, keep a reasonable buffer (256 KB–1 MB). If it still fails, grab the IIS log entry (status/substatus) so we can see if a module or proxy is terminating early.

    I suggest also take a look at these documentation:

    If after these checks the limit persists, next suspects are a security/WAF module or a reverse proxy in front of IIS—share the IIS module list and the exact status code.

    Let me know the result if the problem still persists. I hope this helps.


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.