I'm using Fiddler (or post manager) to invoke requests to my WebApi. ( it's hosted as an ASP.net application in IIS)
This is the service :
[HttpPost]
[ActionName("uploadRessources")]
[AllowAnonymous]
public HttpResponseMessage uploadRessources(ResourcesJson json)
{
...
return Request.CreateResponse(HttpStatusCode.OK, result);
}
For short length body( 3 rows of data) length post data requests like :
POST http://something.com/api/services/uploadRessources HTTP/1.1
Cache-Control: no-cache
Connection: keep-alive
Pragma: no-cache
Accept: application/json
Accept-Encoding: gzip
Accept-Language: he-IL
User-Agent: Mozilla/5.0
Content-Length: 451
Content-Type: application/json
Host: es.com
{ "l":
[{"MasterEntity":2,"screen":"ConfirmHealthDetailsPage","Lbl":"ApproveTheFollowingDetails","enus":"Approve the Following Details:","device":"mobile","description":"NULL"},
{"MasterEntity":2,"screen":"ConfirmHealthDetailsPage","Lbl":"PersonalDetails","enus":"Personal Details","device":"mobile","description":"NULL"},
{"MasterEntity":2,"screen":"FingerPrintResources","Lbl":"CANCEL","enus":"CANCEL","device":"mobile","description":"NULL"}]
}
I DO get a successful response :
HTTP/1.1 200 OK
But for a long body length request ( 101K ) -
It is stuck (it even doesn't hit the breakpoint in my code , while in short request - it does )and I never see a response :
BTW - If later I do run again the short body length request( while still waiting for the previous large requests) - I do get 200 ( for the short length request).
In web.config I did set :
<httpRuntime enableVersionHeader="false" executionTimeout="100000000" maxRequestLength="999999999" />
In IIS : No requests filters
In Event Viewer - I don't see any exceptions or warnings
IIS version : 6.1 ( windows 7) - but it also happens at our server.
Question
Why doesn't my 101k length request - get to my webapi ?
Edit
I've found that it happens for >65k requests. Still don't know what is the problem
It's seems to be an issue with your serializer, tries to put a breakpoint there and see if hits it. If you are not using a custom serializer, creates one temporally just to see what's happen with your request.
It was stuck on request.Content.ReadAsStringAsync().Result ( and never released). Strange but setting it to async , solved the problem. I still don't know why. In General this is the solution - the left pane was the problematic one while the right pane is the working one. ( I must say that the left pane used to work , but after upgrading to 4.6.2 - it started doing problems) - Again - I don't know why
Related
I have a web api consumed by mobile apps. I can reproduce case with postman also with appropriate params.
Here are my postman call captured by fiddler:
GET http://localhost/WebApi/api/User/GetAnnouncement?id=22 HTTP/1.1
Content-Type: application/json
ApiKey: someKey
AuthenticationToken: someGuid1
UserId: 6524
DeviceId: someGuid2
LocalDate: 538294155.662561
OsTypeId: 1
LoginToken: someGuid3
CompanyId: 2
cache-control: no-cache
Postman-Token: b863afdd-b04c-4a4d-b473-69d5ecef622e
User-Agent: PostmanRuntime/7.4.0
Accept: */*
Host: localhost
cookie: ASP.NET_SessionId=nk4g3zzfyi0n3xomfw5dxxxx
accept-encoding: gzip, deflate
Connection: keep-alive
and my issue occurs in authorize action filter:
public class BasicAuthorizeAttribute : FilterAttribute
{
}
public class BasicAuthorizeFilter : AuthorizationFilterAttribute
{
public override void OnAuthorization(HttpActionContext actionContext)
{
//!!!HERE when I debug, in watch I can see already authHeader has value "in some calls"
System.Threading.Thread.SetData( System.Threading.Thread.GetNamedDataSlot("authHeader"), "someValueComingFromRequestHeader" );
}
}
At the very beginning of the OnAuthorization (see !!!HERE line in the code), I can see in watch this expression:
System.Threading.Thread.GetData(System.Threading.Thread.GetNamedDataSlot("authHeader"))
has the value even though I expect it is always null. It has even the value from previous client.
Actually issue come to as a bug "session" mingled (I mean mixed).
This pieces code is on the my company's framework so something is weirdly wrong.
I can give as much as I can so far. Please ask any info necessary.
What could be the cause?
I am daring to ask this because it is possible the issue obvious may be.
Note: I have the same case while none debugging with two phones connected to my pc via proxy settings.
I have a controller that looks similar to the following:
[HttpPut]
[Route("")]
public async Task<IActionResult> Put([FromBody]List<MyObject> fromBody)
{
if (fromBody == null)
throw new InvalidOperationException($"{nameof(fromBody)} must not be null");
// Unimportant junk
}
Very rarely, the InvalidOperationException is thrown during a request. But the raw request data has the correct content and headers(I use raygun for exception reporting and it captures the raw request and the json content is there and valid). Are there any reasons that this could occur?
The headers are the same between both a successful request and a bad one, and are as follows(With my website and any Azure id's redacted):
Connection: "Keep-Alive"
Content-Type: "application/json;charset=utf-8"
Accept: "application/json;charset=utf-8"
Accept-Encoding: "gzip"
Host: "redacted"
Max-Forwards: "10"
User-Agent: "Dalvik/2.1.0 (Linux; U; Android 6.0.1; Nexus 5 Build/M4B30Z)"
Content-Length: "55392"
X-WAWS-Unencoded-URL: "redacted"
X-Original-URL: "redacted"
X-ARR-LOG-ID: "redacted"
DISGUISED-HOST: "redacted"
X-SITE-DEPLOYMENT-ID: "redacted"
WAS-DEFAULT-HOSTNAME: "redacted"
X-Forwarded-For: "redacted"
X-ARR-SSL: "redacted"
X-Forwarded-Proto: "https"
MS-ASPNETCORE-TOKEN: "redacted"
X-Original-For: "redacted"
X-Original-Proto: "http"
Unfortunately I cannot disclose the actual body of the message due to policies beyond my control, but it is composed of a 100% valid json array of objects totaling in the correct length in regard to the Content-Length. And when my client does a retry with the same content/headers, it succeeds.
My suspicion is that it is potentially timed out requests still entering the controller, and then being unable to read the request body due to the timeout. Clients are android devices so they go in and out of internet connectivity constantly. But I don't know why it would enter the controller at all in that case.
Turns out that Asp.NET core had a bug that resulted in this behavior.
https://github.com/aspnet/Mvc/issues/7551
It has been patched in 2.1.X+ of which a preview release is available.
I know it's been asked a lot of time and I have tried everything but still facing the problem. Here is my code:
// POST api/<controller>
public string Post([FromBody]string value)
{
return value;
}
There is nothing fancy just returning the value.
I am using Chrome's PostMan Plugin
I have tried like 100 times but still getting the same null value as the response. I have tried it with Content-Type application/json and everything mentioned but still getting null.
Not really sure what the question is however what you are looking for is to setup your POST with a single value.
Such as below:
POST /api/values HTTP/1.1
Host: localhost:50121
Content-Type: application/json
Accept: application/json, text/javascript
Cache-Control: no-cache
'abc'
Now this is a JSON post so the body doesn't have a parameter name, this is by design as you are posting a single value.
If you need multiple values or a more complex object you should use a class object instead of a single value.
Okay, so I have a web api controller with put action and a return type of void. When I run it using VS's builtin iisepxress and call it, I get back a 204 as expected. The here are the headers:
Cache-Control no-cache
Connection close
Content-Type text/html
Date Thu, 10 Oct 2013 19:33:43 GMT
Expires -1
Pragma no-cache
Server Microsoft-IIS/8.0
X-AspNet-Version 4.0.30319
X-Powered-By ASP.NET
When I put the exact same code in our sbx environment, I get a 204, but with the following headers:
Cache-Control no-cache
Date Thu, 10 Oct 2013 19:39:59 GMT
Expires -1
Pragma no-cache
Server Microsoft-IIS/7.5
X-AspNet-Version 4.0.30319
X-Identifier 17253
X-Powered-By ASP.NET
The pertinent difference being the lack of contentType in the second one.
The problem this creates is that in firefox (and IE I think) it defaults to xml, tries to parse it and fails.
I know how to fix this by setting my contentType in my web api controller, but that doesn't seem like the best fix to me.
So, what I'm asking is what setting difference in IIS might be causing this?
Thanks
Note:
My url looks like this /foo/bar/2 so it isn't mimetype.
If your service is responding with a 204, the response should not contain a message-body. This is by spec. I can only assume you are responding with something in your message body.
Your response from the API method should be like this:
return new HttpResponseMessage { StatusCode = System.Net.HttpStatusCode.NoContent }
Edit. I noticed you mentioned you return "void". Your method should return HttpResponseMessage with the StatusCode I noted above.
That will solve the isssue:
protected internal virtual IHttpActionResult NoContent()
{
HttpResponseMessage responseMsg = new HttpResponseMessage(HttpStatusCode.NoContent) {Content = new StringContent(string.Empty, Encoding.UTF8)};
return this.ResponseMessage(responseMsg);
}
But still doesn't explain why IIS is adding by default:
Content-Type text/html
Or even better how to remove it using web.config or IIS config.
I use this:
Return StatusCode(HttpStatusCode.NoContent);
PLEASE HELP!! Can't figure out why this simple code given by MSDN doesn't work....
I am using the following code in GetAccessToken() as given in the this MSDN article to get the access token to be used in windows notifications, but it returns "Bad Request 400"
PACKAGE_SECURITY_IDENTIFIER, CLIENT_SECRET are the values obtained when the app was registered with the Windows Store Dashboard
string urlEncodedSid = HttpUtility.UrlEncode(PACKAGE_SECURITY_IDENTIFIER);
string urlEncodedSecret = HttpUtility.UrlEncode(CLIENT_SECRET);
string body = String.Format("grant_type=client_credentials&client_id={0}&client_secret={1}&scope=notify.windows.com", urlEncodedSid, urlEncodedSecret);
string response;
using (WebClient client = new WebClient())
{
client.Headers.Add("Content-Type", "application/x-www-form-urlencoded");
response = client.UploadString("https://login.live.com/accesstoken.srf", body);
}
Any help would be highly appreciated.......
I suspect the problem has to do with either an incorrect package identifier, and / or incorrect client secret.
From the MSDN page Push notification service request and response headers:
RESPONSE DESCRIPTION
--------------- --------------------------
200 OK The request was successful.
400 Bad Request The authentication failed.
Update - I ran the code from the question, using FAKE credentials.
Here is the RAW HTTP request:
POST https://login.live.com/accesstoken.srf HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: login.live.com
Content-Length: 88
Expect: 100-continue
Connection: Keep-Alive
grant_type=client_credentials&client_id=test&client_secret=test&scope=notify.windows.com
Here is the server's RAW response:
HTTP/1.1 400 Bad Request
Cache-Control: no-store
Content-Length: 66
Content-Type: application/json
Server: Microsoft-IIS/7.5
X-WLID-Error: 0x80045A78
PPServer: PPV: 30 H: BAYIDSLGN2A055 V: 0
Date: Thu, 21 Mar 2013 12:34:19 GMT
Connection: close
{"error":"invalid_client","error_description":"Invalid client id"}
You will note that the response is a 400. There is also some json that indicates the type of error. In my case, the error is Invalid client id. You probably want to take a look at your response - it will give you an indication of what happened.
I used Fiddler to debug the request/ response.
I found the reason for the error response. In fact it is the wrong PACKAGE_SECURITY_IDENTIFIER and CLIENT_SECRET.
DO NOT type the values. Because associated ASCII values differ. Therefore it is always better to copy and paste directly.
You will probably will get the access token with the simple code snippet.
Cheers
If you're using the new HttpClient API and you're sure you've copied and pasted the SID/secret values correct, you might be experiencing this issue because of encoding, provided you're using the FormUrlEncodedContent class as the content of your POST operation.
Contrary to the examples in the MSDN documentation, you don't want to URL encode the SID and secret values before adding them to the KeyValuePair collection. This is because encoding is implied by the FormUrlEncodedContent class, though I'm not seeing any documentation for this behavior. Hopefully this saves someone some time because I've been wrestling with this all night...