ASP.NET WebApi POST Status 405 message for unique signatures from Java app only?

Question

I've got a weird problem in Microsoft.AspNet.WebApi{5.2.3}. The following two functions work fine alone, and they even work fine together, when my client is a .NET 4.6 HttpWebClient. However, as soon as a Java application tries to access the function, I get the following message:

HttpResponseProxy{HTTP/1.1 405 Method Not Allowed [Allow: GET, 
Content-Length: 73, Content-Type: application/json; charset=utf-8, 
Server: Microsoft-IIS/8.0, X-Powered-By: ASP.NET, Set-Cookie: 
ARRAffinity=2cc8b96e3a4c1d6ee6a6e0;Path=/;Domain=mydomain.com, Date: Mon, 01 
Feb 2016 13:44:57 GMT] ResponseEntityProxy{[Content-Type: 
application/json; charset=utf-8,Content-Length: 73,Chunked: false]}}

It looks from the error message, that a GET is being tried (or expected?)? I have added the explicit routing attribute as a last resort. I do not use it elsewhere.

Function 1:

    [System.Web.Http.HttpPost]
    [System.Web.Http.Route("api/Delegate/MigrateMix2User")]
    public async Task<HttpResponseMessage> MigrateMix2User([FromBody] MigrateUserModel userInfo)
    {...}

Function 2:

    [System.Web.Http.HttpPost]
    [System.Web.Http.Route("api/Delegate/ChangeUserEmail")]
    public async Task<HttpResponseMessage> ChangeUserEmail([FromBody] ChangeEmailModel model)
    {...}

Update Http Traces. Content doesn't look like a cause/problem?

Content usage traces: --- .NET 4.5 HttpClient, works fine:

POST http://localhost:1655/api/Delegate/MigrateMix2User HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsI...bE6s
Content-Type: application/json; charset=utf-8
Host: localhost:1655
Content-Length: 231
Expect: 100-continue
Connection: Keep-Alive

{"r_tc_app_client_id":"TN77PENKGu2Nq525c6Za93jbD7PiHzSo","r_email":"hyxx@acx.org","r_password":"dada","r_lang5":"en-EN","r_country2":"US","r_is_cto":"false","my_cto":"xzy","r_plan_id":"planet","addin_plan_id":"tst","addin_qty":2}


--- Java-Appache http Client: throws 405

"POST /api/Delegate/MirgrateMix2User HTTP/1.1[\r][\n]"
"Authorization: Bearer eyJhbGci...dIRiJE[\r][\n]"
"Content-Type: application/json[\r][\n]"
"Accept: application/json[\r][\n]"
"Content-Length: 274[\r][\n]"
"Host: mytargethost.com[\r][\n]"
"Connection: Keep-Alive[\r][\n]"
"User-Agent: Apache-HttpClient/4.3.6 (java 1.5)[\r][\n]"
"Accept-Encoding: gzip,deflate[\r][\n]"

"{"cto":"true","r_tc_app_client_id":"G04o5323zq1fo6hferi4axABdKvyiSCl","r_email":"kunsbe1@mailinator.com","r_password":"2Mh323aXp","r_lang5":"en-US","r_country2":"DE","r_is_cto":"true","r_plan_id":"05260000_LOR.2001","addin_plan_id":"05260000_LOR.2007","addin_qty":815}"

DEBUG [org.apache.http.wire] http-outgoing-2 << "HTTP/1.1 405 Method Not Allowed[\r][\n]"
2016-02-02 12:49:56,914 DEBUG Wire - http-outgoing-2 << "HTTP/1.1 405 Method Not Allowed[\r][\n]"

score 0 · Answer 1 · answered Feb 01 '16 at 15:43

0

Based on the error message it's because you have marked your methods as HttpPost (verb POST) but your javascript is accessing these using GET (HttpGet).

You should include your java code if you want an exact fix in your calling code.

answered Feb 01 '16 at 15:43

Igor

60,821
10
100
175

Yes, thanks. They Java fellows swear that it is a post, and I'm sure it says that in their code... So, installing fiddler on their (cloud) machine.... – GGleGrand Feb 01 '16 at 15:45
@GGleGrand - good idea on using Fiddler (I was not aware it was another party writing the Java code). That way you can show them that their outgoing call is using GET instead of POST. If this is a test machine and you can easily change your code without affecting other users of the service you could also temporarily remove the HttpPost attribute and log `this.Request.Method` in the body of the method(s) as proof that they are not using POST. – Igor Feb 01 '16 at 15:50
To make Function 1 work with the Java app, I leave in the [HttpPost] directive and must remove both Function 2 AND the explicit routing attribute on Function 1. When I do that, then the POST from the Java App works fine, no changes from their end. Thus, I think it is not a simple question of mistake. It looks more like the WebApi side mapping is getting confused... Tips on debug techniques? – GGleGrand Feb 01 '16 at 15:58
Yes, we'll have to do some rewiring tomorrow away from our QA systems to test all this. Thanks for tips. Stay tuned :-) – GGleGrand Feb 01 '16 at 16:00
@GGleGrand - You could also write a simple javascript file to execute test calls to each function (using xhttp or even JQuery). Many times web api implementations exist to support async calls from web applications to avoid the traditional post back so writing a sample/test this way is a good way to check your code and illustrate to the consumer how they should be executing the calls. It also completely remove any doubt that it is a mapping issue (or bring one to light) and is also something you could send them as a "how to" as it (calling client) does not rely on .NET. – Igor Feb 01 '16 at 16:09
Yes, using google PostMan for this at the moment, will look at xhttp or wget. – GGleGrand Feb 02 '16 at 08:20

score 0 · Answer 2 · edited May 23 '17 at 11:52

OK, the enigma is solved and I want to share the result. In the end, the solution was this post however, there is more to it: you see, the Java folks had a typo in there calling URL the whole time. However, they never noticed that it was the wrong function name since we were getting a 504 response status and not a 404. Also, when we commented out the second POST function in the WebApi Controller, it worked fine. And to make things more confusing, the error message said that the problem was due to a HttpGet being refused and the Java system was definitely sending a HttpPost. So here is what we learned: the WebApi Controller apparently lets any authorized POST call a single POST function, regardless of the name of the function. I suspect that the WebApi 2 default behavior is probably not intentional. Anyway, it led us off track since we assumed that the function name and URL were ok since the function was, after all, being executed. After making the changes in the link above, we started to get 404 instead of 504 and the source of the problem became evident... We didn't know whether to laugh or cry :-)

ASP.NET WebApi POST Status 405 message for unique signatures from Java app only?

2 Answers2