A tale of rabbit holes and multipart/form
-
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header. Fussed with all the IIS settings and web.config settings to no avail. Tested vanilla POST calls, all passed CORS without issues. Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request. Found an obscure post that people were getting this CORS error on ngnix when the file size was too large. Tried uploading a a 1K file, and it worked! Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed. Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)The endpoint was hit, no CORS error. Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself? Found a post on the topic that mentioned this code:var form = ControllerContext.HttpContext.Request.Form;Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible. Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED. Unbelievable. An unauthorized access exception results in the browser giving me a CORS error! This took all week to figure out, spending probably 6 hours a day on it. :sigh: And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content. :sigh:Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainI have no idea what you're talking about :-O other than the punch line, which seems to be that this house of cards is shite at generating error messages that are useful for debugging.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.<p><a href="https://github.com/GregUtas/robust-services-core/blob/master/README.md">Robust Services Core</a>
<em>The fox knows many things, but the hedgehog knows one big thing.</em></p> -
I have no idea what you're talking about :-O other than the punch line, which seems to be that this house of cards is shite at generating error messages that are useful for debugging.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
seems to be that this house of cards is shite at generating error messages that are useful for debugging
It's ALWAYS been this way. SQL Server is the worst.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
Greg Utas wrote:
seems to be that this house of cards is shite at generating error messages that are useful for debugging
It's ALWAYS been this way. SQL Server is the worst.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013I know what an SQL server is but had no idea the post was talking about one. :doh: :-D
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header. Fussed with all the IIS settings and web.config settings to no avail. Tested vanilla POST calls, all passed CORS without issues. Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request. Found an obscure post that people were getting this CORS error on ngnix when the file size was too large. Tried uploading a a 1K file, and it worked! Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed. Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)The endpoint was hit, no CORS error. Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself? Found a post on the topic that mentioned this code:var form = ControllerContext.HttpContext.Request.Form;Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible. Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED. Unbelievable. An unauthorized access exception results in the browser giving me a CORS error! This took all week to figure out, spending probably 6 hours a day on it. :sigh: And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content. :sigh:Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainHmmm,
Marc Clifton wrote:
Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED.
Are you sure that allowing your application pool to use global %TEMP% is a good idea? Everybody can read/write to that location. It's probably more secure if your application pool uses the %USERPROFILE% temp path. I'm not an IIS expert but I think a better fix would be loading the user profile[^] for the application pool identity. You should dig around for a setting to enable that. This setting will populate your environment variables and should change your temp folder to the %USERPROFILE% temp. Just a security recommendation. ;)
-
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header. Fussed with all the IIS settings and web.config settings to no avail. Tested vanilla POST calls, all passed CORS without issues. Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request. Found an obscure post that people were getting this CORS error on ngnix when the file size was too large. Tried uploading a a 1K file, and it worked! Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed. Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)The endpoint was hit, no CORS error. Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself? Found a post on the topic that mentioned this code:var form = ControllerContext.HttpContext.Request.Form;Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible. Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED. Unbelievable. An unauthorized access exception results in the browser giving me a CORS error! This took all week to figure out, spending probably 6 hours a day on it. :sigh: And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content. :sigh:Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainI've had something similar before with something going wrong on the API, but the browser showing it as a CORS error. There's a whole flow that happens and I assume that the initial CORS request fails due to whatever is wrong in the background and the browser then just shows that CORS failed. On a ASP.Net project I had to put a if statement in for handling CORS Options requests from Angular because it was calling the method like it would have with a normal request. Maybe just a weird setup in my case. With .Net Core I don't think the options request activates the breakpoints, although it looks like you can with some middleware: https://www.codeproject.com/Questions/5162494/Currently-I-am-working-on-angular-and-web-API-NET [Complete Guide to CORS](https://reflectoring.io/complete-guide-to-cors/)
-
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header. Fussed with all the IIS settings and web.config settings to no avail. Tested vanilla POST calls, all passed CORS without issues. Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request. Found an obscure post that people were getting this CORS error on ngnix when the file size was too large. Tried uploading a a 1K file, and it worked! Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed. Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)The endpoint was hit, no CORS error. Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself? Found a post on the topic that mentioned this code:var form = ControllerContext.HttpContext.Request.Form;Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible. Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED. Unbelievable. An unauthorized access exception results in the browser giving me a CORS error! This took all week to figure out, spending probably 6 hours a day on it. :sigh: And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content. :sigh:Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainFantastic & interesting post & great detective skills. :thumbsup:
Marc Clifton wrote:
Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp.
I'm filing this one away in my brain for later use. That is a crazy situation but I totally believe it because of horrors I've seen with similar & IIS & CORS etc. BTW, was this change needed only on your dev box or did you have to make that change on the Server also? This is just crazy to me. Can you post the link where you found that solution? Very interesting and quite terrible.
-
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header. Fussed with all the IIS settings and web.config settings to no avail. Tested vanilla POST calls, all passed CORS without issues. Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request. Found an obscure post that people were getting this CORS error on ngnix when the file size was too large. Tried uploading a a 1K file, and it worked! Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed. Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)The endpoint was hit, no CORS error. Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself? Found a post on the topic that mentioned this code:var form = ControllerContext.HttpContext.Request.Form;Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible. Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED. Unbelievable. An unauthorized access exception results in the browser giving me a CORS error! This took all week to figure out, spending probably 6 hours a day on it. :sigh: And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content. :sigh:Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
Hmmm,
Marc Clifton wrote:
Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED.
Are you sure that allowing your application pool to use global %TEMP% is a good idea? Everybody can read/write to that location. It's probably more secure if your application pool uses the %USERPROFILE% temp path. I'm not an IIS expert but I think a better fix would be loading the user profile[^] for the application pool identity. You should dig around for a setting to enable that. This setting will populate your environment variables and should change your temp folder to the %USERPROFILE% temp. Just a security recommendation. ;)
Agreed - the main point being, the absurd journey it took to discover that this was all the result of not being able to access the temp folder that .NET (or something?) was trying to use to buffer the files being uploaded.
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
Fantastic & interesting post & great detective skills. :thumbsup:
Marc Clifton wrote:
Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp.
I'm filing this one away in my brain for later use. That is a crazy situation but I totally believe it because of horrors I've seen with similar & IIS & CORS etc. BTW, was this change needed only on your dev box or did you have to make that change on the Server also? This is just crazy to me. Can you post the link where you found that solution? Very interesting and quite terrible.
raddevus wrote:
was this change needed only on your dev box or did you have to make that change on the Server also?
I've never had to make this change anywhere, whether my local devbox, our development server setup, our live servers. It occurred on an obscure server used only as a repository of uploaded files, and it had never seen a .NET application before. I ended up install VS2022 on it to debug the situation, to some extent I'm glad the VS2022 setup didn't magically "fix" the problem.
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
I recently implemented a small service to handle uploads from the browser to our "media server" (rather legacy, don't ask) and on our dev server, no problem. On the actual media server box, I kept getting the dreaded no-access-control-allow-origin header. Fussed with all the IIS settings and web.config settings to no avail. Tested vanilla POST calls, all passed CORS without issues. Learned about "simple requests" which multiform is one of and which don't do an OPTIONS preflight request. Found an obscure post that people were getting this CORS error on ngnix when the file size was too large. Tried uploading a a 1K file, and it worked! Discovered that if the file size was somewhere between by 31K and 67K test files, the larger one failed. Discovered that if I removed the docInfo parameter:
public IActionResult Upload([FromForm] DocumentUpload docInfo)The endpoint was hit, no CORS error. Was thinking, geez, what is .NET 6 doing? Do I have to parse the multiform data myself? Found a post on the topic that mentioned this code:var form = ControllerContext.HttpContext.Request.Form;Tried that and to my horror, it threw an UnauthorizedAccessException that c:\windows\temp\[temp file] is not accessible. Googled, added IIS AppPool\[my application pool] as a user to c:\windows\temp. AND IT WORKED. Unbelievable. An unauthorized access exception results in the browser giving me a CORS error! This took all week to figure out, spending probably 6 hours a day on it. :sigh: And the small <30K file uploads worked without problems because it didn't require creating a temp file for the stream content. :sigh:Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainLooking at the source[^], it seems you can control the directory it uses by setting the
ASPNETCORE_TEMPenvironment variable. (I found that last week trying to get a .NET 6 API endpoint to accept file uploads with no filename on theContent-Dispositionheader, to make it match the existing .NET Framework Web API endpoint. Which turned out to be a massive PITA.) It's probably worth reporting the misleading error in the GitHub repo: Issues · dotnet/aspnetcore · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
