Why Materialize template redirect from localhost to 127.0.0.1 after login? - next.js

I have added a custom login handler for Github:
const handleLoginGithub = (
params: LoginGithubParams,
errorCallback?: ErrCallbackType
) => {
axios
.get(authConfig.loginGithubEndpoint, { params })
.then(async (res) => {
/*window.localStorage.setItem(
authConfig.storageTokenKeyName,
res.data.accessToken
)*/
const returnUrl = router.query.returnUrl
setUser({ ...res.data })
await window.localStorage.setItem('userData', JSON.stringify(res.data))
//router.replace('/home')
})
.catch((err) => {
if (errorCallback) errorCallback(err)
})
}
There is no redirect from localhost to 127.0.0.1, but it will happen, do you know why?
This is the HTTP message that gos to our backend:
GENERAL:
Request URL: http://localhost:3000/api2/gh-auth-complete?code=f87f5157cbf035a73a50
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:3000
Referrer Policy: strict-origin-when-cross-origin
RESPONSE HEADER:
connection: close
content-length: 681
content-type: application/json; charset=utf-8
date: Sun, 09 Oct 2022 22:18:31 GMT
set-cookie: vapor-session=ReDSKZniIFtUqq0kThCkLbBe7vBoCpzpCUWqooA6xYQ=; Max-Age=31536000; Path=/; Secure; SameSite=Lax
Vary: Accept-Encoding
REQUEST HEADER:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Host: localhost:3000
Referer: http://127.0.0.1:3000/
sec-ch-ua: "Chromium";v="106", "Google Chrome";v="106", "Not;A=Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
The reason why I am asking is, that in dev environment cookie will not be stored if it happens.

Related

make flask return response header http1.1 instead http1.0 [duplicate]

I have a jQuery Ajax call, like so:
$("#tags").keyup(function(event) {
$.ajax({url: "/terms",
type: "POST",
contentType: "application/json",
data: JSON.stringify({"prefix": $("#tags").val() }),
dataType: "json",
success: function(response) { display_terms(response.terms); },
});
I have a Flask method like so:
#app.route("/terms", methods=["POST"])
def terms_by_prefix():
req = flask.request.json
tlist = terms.find_by_prefix(req["prefix"])
return flask.jsonify({'terms': tlist})
tcpdump shows the HTTP dialog:
POST /terms HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/json; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://127.0.0.1:5000/
Content-Length: 27
Pragma: no-cache
Cache-Control: no-cache
{"prefix":"foo"}
However, Flask replies without keep-alive.
HTTP/1.0 200 OK
Content-Type: application/json
Content-Length: 445
Server: Werkzeug/0.8.3 Python/2.7.2+
Date: Wed, 09 May 2012 17:55:04 GMT
{"terms": [...]}
Is it really the case that keep-alive is not implemented?
The default request_handler is WSGIRequestHandler.
Before app.run(), Add one line,
WSGIRequestHandler.protocol_version = "HTTP/1.1"
Don't forget from werkzeug.serving import WSGIRequestHandler.
Werkzeug's integrated web server builds on BaseHTTPServer from Python's standard library. BaseHTTPServer seems to support Keep-Alives if you set its HTTP protocol version to 1.1.
Werkzeug doesn't do it but if you're ready to hack into the machinery that Flask uses to instantiate Werkzeug's BaseWSGIServer, you can do it yourself. See Flask.run() which calls werkzeug.serving.run_simple(). What you have to do boils down to BaseWSGIServer.protocol_version = "HTTP/1.1".
I haven't tested the solution. I suppose you do know that Flask's web server ought to be used for development only.

ASP.NET login does not redirect just logged user properly in Firefox and IE, but works with Chrome

I have ASP.NET application, which is perfectly works on development environment. Login works on Firefox, IE and Chrome.
Requests in Firefox in development env looks like:
POST Request:
POST /MyServiceName/Account/Login?ReturnUrl=%2FMyServiceName%2F HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/MyServiceName/Account/Login?ReturnUrl=%2fMyServiceName%2f
Content-Type: application/x-www-form-urlencoded
Content-Length: 171
Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=bQmz8xMlE-u9e0iKr3vtXpCDqo8FpQkcgPzN3cdw2xp73M8SoV_WTwFG5IIY1JEQlHJ-ZHd8h5z_f75FO4nkEcGRhP6e9HBE64rjsGCEVV81
Connection: keep-alive
Upgrade-Insecure-Requests: 1
And Response:
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /MyServiceName/
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
Set-Cookie: .ASPXAUTH=7D3D9E88072745F5AD2B5FCE038F0A794EF6590F9877A65255A63F124CE4FC3EE0309A03F3ACE9C7C5C39E51050F4009A32558D0FE94F673D7B8D5FEA6E6E2E22BEFF862255B50DFC9B6AC2637C8F04918ECCAD0DD63B29CFCD8B4E9BA4DD898C35C7F7CA8E3BB33DA943CD4A45D80F4F24A1E9EF01829B7258C9195FC977B96; expires=Fri, 28-Sep-2018 09:05:12 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Fri, 28 Sep 2018 08:35:12 GMT
Content-Length: 128
But when I deploy my service into real server, login in with any browser except Chrome does not work.
Requests in Firefox in real server:
Remote host POST Request:
POST /MyServiceName/Account/Login?ReturnUrl=%2FMyServiceName HTTP/1.1
Host: remhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://remhost/MyServiceName/Account/Login?ReturnUrl=%2fMyServiceName
Content-Type: application/x-www-form-urlencoded
Content-Length: 171
Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=-JG3IFQhCVjOuL_SIf7QD0ot7Fc_Fy9lb8Lii_VkLzGKGWswkOPfG-ZQtxijlFYhDO7jAMRiRcatHWcdlBRw7RXVzkdu5864rWiLNWGHc7KSUwgtwA-W_lJHVm-EmKW9v1zEgESa0oQKZ37i9mHC6g2; __RequestVerificationToken_L00yU3VwcG9ydF92Mg2=nAHU2cD63KJZIjm3a8LHUYlZpQ9YChmou1E1pvMfI5xmQl2iqgbJ9x9iCuTH0lDlmAqoqFd5_bnPS3FsUVkNYwYRcLt-WJozs0kWt_jn0fM1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
And Response:
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /MyServiceName
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Set-Cookie: .ASPXAUTH=BD46865424CAA946E4AF046436F14C10841E64596BDF9125E721000DA2056C5613D914985ED65A1F3ADF65A322D93156559D2F4B02DFB2F3D4C8CCC5837C90CE29825E578FBA2B5E2B1F6E06DC259FC60210C1DA31A44F861476D49A6FFE318474FEE116867B58898357335914B1E8AD65DFEF8223DABDBB07D7ECBAB990D976; expires=Fri, 28-Sep-2018 07:53:36 GMT; path=/; HttpOnly
Date: Fri, 28 Sep 2018 07:23:36 GMT
Content-Length: 130
GET Request on Firefox:
GET /MyServiceName HTTP/1.1
Host: remhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://remhost/MyServiceName/Account/Login?ReturnUrl=%2fMyServiceName
Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=-JG3IFQhCVjOuL_SIf7QD0ot7Fc_Fy9lb8Lii_VkLzGKGWswkOPfG-ZQtxijlFYhDO7jAMRiRcatHWcdlBRw7RXVzkdu5864rWiLNWGHc7KSUwgtwA-W_lJHVm-EmKW9v1zEgESa0oQKZ37i9mHC6g2; __RequestVerificationToken_L00yU3VwcG9ydF92Mg2=nAHU2cD63KJZIjm3a8LHUYlZpQ9YChmou1E1pvMfI5xmQl2iqgbJ9x9iCuTH0lDlmAqoqFd5_bnPS3FsUVkNYwYRcLt-WJozs0kWt_jn0fM1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
GET Response on Firefox:
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /MyServiceName/Account/Login?ReturnUrl=%2fMyServiceName
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 28 Sep 2018 07:46:51 GMT
Content-Length: 170
Google Chrome for remote server:
POST Login:
curl 'http://remhost/MyServiceName/Account/Login' -H 'Connection: keep-alive' -H 'Cache-Control: max-age=0' -H 'Origin: http://remhost' -H 'Upgrade-Insecure-Requests: 1' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Save-Data: on' -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8' -H 'Referer: http://remhost/MyServiceName/Account/Login?ReturnUrl=%2FMyServiceName%2F' -H 'Accept-Encoding: gzip, deflate' -H 'Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7' -H 'Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=UcVwtESdo2tT8Uy1opbJpVpDdpBOTYmNXRi0dyW7ubyd529sme8yJ23vQQX4aQlM02NVTMoBowsD4Uzbpydnq_rgd8I2n-G96I5JQ9xgM2E3cnLVys9RNJtbjLwInu1XKdH2VbkqYIaxXP4mWYT-2g2; __RequestVerificationToken_L00yU3VwcG9ydF92Mg2=RANEaw7GedA6EGEajt9O9rDx3k0SPUuWm-gG-nY_GzlpJyr_odsUU3wN6BorEbAz87_yswgZDS07ihDiuUUZxIAfOFdQA2Ohn7HmrlAz1L41' --data '__RequestVerificationToken=eUURMtLNSgIi4SgyID5CJZchnns9yTjK039Z1FFcA7TAQjjZ1wvblnKeseCe7UJu6zclcA3NgZ2rBZnABMGn54maEDhfe5W-kk-mjGeIGIk1&UserName=user&Password=password' --compressed
Request header:
POST /MyServiceName/Account/Login HTTP/1.1
Host: remhost
Connection: keep-alive
Content-Length: 171
Cache-Control: max-age=0
Origin: http://remhost
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Save-Data: on
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://remhost/MyServiceName/Account/Login?ReturnUrl=%2FMyServiceName%2F
Accept-Encoding: gzip, deflate
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=UcVwtESdo2tT8Uy1opbJpVpDdpBOTYmNXRi0dyW7ubyd529sme8yJ23vQQX4aQlM02NVTMoBowsD4Uzbpydnq_rgd8I2n-G96I5JQ9xgM2E3cnLVys9RNJtbjLwInu1XKdH2VbkqYIaxXP4mWYT-2g2; __RequestVerificationToken_L00yU3VwcG9ydF92Mg2=RANEaw7GedA6EGEajt9O9rDx3k0SPUuWm-gG-nY_GzlpJyr_odsUU3wN6BorEbAz87_yswgZDS07ihDiuUUZxIAfOFdQA2Ohn7HmrlAz1L41
Response header:
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: /MyServiceName/
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Set-Cookie: .ASPXAUTH=33BF43D6803B985EB87EEF8AC1301B63F7A8406ADC73ACED15D3F5737AF883F49D3F64AB979E234A550D554C55B570DAF23AC8FF5A91D8517D70C2E6149341A2DD2F35CFC7B5487141A28099A927C5D971A4C954A2669A8A3E6500E0B762402A366850B5A6F1330740ADB958E43F0044D577AD4E70D517B682AFCA55F9A7482E; expires=Fri, 28-Sep-2018 07:30:09 GMT; path=/; HttpOnly
Date: Fri, 28 Sep 2018 07:00:09 GMT
Content-Length: 131
GET MyServiceName/:
curl "http://remhost/MyServiceName/" -H "Connection: keep-alive" -H "Cache-Control: max-age=0" -H "Upgrade-Insecure-Requests: 1" -H "Save-Data: on" -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36" -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8" -H "Referer: http://remhost/MyServiceName/Account/Login?ReturnUrl=^%^2FMyServiceName^%^2F" -H "Accept-Encoding: gzip, deflate" -H "Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7" -H "Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=UcVwtESdo2tT8Uy1opbJpVpDdpBOTYmNXRi0dyW7ubyd529sme8yJ23vQQX4aQlM02NVTMoBowsD4Uzbpydnq_rgd8I2n-G96I5JQ9xgM2E3cnLVys9RNJtbjLwInu1XKdH2VbkqYIaxXP4mWYT-2g2; __RequestVerificationToken_L00yU3VwcG9ydF92Mg2=RANEaw7GedA6EGEajt9O9rDx3k0SPUuWm-gG-nY_GzlpJyr_odsUU3wN6BorEbAz87_yswgZDS07ihDiuUUZxIAfOFdQA2Ohn7HmrlAz1L41; .ASPXAUTH=33BF43D6803B985EB87EEF8AC1301B63F7A8406ADC73ACED15D3F5737AF883F49D3F64AB979E234A550D554C55B570DAF23AC8FF5A91D8517D70C2E6149341A2DD2F35CFC7B5487141A28099A927C5D971A4C954A2669A8A3E6500E0B762402A366850B5A6F1330740ADB958E43F0044D577AD4E70D517B682AFCA55F9A7482E" --compressed
Request header:
GET /MyServiceName/ HTTP/1.1
Host: remhost
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Save-Data: on
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://remhost/MyServiceName/Account/Login?ReturnUrl=%2FMyServiceName%2F
Accept-Encoding: gzip, deflate
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Cookie: __RequestVerificationToken_L00yU3VwcG9ydA2=UcVwtESdo2tT8Uy1opbJpVpDdpBOTYmNXRi0dyW7ubyd529sme8yJ23vQQX4aQlM02NVTMoBowsD4Uzbpydnq_rgd8I2n-G96I5JQ9xgM2E3cnLVys9RNJtbjLwInu1XKdH2VbkqYIaxXP4mWYT-2g2; __RequestVerificationToken_L00yU3VwcG9ydF92Mg2=RANEaw7GedA6EGEajt9O9rDx3k0SPUuWm-gG-nY_GzlpJyr_odsUU3wN6BorEbAz87_yswgZDS07ihDiuUUZxIAfOFdQA2Ohn7HmrlAz1L41; .ASPXAUTH=33BF43D6803B985EB87EEF8AC1301B63F7A8406ADC73ACED15D3F5737AF883F49D3F64AB979E234A550D554C55B570DAF23AC8FF5A91D8517D70C2E6149341A2DD2F35CFC7B5487141A28099A927C5D971A4C954A2669A8A3E6500E0B762402A366850B5A6F1330740ADB958E43F0044D577AD4E70D517B682AFCA55F9A7482E
Response header:
HTTP/1.1 200 OK
Cache-Control: private, s-maxage=0
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 28 Sep 2018 07:00:09 GMT
Content-Length: 4619
Response:
<!DOCTYPE html>
<html lang="en">
<!-- Here is my html when user logged in -->
</html>
The problem seem to be in second GET. On development env it returns status 200 OK, and on real server 302 Found.
Authentication is done thru ASP.NET Simple Membership.
Login POST action:
[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public ActionResult Login(LoginModel model, string returnUrl)
{
string errorMsg = "The user name or password provided is incorrect.";
if (Roles.IsUserInRole(model.UserName, "Disabled"))
{
errorMsg = "Your account has been disabled. Contact administrator for more info.";
}
else if (ModelState.IsValid && WebSecurity.Login(model.UserName, model.Password, true))//persistCookie: false))
{
accountService.AddLogin(model.UserName);
return RedirectToLocal(returnUrl);
}
// If we got this far, something failed, redisplay form
ModelState.AddModelError("", errorMsg);
return View(model);
}
private ActionResult RedirectToLocal(string returnUrl)
{
if (Url.IsLocalUrl(returnUrl))
{
return Redirect(returnUrl);
}
else
{
return RedirectToAction("Index", "Home");
}
}
I have checked login status from server database. The user login was done correctly, and user status is logged in, though Firefox still displays login page as if user is not logged. I think the problem is in redirection somewhere.
Any ideas why? The web.config file is same except database connection settings on both systems. it's same ISS 7.5 on both computers. So what else might be the reason?
One more interesting thing. From the same remote computer where service is run Firefox also works OK. So My problem for remote sessions only.
UPDATE:
Seems I found the root cause here. But I have no idea yet how to fix it in scope of my code
If the third does not have time to finish before redirect, it might be so, that only remote sessions fail. Agree?
In web.config I have:
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" cookieless="UseCookies" timeout="30" slidingExpiration="true" />
</authentication>
From you web config <authentication mode="Forms">, I can deduct you are using forms authentication.
Try these two things:
Set up default url in forms authentication setting like :
<authentication mode="Forms">
<forms loginUrl="~/Account/Login" cookieless="UseCookies" timeout="30" slidingExpiration="true" defaultUrl="~/Home/Index"/>
</authentication>
For redirecting after authentication, instead of using return RedirectToAction("Index", "Home"); or return Redirect(returnUrl);
use FormsAuthentication.RedirectFromLoginPage method like:
if (Membership.ValidateUser(userName, password) == true)
{
FormsAuthentication.SetAuthCookie(userName, false);
FormsAuthentication.RedirectFromLoginPage(userName, false);
}
It Redirects an authenticated user back to the originally requested URL or the default set in the config.
For more information & override of this method refer :
Microsoft docs

Why is my AJAX result not ETag-cached (no If-None-Match)?

Here is my AJAX function:
function ajax(url, data) {
return new Promise((resolve, reject) => {
$.ajax({
url: "https://xxx",
data: data,
method: 'POST',
timeout: 50000,
cache: true,
ifModified: true,
crossDomain: true,
success: (data, textStatus, jqXHR) => {
if (data == '#fail#') reject(data);
else {resolve(data);}
},
error: (jqXHR, textStatus, errorThrown) => {
reject(errorThrown);
}
});
});
}
As observed in Chrome -> Network(F12), this is the response header from the server:
HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: text/html; charset=utf-8
Content-Length: 3
ETag: W/"3-R7zlx09Yn0hn29V+nKn4CA"
Date: Fri, 06 Apr 2018 11:39:41 GMT
Connection: keep-alive
The request header is always identical, even in subsequent calls:
POST /register HTTP/1.1
Host: xxx:60001
Connection: keep-alive
Content-Length: 0
Accept: */*
Origin: http://localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Referer: http://localhost:8000/index.html
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Shouldn't Chrome, upon receiving an ETag header, cache the resource and set the 'If-None-Match' header on subsequent calls to the same URL? Shouldn't I obtain a status code of 304 instead of 200 as the returned content is the same?
The calls to the resources in other servers such as the Google Map server do return 304 sometimes though.
This confirms that caching is generally limited to GET request methods only:
However, common HTTP caches are typically limited to caching responses to GET and may decline other methods. The primary cache key consists of the request method and target URI (oftentimes only the URI is used as only GET requests are caching targets)
This is also confirmed in a post in StackOverflow here.

asp.net web api PUT method not supported

I am making a PUT request for a PersonController but it is not even reaching the controller. Instead I get following response from Server
{"message":"The requested resource does not support http method 'PUT'."}
But a get request GET /api/person is being served properly.
Here is the Person Controller
public class PersonController : ApiController
{
// GET: api/Person/5
[ResponseType(typeof(Person))]
public IHttpActionResult GetPerson(int id) {
//Served without any issues
}
// PUT: api/Person/5
[ResponseType(typeof(void))]
public IHttpActionResult PutPerson(int id, Person person) {
//Not reaching here!
}
}
Here is the PUT request as shown in fiddler
PUT http://localhost:xxxxx/api/person HTTP/1.1
Host: localhost:xxxxx
Connection: keep-alive
Content-Length: 38
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://localhost:xxxxx
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.143 Safari/537.36
Content-Type: application/json
DNT: 1
Referer: http://localhost:xxxxx/index.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ms;q=0.6
{"id":0,"name":"Person 11","age":"11"}
And the Server Response
HTTP/1.1 405 Method Not Allowed
Cache-Control: no-cache
Pragma: no-cache
Allow: GET,POST
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?RDpcWGFuYWR1XFZTX1Byb2plY3RzXEJhY2tib25lSlNfUmVzdENhbGxzXEJhY2tib25lSlNfUmVzdENhbGxzLldlYlxhcGlccGVyc29u?=
X-Powered-By: ASP.NET
Date: Sat, 16 Aug 2014 09:20:46 GMT
Content-Length: 72
{"message":"The requested resource does not support http method 'PUT'."}
Clearly, the PUT request is rejected by the IIS Express. What is the correct way to configure the IIS Express (VS 2013) to allow PUT and DELETE requests at the project level.

Web API Object From Body is Null in IE

I have an asp.net web forms app where I'm trying to call ValidateRegistration1 method fro web api controller. It's doing fine in Firefox and Chrome but the object is null when I use IE. Content type and others seem almost the same. I couldn't find the problem.
Firefox POST in fiddler:
{Method: POST, RequestUri: 'http://localhost:5555/api/accounts/registervalidate1', Version: 1.1, Content: System.Web.Http.WebHost.HttpControllerHandler+LazyStreamContent, Headers:
{
Cache-Control: no-cache
Connection: keep-alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Language: en-US
Accept-Language: en; q=0.5
Cookie: __AntiXsrfToken=0871e412cceb47faa968c5563d19f8e1; ASP.NET_SessionId=glwlyn2mdihne0ev4uhc5fnv
Host: localhost:5555
Referer: http://localhost:5555/
User-Agent: Mozilla/5.0
User-Agent: (Windows NT 6.3; WOW64; rv:25.0)
User-Agent: Gecko/20100101
User-Agent: Firefox/25.0
X-Requested-With: XMLHttpRequest
Content-Length: 207
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
}}
IE POST in fiddler:
{Method: POST, RequestUri: 'http://localhost:5555/api/accounts/registervalidate1', Version: 1.1, Content: System.Web.Http.WebHost.HttpControllerHandler+LazyStreamContent, Headers:
{
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip
Accept-Encoding: deflate
Accept-Language: en-US
Accept-Language: en; q=0.7
Accept-Language: tr; q=0.3
Cookie: __AntiXsrfToken=4772bed0c8e243f4a7893794ed176f47
Host: localhost:5555
Referer: http://localhost:5555/
User-Agent: Mozilla/5.0
User-Agent: (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0)
User-Agent: like
User-Agent: Gecko
X-Requested-With: XMLHttpRequest
Content-Length: 0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
}}
web api method
[Route("registervalidate1")]
//[ResponseType(typeof(Account))]
[HttpPost]
public HttpResponseMessage ValidateRegistrationStep1(HttpRequestMessage request,
[FromBody]AccountRegisterModel a)
{
HttpResponseMessage response = null;
List<string> errors = new List<string>();
bool isEmailFree = _accountService.EmailInUse(a.LoginEmail);
if (isEmailFree)
errors.Add("jj.");
if (errors.Count == 0)
response = request.CreateResponse(HttpStatusCode.OK);
else
response = request.CreateResponse<string[]>(HttpStatusCode.BadRequest, errors.ToArray());
return response;
}
I just ran into the same issue. The fix for me was to manually add the content type of "application/json" (contentType: 'application/json') to my jQuery ajax call. I'm sure you've found a solution to this by now but I'm posting this for others out there with the same problem.

Resources