Код состояния HTTP 500, ошибки .net core CORS и HttpClient - PullRequest
0 голосов
/ 09 мая 2018

У меня есть некоторые проблемы, связанные с CORS / HttpClient в ядре dotnet. Прежде всего, мое приложение структурировано так:

Webapp -> Microservice-Gateway -> multiple Microservices

Если я делаю Ajax-вызов из моего Webapp

$.ajax({
        url: "https://[actual gateway Url]/customer/" + customerId,
        type: "GET",
        timeout: 60000,
        crossDomain: true,
        dataType: "json",
        success: data => {
            //...
        }
    });

Шлюз-серверу иногда получаю следующее сообщение об ошибке:

Нет заголовка «Access-Control-Allow-Origin» в запрошенном ресурс. Происхождение 'http://localhost:50595' поэтому не допускается доступ. Ответ имеет HTTP-код состояния 500.

Внутренне, однако, мой шлюз выдает эту ошибку, если я отлаживаю:

System.Net.Http.HttpRequestException: при отправке произошла ошибка запрос. ---> System.Net.Http.WinHttpException: операция тайм-аут

Я попытался устранить первую ошибку, добавив следующий код в шлюз и каждый микросервис:

public void ConfigureServices(IServiceCollection services) {
        var corsBuilder = new CorsPolicyBuilder();
        corsBuilder.AllowAnyHeader();
        corsBuilder.AllowAnyMethod();
        corsBuilder.AllowAnyOrigin();
        corsBuilder.AllowCredentials();

        services.AddCors(options => {
            options.AddPolicy("SiteCorsPolicy", corsBuilder.Build());
        });
 //..
 }
 public void Configure(IApplicationBuilder app, IHostingEnvironment env) {
        app.UseCors("SiteCorsPolicy");
 //..
 }

И просто чтобы быть уверенным, что я также добавил

[EnableCors("SiteCorsPolicy")]

каждому контроллеру. Вторую проблему, которую я попытался решить, создав HttpClient как Singleton в моем шлюзе и изменив следующие свойства:

var client = new HttpClient();
client.Timeout = new TimeSpan(0, 10, 0);
client.DefaultRequestHeaders.Accept.Clear();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
services.AddSingleton(client);

Мой шлюз отправляет такие HTTP-запросы:

[HttpGet("{id}")]
public async Task<JsonResult> GetById(int id) {
    var response = await _client.GetAsync(new Uri(ServiceUrls.Customer + $"{id}"));

    if (!response.IsSuccessStatusCode)
        return new JsonResult(BadRequest($"{(int)response.StatusCode}: {response.ReasonPhrase}"));

    var customer = JsonConvert.DeserializeObject<CustomerViewModel>(await response.Content.ReadAsStringAsync());
    return new JsonResult(customer);
}

Как я уже сказал, иногда это работает, а иногда нет. Может быть, вы могли бы дать мне несколько идей, в чем моя ошибка. Заранее спасибо!

Edit: проблема, кажется, появляется чаще, если есть несколько асинхронных ajax-вызовов из Webapp одновременно. Но это тоже может быть просто чувство.

Ответы [ 3 ]

0 голосов
/ 09 мая 2018

Хорошо, ребята,

спасибо, что вывели меня в правильном направлении. Я думаю, что нашел решение / исправить. Мне пришлось установить следующее свойство в моем шлюзе:

ServicePointManager.DefaultConnectionLimit = int.MaxValue;
0 голосов
/ 26 июня 2018

Я тоже сталкивался с этой проблемой, .NET Core 2.0 не возвращает коды состояния http для ответов не-200 и не-300. Я исправил это, создав промежуточную одежду для создания ответа, который будет отправлен обратно клиенту.

Вы можете посмотреть все шаги здесь: https://medium.com/@arieldiaz92/net-core-2-0-fix-that-http-status-0-error-by-sending-cors-headers-on-failures-12fe3d245107

0 голосов
/ 09 мая 2018

Это, вероятно, не имеет ничего общего с вашей настройкой CORS. При возникновении ошибки (например, при вызове HTTP с использованием HttpClient) промежуточное ПО обработчика исключений по умолчанию удаляет все заголовки ответа и возвращает ответ об ошибке. Это означает, что любой заголовок CORS, добавленный вашей политикой, будет удален, поэтому вы получите сообщение об ошибке «В запрошенном ресурсе отсутствует заголовок« Access-Control-Allow-Origin ».".

Чтобы преодолеть это, вы должны сами обработать любые исключения в контроллере и вернуть соответствующий результат ошибки, либо написать промежуточное программное обеспечение до или заменить промежуточное программное обеспечение по умолчанию исключением своей собственной логикой обработки исключений.

Существует также открытая проблема GitHub об этом поведении: https://github.com/aspnet/Home/issues/2378.

...