Механизм обновления протокола в перехватчиках okHttp - PullRequest
0 голосов
/ 30 сентября 2019

Мне нужно обновить мой запрос, чтобы он не обрабатывался по HTTP1.1 до HTTP / 2. Это то, что я попробовал.

public class H2cUpgradeRequestInterceptor implements Interceptor {
    private static final Log logger = LogFactory.getLog(H2cUpgradeRequestInterceptor.class);

    @Override
    public Response intercept(Chain chain) throws IOException {
        Request request = chain.request();
        Request upgradeRequest = request.newBuilder().addHeader("Connection", "Upgrade, HTTP2-Settings")
                .addHeader("Upgrade", "h2c").addHeader("HTTP2-Settings", "AAMAAABkAARAAAAAAAIAAAAA").build();
        Response upgradeResponse = chain.proceed(upgradeRequest);
        if (upgradeResponse != null && upgradeResponse.code() == HttpStatus.SC_SWITCHING_PROTOCOLS) {
            logger.debug("Switching Protocols success"); // Success. Got 101 in reply.
        }
        Response response = chain.proceed(request);
        if (response.protocol() == Protocol.HTTP_2) { // This is returning HTTP1.1 as protocol
            logger.debug("Used upgraded h2c protocol");
        }
        return response;

    }

}

На моем сервере включена поддержка h2c. Я также получаю 101 протокол переключения в моем первом chain.proceed() звонке. Но следующий proceed() всегда дает мне HTTP1.1 в качестве протокола, даже если переключение протоколов прошло успешно. Это правильный путь для обновления протокола? И, если да, как я могу убедиться, что он использует HTTP2 после успешного переключения протокола?

1 Ответ

0 голосов
/ 30 сентября 2019

Закрытие, так как согласно документам

мне не нужно отправлять запрос снова.

Если поле заголовка Upgrade получено в GETЗапрос и сервер решает переключить протоколы, он сначала отвечает сообщением 101 (Switching Protocols) в HTTP / 1.1, а затем сразу же следует это с новым протоколом, эквивалентным ответу на GET на целевом ресурсе. Это позволяет обновить соединение до протоколов с той же семантикой, что и HTTP, без затрат на задержку дополнительного обхода.

После возврата здесь

...