IIS-HttpPlatformHandler-Kestrel app not processing POST's

[guardrex]

In reference to an app that I just refactored (steps listed here) from IIS-Helios (beta7) to IIS-HttpPlatformHandler (beta8), GET is processed properly (e.g., the Contact view loads) ...

[HttpGet]
[Route("/contact/{d?}")]
public IActionResult Index(string d, Visitor visitor = null) { ... }

... but POST is resulting in a 404 (e.g., POST to the Contact controller fails) ...

[HttpPost]
[Route("/contact/{d?}")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Index(Visitor visitor) { ... }

IIS is seeing the POST, from the IIS log ...

2015-10-16 17:33:14 10.119.28.25 POST /contact - 8001 - 68.225.66.164 Mozilla/5.0+(Windows+NT+10.0;+WOW64)+AppleWebKit/537.36+
(KHTML,+like+Gecko)+Chrome/46.0.2490.71+Safari/537.36 
http://www.~~~~~~~~.com:8001/contact 404 0 0 2007

The HttpPlatformHandler log (stdout.log) is up but not showing anything (can I enable some more detailed tracing here? Also a bit curious about why it says "Now listening on: http://localhost:33176" when this is on the VM/IIS?) ...

Hosting environment: Production
Now listening on: http://localhost:33176
Application started. Press Ctrl+C to shut down.
<end of entries>

@davidfowl had me remove the --server.urls argument from the web.cmd command to get the app responsive (to GET's anyway), resulting in this ...

"commands": {
  "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel"
},

Nothing changed in the app between going from Helios to HttpPlatformHandler. POST works under IIS Express locally but is failing on the VM under IIS-HttpPlatformHandler.

Packages:

"Microsoft.AspNet.Diagnostics": "1.0.0-beta8",
"Microsoft.AspNet.Diagnostics.Entity": "7.0.0-beta8",
"Microsoft.AspNet.Hosting": "1.0.0-beta8",
"Microsoft.AspNet.Mvc": "6.0.0-beta8",
"Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-beta8",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-beta8",
"Microsoft.AspNet.StaticFiles": "1.0.0-beta8",
"System.ComponentModel.TypeConverter": "4.0.1-beta-*",
"System.Net.Http": "4.0.0-beta-*",
"System.Net.Security": "4.0.0-beta-*",
"System.Net.Sockets": "4.0.10-beta-*",
"Microsoft.AspNet.Antiforgery": "1.0.0-beta8",
"System.Runtime.Serialization.Primitives": "4.0.10-beta-*",
"WindowsAzure.Storage": "5.0.3-preview",
"Microsoft.Framework.Configuration": "1.0.0-beta8",
"Microsoft.Dnx.Compilation.CSharp.Abstractions": "1.0.0-beta8",
"Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-beta8"

Runtime:

dnx-coreclr-win-x64.1.0.0-beta8

Server:

Azure VM: WS 2012 (not R2), IIS 8

[MaxxDelusional]

Do you need to add app.UseIISPlatformHandler(); to your Startup.cs?

For what it's worth, my log also says "Now listening on: http://localhost:2256", but my app is working fine in IIS.

[guardrex]

@MaxxDelusional I just tried it ... same result ... 404 when POST'ing back to that controller.

Your POST's are working ok?

btw- I didn't even know about the Microsoft.AspNet.IISPlatformHandler package ... it would cool if someone from the team could say when that package is required. The app seems to run fine (without that package and including POST's) when run locally.

[guardrex]

Ok, I see it now ... Microsoft.AspNet.IISPlatformHandler is described. It is required beyond loading the app for forwarding windows auth, scheme, and client ip.

aspnet/Templates#189

Anyway ... still work'in this POST-404 problem.

[MaxxDelusional]

@guardrex Yep, I tested my POSTS and they are working. I honestly didn't know what UseIISPlatformHandler() did, I just saw it in the new template, so I thought it was required.

I'm wondering if it has something to do with [ValidateAntiForgeryToken]. Could you try removing that attribute and see if it works.

[guardrex]

@MaxxDelusional That's good. It's just me then.

I tried without Antiforgery, but it didn't fix it. Not surprising really, since I would think the Antiforgery cookie and header bits come after the pipeline gets back to the controller. This is acting like it can't find the POST route. I'll try putting a different controller and view up and see if this is just isolated to that one Contact Us webform.

[guardrex]

@MaxxDelusional Yeah, so another [HttpPost] controller in the Home controller did work. This is a route problem apparently with that one controller. I'll keep digging.

[guardrex]

Does IActionResult affect the route in some way?

async Task<string> WORKS 👍 ... 200 OK

[HttpPost]
[Route("/contact/{d?}")]
[ValidateAntiForgeryToken]
public async Task<string> Contact(Visitor visitor)
{
    return await Task.Run(() => { return "Contact test okey-dokey!"; });
}

async Task<IActionResult> does NOT 👎 work ... 404!

[HttpPost]
[Route("/contact/{d?}")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Contact(Visitor visitor)
{
    ViewBag.StatusMessage = await Task.Run(() => { return "Contact test okey-dokey!"; });
    return View(visitor);
}

IActionResult does NOT 👎 work ... 404!

[HttpPost]
[Route("/contact/{d?}")]
[ValidateAntiForgeryToken]
public IActionResult Contact(Visitor visitor)
{
    ViewBag.StatusMessage = "Contact test okey-dokey!";
    return View(visitor);
}

[guardrex]

Two separate issues found here ... I'm going to close, open a separate issue on each, and reference back to this issue in each.

[ddotlic]

@guardrex I'm actually seeing the same issue as you (GET works but POST doesn't).

Our action returns Task<IActionResult> and we get 404 (like you).

Did you ever get to the bottom of this? We're using released beta8 and everything else works just fine.

[ddotlic]

@guardrex False alarm, the error is actually banal - we do not have a route for "/error" (yet it is configured right there in Startup.cs) and there was an error (and rather early in the process).

Logs finally helped me understand where the issue was, just had to turn it on in web.config: new publish already creates logs next to the approot and webroot but doesn't enable it.