Как заставить HTTP-клиента Apache 4.0.1 (org.apache.httpcomponents) автоматически перенаправлять на получение после публикации?

Question

Согласно документации, http-клиент apache должен автоматически перенаправлять.Я отправляю сообщение на сервер, и оно перенаправлено.К сожалению, обработчик ответа возвращает пустую строку.Он просто не следует за редиректом и не дает мне этот контент напрямую.Есть ли простой способ заставить клиента следовать перенаправлениям?

Answer 1

Вы могли видеть результат особенно уродливой области RFC-2616 . Заголовок Location используется для перенаправления клиента в зависимости от точного кода состояния. Интересными являются 201, 301, 302 и 303. Правильная обработка сильно зависит от того, какую из них вы получаете. Я предполагаю, что вы должны получить 303 See Other и получить другой код и , ваш клиент следует различным HTTP-спецификациям.

Я не знаю поведение HTTP-клиента Apache, но я знаю, что во многих реализациях сервера и клиента это поведение неправильно. Вот соответствующие фрагменты RFC-2616. Я прошу прощения за этот довольно многословный ответ.

10.2.2. 201 Создано

Запрос был выполнен, и в результате был создан новый ресурс. На вновь созданный ресурс могут ссылаться URI, возвращенные в объекте ответа, с наиболее конкретным URI для ресурса, заданным в поле заголовка Location. Ответ ДОЛЖЕН включать в себя объект, содержащий список характеристик и местоположений ресурсов, из которых пользователь или пользовательский агент может выбрать наиболее подходящий. Формат объекта определяется типом мультимедиа, указанным в поле заголовка Content-Type. Сервер происхождения ДОЛЖЕН создать ресурс перед возвратом кода состояния 201. Если действие не может быть выполнено немедленно, сервер ДОЛЖЕН ответить 202 (Принятым) ответом.

10.3.2. 301 перемещено навсегда

Запрошенному ресурсу был назначен новый постоянный URI, и любые будущие ссылки на этот ресурс ДОЛЖНЫ использовать один из возвращенных URI. Клиенты с возможностями редактирования ссылок должны автоматически связывать ссылки на Request-URI с одной или несколькими новыми ссылками, возвращаемыми сервером, где это возможно. Этот ответ кешируется, если не указано иное.

Новый постоянный URI ДОЛЖЕН быть задан полем Location в ответе. Если метод запроса не является HEAD, объект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылкой на новый URI.

Если код состояния 301 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых запрос выдан.

Примечание. При автоматическом перенаправлении запроса POST после получения кода состояния 301 некоторые существующие пользовательские агенты HTTP / 1.0 по ошибке изменят его на запрос GET.

10.3.3. 302 найдено

Запрашиваемый ресурс временно находится под другим URI. Поскольку перенаправление может иногда изменяться, клиент ДОЛЖЕН продолжать использовать Request-URI для будущих запросов. Этот ответ может быть кэширован, только если он указан в поле заголовка Cache-Control или Expires.

Временный URI ДОЛЖЕН быть задан полем Location в ответе. Если метод запроса не является HEAD, объект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылкой на новый URI.

Если код состояния 302 получен в ответ на запрос, отличный от GET или HEAD, пользовательский агент НЕ ДОЛЖЕН автоматически перенаправлять запрос, если он не может быть подтвержден пользователем, поскольку это может изменить условия, при которых запрос был выдано.

Примечание. RFC 1945 и RFC 2068 указывают, что клиенту не разрешено изменять метод в перенаправленном запросе. Однако большинство существующих реализаций пользовательского агента обрабатывают 302 так, как если бы это был ответ 303, выполняя GET для значения поля Location независимо от исходного метода запроса. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно прояснить, какой тип реакции ожидается от клиента.

10.3.4 303 См. Другое

Ответ на запрос может быть найден под другим URI и ДОЛЖЕН быть получен с использованием метода GET для этого ресурса. Этот метод существует главным образом, чтобы позволить выводу сценария, активированного POST, перенаправить пользовательский агент на выбранный ресурс. Новый URI не является заменой ссылки на первоначально запрошенный ресурс. Ответ 303 НЕ ДОЛЖЕН кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэширован.

Другой URI ДОЛЖЕН быть задан в поле Location в ответе. Если метод запроса не является HEAD, объект ответа ДОЛЖЕН содержать краткую гипертекстовую заметку с гиперссылкой на новый URI.

Примечание. Многие пользовательские агенты до HTTP / 1.1 не понимают состояние 303. Когда возникает проблема взаимодействия с такими клиентами, вместо этого можно использовать код состояния 302, поскольку большинство пользовательских агентов реагируют на ответ 302, как описано здесь для 303.

Answer 2

Я пробовал это с Apache HttpComponents 4.3.5, Вы должны указать свою стратегию перенаправления, чтобы следовать перенаправлениям.

Вот как я это сделал.

HttpClient httpClient = HttpClients.custom()
                .setRedirectStrategy(new LaxRedirectStrategy())
                .build();