Клиент CXF JAX-RS всегда отправляет пустые запросы PUT в режиме чанкинга относительно настройки AllowChunking

Question

Мы выполняем PUT-запрос к нашей стороне, используя клиент CXF JAX-RS. Тело запроса пусто. Простой вызов запроса приводит к ответу сервера с кодом 411.

Response-Code: 411  
"Content-Length is missing"

REST-серверу нашей стороны требуется установить HTTP-заголовок Content-Length.

Мы отключили блокировку в соответствии с примечанием о блокировании, но это не решило проблему. REST-сервер все еще отвечает с ошибкой 411.

Вот наша конфигурация канала из файла cxf.xml

    <http-conf:conduit name="{http://myhost.com/ChangePassword}WebClient.http-conduit">
        <http-conf:client AllowChunking="false"/>
    </http-conf:conduit>

Строка в журнале подтверждает, что выполнение нашего запроса привязано к нашей конфигурации канала:

DEBUG o.a.cxf.transport.http.HTTPConduit - Conduit '{http://myhost.com/ChangePassword}WebClient.http-conduit' has been configured for plain http.

Добавление заголовка Content-Length явно также не помогло.

    Invocation.Builder builder = ...  
    builder = builder.header(HttpHeaders.CONTENT_LENGTH, 0);

Запись в журнале клиента CXF подтверждает настройку заголовка, однако когда мы перехватывали пакеты, мы неожиданно обнаружили, что настройка заголовка полностью игнорируется клиентом CXF. Заголовок Content-Length не был отправлен.

Вот журнал. Заголовок Content-Length присутствует:

INFO  o.a.c.i.LoggingOutInterceptor - Outbound Message
---------------------------
ID: 1
Address: http://myhost.com/ChangePassword?username=abc%40gmail.com&oldPassword=qwerty123&newPassword=321ytrewq
Http-Method: PUT
Content-Type: application/x-www-form-urlencoded
Headers: {Accept=[application/json], client_id=[abcdefg1234567890abcdefg12345678], Content-Length=[0], Content-Type=[application/x-www-form-urlencoded], Cache-Control=[no-cache], Connection=[Keep-Alive]}
--------------------------------------
DEBUG o.apache.cxf.transport.http.Headers - Accept: application/json
DEBUG o.apache.cxf.transport.http.Headers - client_id: abcdefg1234567890abcdefg12345678
DEBUG o.apache.cxf.transport.http.Headers - Content-Length: 0
DEBUG o.apache.cxf.transport.http.Headers - Content-Type: application/x-www-form-urlencoded
DEBUG o.apache.cxf.transport.http.Headers - Cache-Control: no-cache
DEBUG o.apache.cxf.transport.http.Headers - Connection: Keep-Alive

А вот и вывод анализатора пакетов. Заголовок Content-Length отсутствует:

PUT http://myhost.com/ChangePassword?username=abc%40gmail.com&oldPassword=qwerty123&newPassword=321ytrewq HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/json
client_id: abcdefg1234567890abcdefg12345678
Cache-Control: no-cache
User-Agent: Apache-CXF/3.1.8
Pragma: no-cache
Host: myhost.com
Proxy-Connection: keep-alive

Кто-нибудь знает, как на самом деле отключить чанкинг?

Вот наш код:

    public static void main(String[] args)  
    {  
        String clientId   = "abcdefg1234567890abcdefg12345678";  
        String uri        = "http://myhost.com";  
        String user       = "[e-mail]";  

        Client client = ClientBuilder.newBuilder().newClient();  
        WebTarget target = client.target(uri);  
        target = target.path("ChangePassword").queryParam("username", user).queryParam("oldPassword", "qwerty123").queryParam("newPassword", "321ytrewq");  
        Invocation.Builder builder = target.request("application/json").header("client_id", clientId).header(HttpHeaders.CONTENT_LENGTH, 0);  
        Response response = builder.put(Entity.form(new Form()));  
        String body = response.readEntity(String.class);  
        System.out.println(body);  
    }

Версии:

• ОС: Windows 7 Enterprise SP1
• Арка: x86_64
• Java: 1.7.0_80
• CXF: 3.1.8

Answer 1

У меня была очень похожая проблема, которую я не смог решить, как вы, пытаясь отключить порцию.

В итоге я установил для Content-Length значение 1 и добавил пробел " " в качестве тела. Мне показалось, что прокси-серверы до того, как серверное приложение отклонило запрос, и благодаря этому я смог пройти мимо прокси-серверов, и сервер смог обработать запрос, поскольку он работал только на основе URL-адреса.