Reputation: 38
I have an App service with MySQL hosted in Azure it has a public API and a Web App. When I use the web app there are no issues. But while accessing the API from the Android application using OKHttp, I am getting the following error :
StatusCode: 404, ReasonPhrase: ‘Site Not Found’, Version: 1.1, Content: ModernHttpClient.ProgressStreamContent, Headers:
{
Date: Thu, 11 May 2017 21:24:58 GMT
OkHttp-Received-Millis: 1494537900018
OkHttp-Sent-Millis: 1494537899773
Server: Microsoft-IIS/8.0
Content-Length: 5147
Content-Type: text/html
OkHttp-Received-Millis: 1494537900018
OkHttp-Sent-Millis: 1494537899773
}
I checked the logs, but couldn't find a 404 response. The issue occures when there are a couple of requests being made fast. Eg : Swapping between tabs where each tab uses the API to load data. And it occurs randomly in other areas too.
UPDATE: This is the response text I am receiving.
Error 404 - Web app not found.
The web app you have attempted to reach is not available in this Microsoft Azure App Service region. This could be due to one of several reasons:
1.The web app owner has registered a custom domain to point to the Microsoft Azure App Service, but has not yet configured Azure to recognize it. Click here to read more.
When an app owner wants to use a custom domain with a Microsoft Azure Web Apps web app, Azure needs to be configured to recognize the custom domain name, so that it can route the request to the appropriate server in the region. After registering the domain with a domain provider and configuring a DNS CNAME record to point to the app's Azurewebsites.net address (for example, contoso.azurewebsites.net), the web app owner also needs to go to the Azure Portal and configure the app for the new domain. Click here to learn more about configuring the custom domains for a web app.
2.The web app owner has moved the web app to a different region, but the DNS cache is still directing to the old IP Address that was used in the previous region. Click here to read more.
With Web Apps, the app is stored in a datacenter located in the region that the web app owner has selected when creating the app, and Azure�s DNS server resolves the web app address that was chosen for it to that datacenter. DNS servers are in charge of resolving the name of the server the user is trying to reach into an IP address, but clients cache this information in order to be able to load the page as fast as possible. If this app was deleted and re-created in another region, the new app will have a different IP address, but the client might still be caching the old IP address. First, try clearing the cache on your client as described here. If this does not help, this is probably due to the caching done on an intermediate DNS server such as the one used by your Internet Service Provider. If so, this issue should clear up soon, once the DNS cache reaches its time-to-live period. Please try to visit the app again in approximately one hour. If you continue to receive this error page, please contact Microsoft support.
UPDATE : Code for Accessing API.
using (var client = new HttpClient(new NativeMessageHandler()))
{
client.BaseAddress = new Uri(BaseUrl);
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(“application/json”));
client.DefaultRequestHeaders.Add(“ZEMOSE-API-KEY”, ZemoseAPIKey);
var response = await client.PostAsync(url, content);
var temp = await response.Content.ReadAsStringAsync();
if (response.IsSuccessStatusCode)
{
var json = await response.Content.ReadAsStringAsync();
var result = await Task.Factory.StartNew(() => JsonConvert.DeserializeObject<RootNode>(json));
return result;
}
else
{
Debug.WriteLine(client.ToString());
Debug.WriteLine(response);
Debug.WriteLine(client.DefaultRequestHeaders);
Debug.WriteLine(await response.Content.ReadAsStringAsync());
var status = new ZemoseStatus();
status.Status = “NoInternet”.Translate();
status.StatusCode = “NoInternet”;
var rootnode = new RootNode();
rootnode.status = status;
rootnode.data = null;
return rootnode;
}
}
Upvotes: 0
Views: 1103
Reputation: 38
I had an extra deployment slot active, that slot was given 10% traffic and was later removed but the changes did not take effect in Testing in production page where 10% traffic was still routed to the old deleted slot. When I removed that static routing the issue was resolved. I assume it was happening due to traffic being routed to that removed Slot.
Upvotes: 0