Вызов отсутствующей конечной точки в. NET Ядро выдает 404, но также и ОК в ответ на Angular - PullRequest
Новая
       4

Вызов отсутствующей конечной точки в. NET Ядро выдает 404, но также и ОК в ответ на Angular

0 голосов
/ 26 января 2020

Звоня в свой бэкэнд, я забыл, что мы изменили имя конечной точки, поэтому я получил 404. Однако я заметил, что предоставленный текст был не Не найден , как ожидалось в такой ситуации, а скорее OK . Как показано на рисунке, корреляция между (правильным) кодом состояния в сообщении об ошибке и (неправильным) названием состояния отсутствует.

enter image description here

Сначала я подозревал, что бэкэнд использовал нечто подобное, забыв правильно классифицировать код состояния ответа. Затем я понял, что это невозможно, поскольку конечная точка не существует, поэтому содержимое не может быть связано с тем, что там выполнено. 

//[HttpGet("coordinates/{id}")]
[HttpGet("coords/{id}")]
public async Task<ActionResult> GetCoordinates(int id)
{
  ...
  // if (output == null)
  //  return NotFound(id);


  return Ok(output);
}

Мне нужна помощь в диагностике проблемы, и в данный момент я Я не уверен, нужно ли касаться бэкэнда или это происходит в Angular. Код для связи с сервером довольно прост для такой книги. 

getCoordinates(id: number): Observable<boolean> {
  return this.http
  .get<boolean>(this.url + "coordinates/" + id);
}

Наблюдаемое затем используется в таком компоненте (логическое значение может быть неожиданным для GET, но в реальном случае это имеет смысл Я работаю над). 

onSave() {
  this.service.getCoordinates(this.id)
    .subscribe(
      suc => this.router.navigate([this.origin]),
      err => console.log(err));
}

Где вероятная точка неправильного обращения с ответом? Или, в некотором смысле, я не знаю, в каком я состоянии? Я не совсем уверен, чтобы сделать здесь суждение.

Я только нашел это , и это только подтверждает, что что-то подозрительно, но не дает намек на то, что. Кроме того, это PHP, поэтому я не уверен насчет актуальности.

Ответы [ 2 ]

3 голосов
/ 26 января 2020

Согласно документации RF C 7540 ,

Для ответов HTTP / 2 одно поле псевдозаголовка ": status" определено
, которое содержит поле кода состояния HTTP (см. [RFC7231],
Раздел 6). Это поле псевдозаголовка ДОЛЖНО быть включено во все
ответов; в противном случае ответ искажен (Раздел 8.1.2.6).

HTTP / 2 не определяет способ переноса версии или фразы причины
, включенной в строку состояния HTTP / 1.1. .

Здесь обсуждается то же самое: https://github.com/whatwg/fetch/issues/599#issue -255768557 .

Fetch spe c просто определяет statusText как значение status message, которое, если не указано иное, равно OK.

Для HTTP / 2 кажется, что сообщение о состоянии может быть интерпретировано любым количеством способов:

  • пустая строка - потому что нет фразы причины "OK"
  • , потому что это всегда стандартная (хотя было бы странно иметь 404 ОК) реализация, определенная
  • , например, какая-то причина по умолчанию текст для кода состояния
1 голос
/ 27 января 2020

statusText: 'OK' соответствует RF C, см. Здесь .

Тем не менее, вы можете настроить свой ответ в. NET основной WebAPI с промежуточным программным обеспечением (, как показано здесь ).

Вот пример пользовательской обработки ошибок в нашем приложении

Startup.cs 

public class Startup
{
    public void Configure(
        IApplicationBuilder app,
        IHostingEnvironment env,
        IApiVersionDescriptionProvider provider,
        VersionedODataModelBuilder builder)
    {
        app.UseMiddleware<ErrorHandling>();

ErrorHandling.cs 

public class ErrorHandling
{
    public ErrorHandling(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await next(context);
        }
        catch (Exception ex)
        {
            await HandleExceptionAsync(context, ex);
        }
    }

    private static Task HandleExceptionAsync(HttpContext context, Exception ex)
    {
        // Error handling code here
        // For example if you want to set a specific statusCode
        context.Response.StatusCode = MySpecificStatusCode;
...