I have an ASP.NET application that runs on:
Windows Server 2019 Standard
IIS Version 10.0.17763.1
Application is set up to use HTTPS
Application is using the library System.Web.UI.WebControls.FileUpload for file upload
Application is using QuickPDFDLL0811.dll to read PDF files and count the number of pages
Users have been reporting that SOME PDF files are failing to upload. The chrome browser tab shows a spinner as if the application is doing something and then the users get presented with a "The site can't be reached" page (attached). However, the same users have indicated they have taken the same PDF files that are erroring out through the steps I found on google 
CodePudding user response：
Your issue is about experience, you want someone who has ran into the same error to answer you. But your problem needs some specifics. Though I will try and answer you.
The scenario you described could be from three things...
- When deploying some apps using Editors or IDEs like Visual Studio, you would notice that not all folders/directories are published. Some are not there when you deploy either to production or on your machine. So the implication of this is that when you finally deploy the app, it would not contain the folder to which you are trying to upload data and if your code does not contain the block that checks whether the directory exists or not and create it when it does not find it, the code fails. (This process is by publishing with Visual Studio IDE).
so ensure your code checks if the directory exists otherwise create it.
- When the Directory's security settings does not allow write. Could be readonly and not read/write.
You would be required to grant write access to that directory you are trying to upload data into.
- Absolute Path for a resource. Sometimes in code the path to the folder you are writing to or uploading to might be different on the production.
Ensure the production machine has the same path for deployment resources as would your development environment.
NB: The three scenarios above can both make the code work on a test machine but not in production because if you test on the local machine, its probably going to contain the directory you are writing to or uploading to. And Read/Write access needs not be granted on developer machine most times but in production, you surely do. It happened to me when I failed to check if the directory exists or not and I published directly from my Visual Studio IDE into Microsoft Azure. When I tried to upload pictures, it failed because the directory could not be found. Though no Error Message appeared.
CodePudding user response：
I'm going to venture a guess that the PDF files that fail to upload are larger than 4MB. If so, what you are encountering is the default request limit of classic asp.NET applications.
See the answers to this question for how to fix this: How to increase the max upload file size in ASP.NET?
The behavior you see, of the "connection was reset" is because the server closes the connection when the limit is reached. It has to do this, because it cannot send a response until the request is fully received, and so it has no other option than to terminate the connection which results in the error you see in the browser. The reason this limit exists is for security reasons: A malicious client could overwhelm your server resources by sending extremely large requests, extremely slowly. For a similar reason, web servers also typically require that clients transmit data at a reasonable rate.
Apparently, in ASP.NET core, the request limit default was bumped up to 30MB, probably because the 4MB limit is too restrictive on the modern web.