I am trying to reach an endpoint hosting a json from an Azure function.
I can access the url from my machine in a browser or when executing the code.
But from Azure I keep getting a 406.
the code is pretty simple and as follow:
var client = new HttpClient();
client.DefaultRequestHeaders
.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
var response = await client.GetAsync(endpointurl);
response.EnsureSuccessStatusCode();
this keeps giving me the 406 when hosted on Azure, not on local ...
Any idea how to get more information? How to debug/fix that?
Thanks
406 is one of the HTTP Response Status codes which indicates that something is NOT ACCEPTABLE.
From you code we are requesting something with Accept header, but the server is unable to fulfill it.
Also, as 406 will comes under 4XX which is client error responses.
In our case, we are requesting a specific content type to be returned by the server. For ex: Accept: application/json or application/xml, so here server is unable to respond to the matching content type that was requested. This leads to throwing a 406 Not Acceptable error.
Most possible situation of cause the error is with the endpoint URL and it show have access to it. As you mentioned that it is working on local, there should be some parameters assigning. Like adding connections like local.settings.json to Application settings in Azure portal, CORS to your endpoint..
Check for private endpoint info from MS Docs
To understand more about 406 Not Acceptable Error refer to blog, thanks to airbrake.io
Related
I am using create-sent.net version 2.2 for CampaignMonitor. But recently I get this error:
System.Net.WebException: The remote server returned an error: (406) Not Acceptable.
at createsend_dotnet.HttpHelper.MakeRequest[T,U,EX](String method, CreateSendCredentials authCredentials, String path, NameValueCollection queryArguments, T payload)
from the service. Would there be any problem in HTTP header content-type?
Figured out the problem. The API was moved to HTTPS only. but inside our Http Request, we used HTTP URL. due to that reason the API returns (406) Not Acceptable code.
Your service is saying that the response type returned is not provided in the Accept HTTP header in your Client request.
Ref: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Find out the response (content type) returned by Service.
Provide this (content type) in your request Accept header.
So you will have to supply a different one which is acceptable to the server.
In implementing a server Paypal integration, the POST Create call works correctly to https://api.sandbox.paypal.com/v1/payments/payment with the response object matching that found in the API. The server successfully returns the result to the Client, and res.id for the .then(res) function of paypal.request.post is: PAY-76T970067E989851JLPLCMKA
After the user authorizes payment, the client sends a request to my server's execute endpoint with a payload of:
{
"paymentID" : "PAY-76T970067E989851JLPLCMKA",
"payerID" : "3LSD3Q8J7T3ZL"
}
The server then remodels the payload for a query to paypal's POST Execute endpoint as follows:
headers:
Content-Type = "application/json"
Authorization = "Bearer " + accessToken // checked not expired
and a body payload of:
{"payer_id" : "3LSD3Q8J7T3ZL"}
The post is then made to:
https://api.sandbox.paypal.com/v1/payments/payment/PAY-76T970067E989851JLPLCMKA/execute
at which point, the paypal server responds with: The remote server returned an error: (400) Bad Request.
Form what I can see, this matches the API requirements outlined here: https://developer.paypal.com/docs/api/payments/v1/#payment_execute
As a side note, I setup an endpoint on my own server to check the headers and JSON payload being submitted to the Paypal execute endpoint are correct.
Any suggestions would be greatly appreciated.
Resolved: Although the error is being returned when calling the Paypal's Execute endpoint, the problem actually resides in the Create payload. The soft_descriptor property submitted to the Create endpoint must be unique, just like the invoice_number property. Both of these values are found in the Transaction object, as shown here:
https://developer.paypal.com/docs/api/payments/v1/#definition-transaction.
Really, the error should be caught when creating the payment and not when executing it, but, hopefully this helps someone else.
Note to Paypal: A bit more information in the API would have saved a lot of headaches.
As usual, in .NET 4.5, I used a HttpClient to send a get request to restful service (a remote server)
However, this time, it returned error 415 - Unsupported Media Type.
I'm expecting the request header including Content-Type = application/json.
And I cannot find a way to set Content-Type correctly.
Anybody has experience for this case or any suggestion will be appreciated!
The code is as below and the httpResponseMessage.RequestMessage.Headers
Updated 1
As I researched, I cannot add a retricted header for Content-Type. Since this is 4.5 implementation. Is this correct?
Updated 2
I tried to add
request.Content.Headers.ContentType = new MediaTypeHeaderValue("application/json");
However it returned Cannot send a content-body with this verb-type
I am guessing that your server is not complaining about the invalid content type you requested but about the content type you sent with that request.
That you get
Cannot send a content-body with this verb-type
seems to hint that your tried to send a GET request. It is rather unusual (allthough technically the HTTP protocol allows this) that servers require a GET request with a body. So my best guess is that there is something wrong with the server.
This ServiceStack client code works:
var client = new JsonServiceClient("http://localhost:32949/test");
var request = new MyRequest { ClassificationId = new ClassificationId (21300) };
var response = client.Post(request);
However, when observing the traffic in Fiddler, I see nothing. I would like to observe the traffic to get a better idea on how to build the required JSON request for other clients I have to write.
To make the above code work, I had to reference the assembly that has the service, and I am suspecting that ServiceStack is making some clever calls to avoid sending a HTTP request. Is this the case ?
Why am I not seeing any traffic in Fiddler, and how do I force it ?
HTTP traffic to localhost endpoints via the browser is shown correctly.
Edit your hosts file, located at
C:\Windows\System32\drivers\etc\hosts
and add the following entry
127.0.0.1 mymachine.com
then point your client to mymachine.com instead of localhost
I will answer my own question here - commenter #wal pointed out the problem to me:
This has nothing to do with ServiceStack, and requests actually go over the http protocol. The problem was looping back to localhost did not send the traffic through fiddler. It is actually explained on the Fiddler2 FAQ page.
The other trick is to replace your "localhost" uri with your machine name, and that should work out of the box with Fiddler.
http://machinename:port/test
I have a Silverlight (v3) application that uses WebRequest to make an HTTP POST request to a webpage on the same website as the Silverlight app. This HTTP request gets back a 302 (a redirect) to another page on the same website, which HttpWebRequest is automatically supposed to follow (according to the documentation).
There's nothing particularly special about the code that makes the request (it uses the browser's HTTP stack, it is not configured to use the alternate inbuilt Silverlight HTTP stack):
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Format("{0}?name={1}&size={2}", _UploadUrl, Uri.EscapeUriString(Name), TotalBytes));
request.Method = "POST";
All this works fine in Firefox and Chrome; Silverlight makes the POST HTTP request, receives a 302 response and automatically does a GET HTTP request of the specified redirect URL and returns that to me (I know this because I used Fiddler to watch the HTTP requests going on).
However, in Internet Explorer (v8), Silverlight does the POST HTTP request and then throws a WebException with a 404 error code!
Using Fiddler, I can see that Silverlight/Internet Explorer was successfully returned the 302 status code for the request, and I assume that the 404 status code (and associated WebException) that I get in Silverlight is because as far as I know HTTP requests that are done via the browser stack can only return 200 or 404 due to limitations. The real question is why does Internet Explorer not follow through the redirect like the other browsers?
Thanks in advance for any help!
EDIT: I would prefer not to use the Silverlight client HTTP stack because to my knowledge requests issued by it do not include cookies that are a part of the browser's session, critically including the ASP.NET authentication cookie that I need to be attached to the HTTP requests being made by the Silverlight control.
EDIT 2: I have discovered that Internet Explorer only exhibits this behaviour when you do a POST request. A GET request redirects successfully. This seems like pretty bad behaviour considering how many websites now do things in the Post-Redirect-Get style.
IE is closer to the specification, in that in responding to a 302 for a POST the user agent should send a POST (though it should not do so without user confirmation).
On the other hand, FF and Chrome are deliberately wrong, in copying ways in which user agents were frequently wrong some considerable time ago (the problem started in the early days of HTTP).
For this reason, 307 was introduced in HTTP/1.1 to be clearer that the same HTTP method should be used (i.e. in this case, it should be a POST) while 303 has always meant that one should use GET.
Therefore, instead of doing Response.Redirect which results in a 302 - that different user agents will handle in different ways, send a 303. The following code does so (and includes a valid entity body just to be within the letter of the spec). There is an overload so you can call it with either a Uri or a string:
private void SeeOther(Uri uri)
{
if(!uri.IsAbsoluteUri)
uri = new Uri(Request.Url, uri);
Response.StatusCode = 303;
Response.AddHeader("Location", uri.AbsoluteUri);
Response.ContentType = "text/uri-list";
Response.Write(uri.AbsoluteUri);
Context.ApplicationInstance.CompleteRequest();
}
private void SeeOther(string relUri)
{
SeeOther(new Uri(Request.Url, relUri));
}
I believe this was a feature change in Internet Explorer 7, where by they changed the expected 200 response to a 302 telling IE to be redirected. There is no smooth solution to this problem that I know off. A similar question was posed a while back here.
Change in behavior with Internet Explorer 7 and later in regard to CONNECT requests