FormTagHelper is missing asp-fragment.

[Bartmax]

I would like to use a fragment on the form action.

<from asp-action="Edit" asp-fragment="something">
...
</form>

related #3988

[Bartmax]

also POSTing to an url with fragments returns 400 bad request :(

[dougbu]

also POSTing to an url with fragments returns 400 bad request

That seems expected since fragments are a client-side concept. How should an HTTP server handle a received URL header containing a fragment? Where is the behaviour defined?

[Bartmax]

This is mostly a routing issue than a posting issue. servers discard the fragment part on posts. That's ok, what I want to do is keep the routing/navigation url path.

just to sample this better:

create this html on any mvc route (ex: Home/Index)

<form method="post">
<button type="submit">submit</button>
</form>

Go to url: Home/Index#something
Press submit button.

mvc returns a 400 Bad Request error.

The expected behavior will be to submit to [HttpPost]Home/Index. (browser already discards the fragment from the url) but routing should stay on Home/Index#something.

I'm trying to be clear, but let me know if this does not make sense, I think I spelled it quite confusing.

[Eilon]

It's not the server that discards the #fragment, the browser does that, so the server never sees it, so it can't generate the URL, because it never saw the fragment to begin with...

[Bartmax]

@Eilon you are right. What I don't understand then is why a post in a fragment url returns a Bad Request from MVC but not without the fragment and how the url (including the fragment) is preserved.
Something else is going on. I will try to investigate a little further. My gut feeling tells me there's something on mvc or kestrel that is not quite right.

[Bartmax]

Ok. I now see why MVC returned Bad Request. Is because when not using the <form> tag helper, the anti forgery token is not included. So that explains it.

About the asp-fragment on form tag helper:

[HttpPost]
[ValidateAntiForgeryToken]
public IActionResult Index() {
    return View();
}

<form action="/Home/Index#test" method="post">
@Html.AntiForgeryToken()
<button type="submit">submit</button>
</form>

This works flawlessly and the url in the browser ends in /Home/Index#test

I'm not sure how exactly this works. The request on chrome inspector clearly shows that the fragment part is not present on the POST request, looks like it still use it to adjust the browser destination url to that address (including fragment).

While it still would help to have the asp-fragment on the form taghelper, I guess this is more browser magic than anything else and maybe from a framework perspective is better to leave it as is.

I let you decide what's best and feel free to close this issue. Probably is custom enough for me to handle in my code. Thanks for your time.

[Eilon]

@Bartmax ok, so to make sure I've understood, you'd still like to see an asp-fragment property on various tag helpers (probably not just the <form> one, but also <a> and maybe others), and other than that everything works?

[Bartmax]

@Eilon I'm not sure, that's why I think it's better for you to decide maybe based on more customers.

I do want to be able to manage the routing consistently alongside my app (aka creating url address for endpoints).
But i don't think having a fragment on form tag helper sounds about right.

[rmarskell]

I'd also like to see this feature. I have a single page app with a couple forms far past the fold and when they post back, I want the page to scroll down and show the validation messages.

Thankfully @Bartmax's work around of adding @Html.AntiForgeryToken() explicitly worked for me, but it would be nice if this was built in.