Получение ответа после 2mins в HttpClient postAbs Vert.x

Question

Я слушаю Eventbus, как показано ниже, и призывающих HttpClient.postAbs() с использованием vert.x

public void start(Future<Void> fut) { 
    EventBus eb1 = MainAdminVx.serviceBack.getEventBus(); 
    eb1.consumer("local-message-receiver", message -> { 

     HttpClient client = vertx.createHttpClient(); 

     client.postAbs("http://external-server-address/test@xyz.com/activityIn?activityId=5", r -> { 
      r.bodyHandler(b -> System.out.println(b.toString() + r.statusCode()) 
        ).exceptionHandler(t -> System.err.println(t.getMessage())); 
      }) 
       .putHeader("content-length", "1000") 
       .putHeader("userId", "test@xyz.com") 
       .putHeader("Content-Type", "application/json") 
       .putHeader("Accept", "application/json") 
       .write("some text") 
       .exceptionHandler(System.err::println) 
       .end(); 


    }); 

} 

я что-нибудь не хватает? или есть другой способ сделать это ... потому что я получаю ответ после 2 минут в postAbs, и тот же запрос POST быстро работает в почтальоне.

Заранее благодарен!

Answer 1

Мы просто должны установить

setChunked (истинный)

и он работает как шарм !!!

Как я установил длину контента как «1000», поэтому сервер будет ждать, пока он не получит 1000 байтов, даже если вы ничего не отправляете и не отвечаете после. Это означает точную длину байта тела HTTP. Обычно он используется для HTTP 1.1, так что принимающая сторона знает, когда текущий ответ/запрос завершен, поэтому соединение может быть повторно использовано для другого запроса.

Так что поблочный:

фрагментированного кодирование передачи представляет собой механизм передачи данных в версии 1.1 протокола передачи гипертекста (HTTP), в котором данные передаются в серии «куски». Он использует HTTP-заголовок Transfer-Encoding вместо заголовка Content-Length, который в противном случае требовал бы более ранняя версия протокола. Поскольку заголовок Content-Length не используется, отправителю не нужно знать длину содержимого, прежде чем он начнет передавать ответ получателю. Отправители могут начать передачу динамически генерируемого контента, прежде чем знать общий размер этого содержимого.

В качестве альтернативы, длина контента может быть опущена, и может использоваться кодированное кодирование или если оба они отсутствуют, то в конце ответа соединение должно быть закрыто.

Надеюсь, это поможет вам понять концепцию Http chunk.