Угловой 6 - HTTP Interceptor и net :: ERR_TIMED_OUT - PullRequest
0 голосов
/ 09 января 2019

У меня вопрос к чему-то, о чем я недавно чесал голову -

В моем перехватчике у меня есть код, который анализирует и обрабатывает определенные ошибки и будет действовать определенным образом в зависимости от кода состояния ошибки и т. Д. (Я не включил этот код, потому что он на самом деле не служил какой-либо цели для этого вопроса , но если у кого-то есть веская причина, почему я должен включить это, я абсолютно могу.

Я пытаюсь понять, как обработать net :: ERR_TIMED_OUT (с помощью Google Chrome / Opera) в моем перехватчике. Я проследил его до такой степени, что могу сказать, что запрос создается и обрабатывается, но после этого запрос и ответ исчезают. Сначала я думал, что где-то есть ошибка XMLHttpRequest, и она каким-то образом подавляется, а ответ отбрасывается.

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const intercepted = this.setHeaders(req);
    return this.SetPendingRequests(next.handle(intercepted))
            .pipe(catchError((err): Observable<HttpEvent<any>> => {
                return this.ParseErrorResponse(err);
            }));
}

Я также пытался добавить к нему finalize(() => {}), и это прекрасно работает во всех случаях, кроме этого, где ERR_TIMED_OUT в основном, кажется, решает, что все должно прекратиться.

Я также пытался подключиться к XMLHttpRequest напрямую, и angular это не восприняло слишком любезно - я чувствую, что корень проблемы может быть связан с самим этим.

Все поиски в google / stackoverflow в значительной степени указывают на то, что это локальная проблема, но я чувствую, что должен быть какой-то способ справиться с этим в моем коде, поэтому, если пользователь столкнется с этой ошибкой при использовании моего приложения, я был бы в состоянии справиться с этим соответствующим образом. По сути, я просто хочу любой запрос на ERR_TIMED_OUT (что, как ни странно, другие базовые ошибки браузера возвращают ошибку типа «Неизвестная ошибка» - это единственный странный выброс, который я обнаружил, который просто останавливает все. чтобы выяснить, не сталкивался ли кто-либо еще с этой проблемой / хотел бы помочь мне разобраться с ней.

Благодарим за любую помощь по этому вопросу и заранее спасибо,

1 Ответ

0 голосов
/ 11 января 2019

Быстрое обновление моей проблемы - кажется, я нашел решение внутри RxJS. Оказывается, у RxJS есть все, и, похоже, это, похоже, решило проблему, с которой я столкнулся (среди прочего, создание других вещей для реагирования на определенные ошибки и т. Д.)

Код перехватчика, который я построил, выглядит примерно так ... (Я выбрал 20000, поскольку в моем случае для Chrome значение по умолчанию составляло 30 секунд для тайм-аута браузера ...)

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const intercepted = this.setHeaders(req);
    return this.SetPendingRequests(next.handle(intercepted))
            .pipe(timeout(20000),
            catchError((err): Observable<HttpEvent<any>> => {
                return this.ParseErrorResponse(err);
            }));
}

Оператор тайм-аута должен возвращать допустимую ошибку, а не снимать 1 и 0 в космосе без гарантии того, что они когда-либо вернутся в случае фактического тайм-аута. Это также отменяет любой тайм-аут на основе браузера (если мой сетевой вызов истекает через 20 секунд от оператора RxJS, то он не будет снова тайм-аут в браузере. Ошибка выдается, и жизнь продолжается). Быть способным реагировать на ошибки - отличная вещь, которую я обнаружил и в обработке ошибок, так что это делает все лучше.

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

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

...