I try to update an object with WEB API hosted on a remote server. I recover well the object but at the time of the change, the answer gives 404 method not Allowed. I tested to host my service in a machine of my colleague just nearby. It works well. Is what is needed to make a configuration or something else?
Thank you a lot.
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
HttpResponseMessage responsse = client.PutAsJsonAsync("api/Collaborateurs/" + coll.matricule_collaborateur, coll).Result;
if (responsse.IsSuccessStatusCode) {
}
Error:
{StatusCode: 405, ReasonPhrase: 'Method Not Allowed', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Date: Thu, 12 Nov 2015 14:28:10 GMT
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Content-Length: 1343
Allow: GET
Allow: HEAD
Allow: OPTIONS
Allow: TRACE
Content-Type: text/html
}}
WebDAV is know to interfere with the verb PUT. Try uninstalling WebDAV if it is present on the server and you do not use it.
It may also be that you need to contact the remote server's administrator. PUT is sometimes blocked by network switches/routers. I.e. there well may be nothing you can do to fix this with code. Try using POST instead.
Related
i have a service .svc hosted on a machine whit windows server 2019 on IIS 10,
im tryng to send a POST request whit postman sending a json whit the following headers:
Postman-Token: calculated when request is sent>
Content-Lenght: calculated when request is sent
Host: calculated when request is sent
Accept: * / *
Content-Type: application/json
and this in the body:
{
"orderNumber": "12345",
"idTransaction":"1",
"authorization":"auth",
"amount":"14.95",
"paymentDate":"2020-01-01",
"currency":"euro",
"resultCode": "ok"
}
the service responds correctly and read the json but the status is "406 Not Accettable"
as you can see i have placed the Accept header whit value "* / *" that mean accept every kind of content-type and that is the response that i get
response headers:
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Mon, 04 Jan 2021 09:54:27 GMT
Content-Length: 69
response body
"Not found any payment whit numeroOrdine=12345."
the server/service read the json and respond corretly couse the number of order 12345 was an example and dosent exist,
but whit status code 406 not accetable,
i tryed also to add the header Accept-Charset: UTF-8 in the request but the situation dosent change,
i checked on iis on the server and after select on the mime type list i can that application/json is in the list,
Mime type IIS
maybe i have to enable it somewhere else? Specify the mime type in the web.config file?
or it could be something else?
thanks in advance
I have a little Web API, almost directly from the standard VS project template, i.e. Home and Values controllers, and lots of MVC cruft. It is set to run and debug under IIS 10.
I have set up tracing by adding the package Microsoft.AspNet.WebApi.Tracing and the following code in WebApiConfig:
public static void Register(HttpConfiguration config)
{
config.EnableSystemDiagnosticsTracing();
SystemDiagnosticsTraceWriter traceWriter = config.EnableSystemDiagnosticsTracing();
traceWriter.IsVerbose = true;
traceWriter.MinimumLevel = TraceLevel.Debug;
config.Services.Replace(typeof(ITraceWriter), new SimpleTracer());
...
...
}
SimpleTracer is an ITraceWriter that writes to a text file.
When I call the API from outside the VS ecosystem, i.e. from PostMan in Chrome, a bad url, that results in a 404 error message, and the creation of a new trace file if there's not already one. Of I call it from PostMan with a good url, I get the expected result, and a trace of the request in the trace file.
When I call it from my Console app, even with a good url, I still get a 404 error response, and nothing is written to the trace file. I made sure by removing it and IIS doesn't even re-create it when using the .exe client.
If I call it from the compiled .exe from outside VS, I get the same error.
Then, when I set the Web API to use IIS Express, everything works perfectly. Do I need CORS for calls from non-web apps, does IIS need an extra header in this case? What is wrong?
EDIT A: This is the request when I use PostMan, and it returns a 200 and the expected list of strings.
GET /DemoApi/api/values HTTP/1.1
Host: localhost
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: f9454ffc-6a8d-e1ed-1a28-23ed8166e534
and the response and headers:
["value1","value2","value3","value4","value5","value6","value7"]
Cache-Control →no-cache
Content-Length →64
Content-Type →application/json; charset=utf-8
Date →Tue, 13 Dec 2016 06:20:07 GMT
Expires →-1
Pragma →no-cache
Server →Microsoft-IIS/10.0
X-AspNet-Version →4.0.30319
X-Powered-By →ASP.NET
EDIT B: This is the request sent using HttpClient:
GET http://abbeyofthelema/api/values HTTP/1.1
Accept: application/json
Host: abbeyofthelema
Connection: Keep-Alive
The only real difference is that because Fiddler doesn't capture traffic from localhost, I had to use my computer name instead. The same recipient still gets the request.
The response here is:
HTTP/1.1 404 Not Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Tue, 13 Dec 2016 08:07:25 GMT
Content-Length: 4959
According to Timothy Shields at the following link
Why is HttpClient BaseAddress not working?
You must place a slash at the end of the BaseAddress, and you must not place a slash at the beginning of your relative URI
I've publish my Web-Api2 on a development server (Windows 2012 Server and IIS8.5).
I've added the Websockets Protocol role, and also went through the steps in this answer to make sure everything is set up on my side. The app is running under `Default Web Site'.
However, I'm still getting this error:
Microsoft.AspNet.SignalR.Client.HttpClientException: StatusCode: 404,
ReasonPhrase: 'Not Found', Version: 1.1, Content:
System.Net.Http.StreamContent, Headers:
{
Date: Fri, 15 Jul 2016 09:18:54 GMT
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Content-Length: 1285
Content-Type: text/html
}
at Microsoft.AspNet.SignalR.Client.Http.DefaultHttpClient
<>c__DisplayClass2.<Get>b__1(HttpResponseMessage responseMessage)
at Microsoft.AspNet.SignalR.TaskAsyncHelper.<>c__DisplayClass19`2
<Then>b__17(Task`1 t)
at Microsoft.AspNet.SignalR.TaskAsyncHelper.TaskRunners`2
<>c__DisplayClass42.<RunTask>b__41(Task`1 t)
Do I need to add other server roles or configure IIS further?
The problem was on the client side of the application as shown from here Microsoft.AspNet.SignalR.Client.HttpClientException
The status code was 404 Not Found.
The problem was a wrong url passed to the hub connection after deploying from localhost to an actual IIS running in Windows 2012 server. Once the url was fixed, the client runs without problems.
I am using the LinkedIn Owin Middleare and started running into issues this morning and have now reproduced it to the below error:
POST https://www.linkedin.com/uas/oauth2/accessToken HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Host: www.linkedin.com
Cookie: bscookie="v=1&201504071234373bc02b47-9d08-477f-8375-b80b281ef416AQEptFjv8jXPI93YmF-H-3kvnwSLwBF8"; bcookie="v=2&46f6f299-6702-48bf-8634-7ba023bd5099"; lidc="b=LB23:g=218:u=215:i=1428412320:t=1428487523:s=AQEQQq6vlEKPT3LW8c0cPEzRTKp-ToxL"
Content-Length: 267
Expect: 100-continue
Connection: Keep-Alive
grant_type=authorization_code&code=AQQRSgEH8vczSFJKNxtMpunzjYN6YJxoF2hiX_d9RVkqBvMC7TzRpur0p9NJFdQOUNf8RmFyj_cCg3ENTucRw5e-gQfEZ5sPGoujiFRsQ8Tb0pLnaog&redirect_uri=http%3A%2F%2Flocalhost%3A1729%2Fsignin-linkedin&client_id=&client_secret=
Results in method not found.
HTTP/1.1 405 Method Not Allowed
Date: Tue, 07 Apr 2015 13:13:16 GMT
Content-Type: text/html
Content-Language: en
Content-Length: 5487
X-Li-Fabric: PROD-ELA4
Strict-Transport-Security: max-age=0
Set-Cookie: lidc="b=LB23:g=218:u=215:i=1428412396:t=1428487523:s=AQExeP2uX-7KXQv79NIZmW0LB09uE4eJ"; Expires=Wed, 08 Apr 2015 10:05:23 GMT; domain=.linkedin.com; Path=/
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Connection: keep-alive
X-Li-Pop: PROD-IDB2
X-LI-UUID: 0FM/jIG90hPAzyhAqCsAAA==
Looking for anyone to confirm that there was a change on linkedin causing this error and that its not application specific.
Note that i removed teh above clientid/secrets.
I also spent most of the morning off and on trying to get this to work. Frustratingly it worked fine using Advanced Rest Client chrome tool. A combination of this and fiddler showed the only difference in the header was that Expect: 100-continue flag in the header. The only way I was able to get it to be set to false was in the web.config section
<system.net>
<settings>
<servicePointManager expect100Continue="false" />
</settings>
</system.net>
Hope this helps.
I ran into this issue this morning too (I'm using DotNetOpenAuth). It looks like this is related to the use of the following request header: Expect: 100-continue
After removing this request header, the HTTP/1.1 405 Method Not Allowed response no longer occurs. Obviously this isn't much help if you don't have access to the source code!
I'm assuming this is due to a change in LinkedIn as I only started experiencing problems this morning. I'm guessing they'll need to look into a fix for this.
I started having this issue today. After some research about Expect: 100-continue I found that putting
System.Net.ServicePointManager.Expect100Continue = false;
in my Application_Start() function inside of Global.asax, takes out the 100-continue from the request and my login with LinkedIn is now working again.
Not a permanent fix as I would like to now why it broke in the first place.
I had same issue also use DotNetOpenAuth.
How I fix:
I remove from request header "Expect: 100-continue"
in my case redirect_uri was encoded and I remove encode for redirect_uri (for request to https://www.linkedin.com/uas/oauth2/accessToken )
For those using Owin Middleware and Owin.Security.Providers
A pre-release nuget was created with a fix.
https://www.nuget.org/packages/Owin.Security.Providers/1.17.0-pre
This works for now. But until we know what linkedin has changed or comes with statement about what they changed people can use this as a hotfix.
Alittle more background on the fix can be found at :
https://github.com/RockstarLabs/OwinOAuthProviders/issues/87#issuecomment-90838017
But the root cause is that LinkedIn changed something on there accessToken endpoint causing most of the libs using linkedin SSO had to apply a hotfix, but we yet haven't heard anything from linkedin.
Found a solution for curl, pretty simple:
curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:') );
I'm trying to use a batch file with WGET to download the public FCC file from here
http://wireless.fcc.gov/uls/data/complete/l_micro.zip
When I intially run the batch file with parameters
wget --server-response -owget.log http://wireless.fcc.gov/uls/data/complete/l_micro.zip
It fails with an HTTP 401 unauthorized error. I can retry at this point and it keeps failing. However I noticed if I open up IE, start a download and cancel when prompted to save, I can rerun the batch file and it executes perfectly!
Here is my detailed server response from the log
--2012-02-06 14:32:24-- http://wireless.fcc.gov/uls/data/complete/l_micro.zip
Resolving wireless.fcc.gov (wireless.fcc.gov)... 192.104.54.158
Connecting to wireless.fcc.gov (wireless.fcc.gov)|192.104.54.158|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 302 Found
Location: REMOVED - appears to have my IP
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Connection: close
Content-Length: 513
Location: REMOVED [following]
--2012-02-06 14:32:24-- REMOVED
Resolving REMOVED... 192.168.2.11
Connecting to REMOVED|192.168.2.11|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Pragma: no-cache
WWW-Authenticate: NTLM
WWW-Authenticate: BASIC realm="AD_BCAAA"
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-8ECFB6B4AA642EF0=2; Path=/
Connection: close
Content-Length: 575
Authorization failed.
Here is the log after doing my little IE procedure and getting it to work
--2012-02-08 15:52:43-- http://wireless.fcc.gov/uls/data/complete/l_micro.zip
Resolving wireless.fcc.gov (wireless.fcc.gov)... 192.104.54.158
Connecting to wireless.fcc.gov (wireless.fcc.gov)|192.104.54.158|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: Sun-Java-System-Web-Server/7.0
Date: Fri, 27 Jan 2012 18:37:51 GMT
Content-type: application/zip
Last-modified: Sun, 22 Jan 2012 11:18:09 GMT
Etag: "46fa95c-4f1bf071"
Accept-ranges: bytes
Content-length: 74426716
Connection: Keep-Alive
Age: 1045014
Length: 74426716 (71M) [application/zip]
Saving to: `l_micro.zip'
Any help is appreciated!
If the website has simply a htpassword setup, you can try:
wget --user=admin --ask-password https://www.yourwebsite.com/file.zip
I used --auth-no-challenge and the exact error get solved .
You have a Blue Coat secure web gateway on your network, as evidenced by the line in the response:
Set-Cookie: BCSI-CS-8ECFB6B4AA642EF0=2; Path=/
It looks like it wants you to authenticate, presumably with your domain credentials. Try passing them with --http-user and --http-passwd.
I had a similar issue with the xwiki based site. after several attempts I found some combination that worked for me just fine
wget --no-check-certificate --auth-no-challenge -k -nc -p -l 1 -r https://user:password#host.domain
I think the key was --auth-no-challenge
Try using this extension for firefox. It generates a wget or a curl command that can be copied and run from bash.
I came here trying to find out why wget was giving a 401 unauthorized message when on another system the problem did not occur.
After installing a later version of wget from source (binary was not available in my distro) it worked. I can't explain why, except that it must be some kind of bug so if none of the above fixes your problem, consider upgrading wget.
Try setting a user-agent string with wget - e.g.
--user-agent=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
it's entirely feasible for a site to reject requests from certain user agents, particularly if they look to be circumventing the "usual" routes to information (i.e. through webpages).
Although this doesn't explain your problem, it's a good idea anyway. Perhaps the site implements a mechanism whereby when you browse with a "known" browser (e.g. IE) it then caches your IP as "safe" then allows any user agent from your IP to download anything :)