2016-12-12 11 views
0

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

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

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

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

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

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

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

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); 

запись в журнале A 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 header нет:

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  = "[email protected]"; 

     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
  • Arch: x86_64
  • Java: 1.7.0_80
  • CXF: 3,1 .8

ответ

0

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

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