webpack dev-server: избегайте ошибок прокси при ошибках HTTP, возвращаемых из цели прокси - PullRequest
0 голосов
/ 13 февраля 2019

У меня есть проект Vue.js, в котором я настроил dev-сервер веб-пакета для передачи всех запросов к пользовательскому интерфейсу на мой внутренний сервер.Вот соответствующая часть vue.config.js:

devServer: {
    contentBase: PATHS.build,
    port: 9000,
    https: false,
    hot: true,
    progress: true,
    inline: true,
    watchContentBase: true,
    proxy: {
        '^/': {
            target: 'http://127.0.0.1:8089',
            secure: false
        },
    }
},

Я заметил, что если код ответа HTTP от http://127.0.0.1:8089 отличается от 2xx, то прокси завершается ошибкой со следующимошибка:

Ошибка прокси: не удалось прокси-запрос / API / тест с локального хоста: от 9000 до http://127.0.0.1:8089. См. https://nodejs.org/api/errors.html#errors_common_system_errors для получения дополнительной информации (HPE_INVALID_CHUNK_SIZE).

Это также приводит к тому, что код HTTP-ответа от запроса к localhost: 9000 будет равен 500 для любой ошибки, и вся информация о том, что пошло не так на стороне сервера, будет потеряна.Это проблематично, так как я хочу иметь возможность извлекать информацию из ответов об ошибках для отображения пользователю.

Я знаю, что это можно сделать, потому что он работал над более старым проектом Angular, который, я думаю, использовал Webpack 3(сейчас использую Webpack 4).Я попытался скопировать всю конфигурацию dev-сервера из этого проекта, но, похоже, он здесь не работает!

РЕДАКТИРОВАТЬ: я был не прав.Ошибка прокси-сервера возникает не при каждом неправильном ответе, а только для одного из запросов, который является загрузкой файла из нескольких частей.Все еще неспособен воспроизвести это в меньшем примере, чтобы поставить github, хотя так изо всех сил пытается определить причину.

Ответы [ 2 ]

0 голосов
/ 19 февраля 2019

Я наконец-то нашел проблему, и я прошу прощения, это была гораздо более конкретная проблема, чем я думал, когда писал вопрос.

Проблема заключалась в том, что запрос был передан надругой сервер, использующий Spring RestTemplate:

например,

@PostMapping("/upload")
    public ResponseEntity upload(@RequestParam("file") MultipartFile file)
        throws Exception {
        String baseUrl = serviceProperties.getAddress();
        HttpEntity<MultiValueMap<String, Object>> request = createMultipartRequest(file.getBytes());
        return restTemplate.postForEntity(baseUrl + "/api/upload", filterRequest, String.class);
    }

ResponseEntity, возвращаемый из прокси шаблона остатка, содержал заголовок "Connection: close", когда ответ был чем-то отличным от 200, что вызываетсоединение закрылось, и этот запрос не смог вернуть ничего, что впоследствии привело к сбою прокси-сервера dev-server в пользовательском интерфейсе.

Исправлено это, когда заголовок ответа не передавался из прокси остального шаблона в ответ:

@PostMapping("/upload")
    public ResponseEntity upload(@RequestParam("file") MultipartFile file)
        throws Exception {
        String baseUrl = serviceProperties.getAddress();
        HttpEntity<MultiValueMap<String, Object>> request = createMultipartRequest(file.getBytes());
        ResponseEntity response = restTemplate.postForEntity(baseUrl + "/api/upload", filterRequest, String.class);
        return new ResponseEntity<>(response.getBody(), response.getStatusCode());
    }
0 голосов
/ 18 февраля 2019

Это сообщение об ошибке приходит от node_modules/@vue/cli-service/lib/util/prepareProxy.js, который определяет обратный вызов onError для node-http-proxy;

Итак, я провел некоторый эксперимент, заставив back-end api генерировать ответ 400 404 500, но я этого не сделалполучил эту ошибку.

После того, как мне удалось закрыть внутренний API, возникает ошибка:

Proxy error: Could not proxy request /hello from localhost:8080 to http://localhost:8081 (ECONNREFUSED).

Я ищу в документ и нахожу это:

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

Так что onError не обрабатывать код ошибки, вызывается только при сбое запроса (500 response по-прежнему обрабатывается как полный запрос, connection refuse нет)


Вернуться к сообщению об ошибке, [HPE_INVALID_CHUNK_SIZE] означает неверный запрос к интерфейсу API сервера.В этой проблеме она дает решение: add a keep-alive header:

devServer: {
    publicPath: 'http://localhost:9090/front/static-dev/build/',
    port: 9090,
    proxy: {
        '/**': {
            target: 'http://localhost:8080',
            secure: false,
            changeOrigin: true,
            headers: {
                   Connection: 'keep-alive'
            }
    },
    open: true
}
...