How to work with HttpPut?

[Schurr, Bastian]

Hi,
I have to upload files - text files as well as binary files - to a server using 
http put method. I get the URL from the server and upload my sample files to 
the server without any failure.
But when I open the uploaded files on the server I find modifications in the 
files like follows (original content in green):

--file: 
Walze.txt---
--359OQxCzKReuMiQUCDjZkKneprgsPnZApeFpvoPF
Content-Disposition: form-data; name="Walze.txt"; filename="Walze.txt"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

line 1: content
line 2: content
--359OQxCzKReuMiQUCDjZkKneprgsPnZApeFpvoPF--
--file: 
Walze.txt---

Here is my code:

public List put(File fIn, String sUrl) throws IllegalArgumentException, 
ClientProtocolException, IOException {
if (fIn != null && sUrl != null && !sUrl.isEmpty()) {

   CloseableHttpClient client = 
HttpClients.createDefault();
   try {
   HttpPut request = new 
HttpPut(sUrl);

   FileBody file = new 
FileBody(fIn);

   HttpEntity reqEntity = 
MultipartEntityBuilder.create().addPart(fIn.getName(), file).build();
   request.setEntity(reqEntity);

   CloseableHttpResponse response = 
client.execute(request);

   List vLines = 
this.readResponse(response);

   this.handleResponse(response);

   return vLines;
   } finally {
   try {
   client.close();
   } catch (IOException eIgnore) {
   }
   }
}
}

private List readResponse(CloseableHttpResponse response) throws 
IOException {
List vLines = new ArrayList();

HttpEntity resEntity = response.getEntity();
if (resEntity != null) {
   BufferedReader reader = new BufferedReader(new 
InputStreamReader(resEntity.getContent()));

   String s;
   while (null != (s = reader.readLine())) {
   if (!s.isEmpty()) {
   vLines.add(s);
   }
   }
}
return vLines;
}

private void handleResponse(CloseableHttpResponse response) throws IOException {
Logger.getLogger(this.getClass()).debug("Response status line 
[" + response.getStatusLine() + "]");
Logger.getLogger(this.getClass()).debug("Response status code 
[" + response.getStatusLine().getStatusCode() + "]");
Logger.getLogger(this.getClass()).debug("Response status phrase 
[" + response.getStatusLine().getReasonPhrase() + "]");

Header[] vHeaders = response.getAllHeaders();
for (Header header : vHeaders) {
   String sName = header.getName();
   String sValue = header.getValue();
   
Logger.getLogger(this.getClass()).debug("Response header " + sName + " [" + 
sValue + "]");
}

HttpEntity resEntity = response.getEntity();
if (resEntity != null) {
   
Logger.getLogger(this.getClass()).debug("Response content type [" + 
resEntity.getContentType() + "]");
   
Logger.getLogger(this.getClass()).debug("Response content length [" + 
resEntity.getContentLength() + "]");

   EntityUtils.consume(resEntity);
}

try {
   response.close();
} catch (IOException eIgnore) {
}
}


Can anyone please tell me what is missing in my code or what can be the failure?

Thanks and Regards

Bastian


CENIT AG, Industriestrasse 52-54, 70565 Stuttgart, Tel.: +49 711 7825-30, Fax: 
+49 711 7825-4000, Internet: www.cenit.com
Geschaeftsstellen: Berlin, Frankfurt, Hamburg, Hannover, Muenchen, Oelsnitz, 
Ratingen, Saarbruecken
Vorstandsmitglieder: Kurt Bengel, Matthias Schmidt
Aufsichtsratsmitglieder: Andreas Schmidt (Vorsitzender des Aufsichtsrats), 
Hubert Leypoldt, Andreas Karrer
Bankverbindungen:
Deutsche Bank (BLZ 600 700 70) Kto. 1661 040 IBAN : 

wire/header logs on log4j2?

[Marc Boorshtein]

I have http-client 4.5.2 and core 4.4.4 running on log4j2 with the
compatibility jars in place for 1.2.  I can't seem to get wire or debug
logs working.  Here's my log4j2.xml:



  

  

  
  


  


  

  


I don't get any output from htto client.  Am I missing something?

Thanks
Marc

[ANNOUNCEMENT] HttpComponents Client 4.5.3 GA Released

[Oleg Kalnichevski]

The Apache HttpComponents project is pleased to announce 4.5.2 GA
release of HttpComponents HttpClient.

HttpClient 4.5.3 is a maintenance release that fixes a number of minor
bugs reported since 4.5.2.

Download - 
Release notes -

HttpComponents site - 

About HttpComponents HttpClient

The Hyper-Text Transfer Protocol (HTTP) is perhaps the most significant
protocol used on the Internet today. Web services, network-enabled
appliances and the growth of network computing continue to expand the
role of the HTTP protocol beyond user-driven web browsers, while
increasing the number of applications that require HTTP support.

Although the java.net package provides basic functionality for
accessing resources via HTTP, it doesn't provide the full flexibility
or functionality needed by many applications. HttpClient seeks to fill
this void by providing an efficient, up-to-date, and feature-rich
package implementing the client side of the most recent HTTP standards
and recommendations.

Designed for extension while providing robust support for the base HTTP
protocol, HttpClient may be of interest to anyone building HTTP-aware
client applications such as web browsers, web service clients, or
systems that leverage or extend the HTTP protocol for distributed
communication.


-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: Support HTTP/2 protocol

[Oleg Kalnichevski]

On Thu, 2017-01-26 at 14:32 +0100, Philippe Mouawad wrote:
> Hello ,
> Oleg kindly proposed to help JMeter project in adding HTTP/2 support.
> 
> We have started this thread to work on design.
> 
> As per Andrei remark, it seems ALPN is not yet supported by current
> HTTPClient 5.x version.
> Is there some visibility on its support ?
> 


ALPN will be supported as soon as it is supported by the Java platform
(which is not going to happen until Java 9). 

ALPN can be used to advertise server protocol capabilities at the time
of SSL handshake and allow clients to pick the desired protocol from
the list of supported protocols. If one knows supported protocols
beforehand ALPN is completely useless. Clients can go straight to using
HTTP/2 if the server is known to support it.

In the next release of HttpCore I would like to add protocol detection
logic to enable endpoints to detect HTTP protocol version by examining
the first packet received from the opposite endpoint. This in my
opinion would be a much more practical feature. ALPN presently is very
low on my priority list.

Having said that ALPN support contribution would be welcome if someone
is willing to develop it.

Oleg 



> Thanks for your help.
> Regards
> 
> On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilko  wrote:
> 
> > Hi,
> > 
> > From my experiments, I see that lack of two specific features make
> > it
> > not useful. According to https://hc.apache.org/news.html:
> > 
> >   * No ALPN support yet
> >   * no connection upgrade
> > 
> > Especially ALPN part is crucial for protocol functioning. Is there
> > any
> > ETA from Oleg when it will become available?
> > 
> > 
> > In general, we can start designing the "synchronous way" solution.
> > From
> > my understanding, it is doable and will be good enough for the
> > beginning.
> > 
> > 
> > Andrey Pokhilko
> > 
> > On 25.01.2017 23:38, Philippe Mouawad wrote:
> > > Hello
> > > I'd like to start a thread on this particular item for which an
> > 
> > enhancement
> > > exists:
> > > 
> > >    - https://bz.apache.org/bugzilla/show_bug.cgi?id=59847
> > > 
> > > The aim of this thread is to discuss, throw ideas on how we could
> > 
> > implement
> > > this in JMeter.
> > > 
> > > Oleg K. from HttpComponents project has nicely proposed to help
> > > on it.
> > > 
> > > I see at least 2 parts in this item:
> > > 
> > >    - The Sampler
> > >    - The Recorder
> > > 
> > > 
> > > 
> > > *Sampler:*
> > > We have 2 options:
> > > 
> > >    - build a usual "synchronous" sampler similar to HTTP:
> > >   - Is this realistic ?
> > >   - Does it perform well ?
> > >   - + : It should not be too complex
> > >    - build a new "Asynchronous sampler":
> > >   - Is this realistic ?
> > >   - + We could gain more performance
> > >   - - It is a huge piece of work as we need to change JMeter
> > > model
> > > 
> > > *Recorder:*
> > > 
> > > I think we need to introduce a new more generic Recorder as the
> > > current
> > > Test Script Recorder is too tightly linked to HTTP 1.X protocol
> > > 
> > > 
> > > Regards
> > > Philippe M.
> > > @philmdot
> > > 
> > 
> > 
> 
> 

-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org

Re: Support HTTP/2 protocol

[Philippe Mouawad]

Hello ,
Oleg kindly proposed to help JMeter project in adding HTTP/2 support.

We have started this thread to work on design.

As per Andrei remark, it seems ALPN is not yet supported by current
HTTPClient 5.x version.
Is there some visibility on its support ?

Thanks for your help.
Regards

On Thu, Jan 26, 2017 at 2:13 PM, Andrey Pokhilko  wrote:

> Hi,
>
> From my experiments, I see that lack of two specific features make it
> not useful. According to https://hc.apache.org/news.html:
>
>   * No ALPN support yet
>   * no connection upgrade
>
> Especially ALPN part is crucial for protocol functioning. Is there any
> ETA from Oleg when it will become available?
>
>
> In general, we can start designing the "synchronous way" solution. From
> my understanding, it is doable and will be good enough for the beginning.
>
>
> Andrey Pokhilko
>
> On 25.01.2017 23:38, Philippe Mouawad wrote:
> > Hello
> > I'd like to start a thread on this particular item for which an
> enhancement
> > exists:
> >
> >- https://bz.apache.org/bugzilla/show_bug.cgi?id=59847
> >
> > The aim of this thread is to discuss, throw ideas on how we could
> implement
> > this in JMeter.
> >
> > Oleg K. from HttpComponents project has nicely proposed to help on it.
> >
> > I see at least 2 parts in this item:
> >
> >- The Sampler
> >- The Recorder
> >
> >
> >
> > *Sampler:*
> > We have 2 options:
> >
> >- build a usual "synchronous" sampler similar to HTTP:
> >   - Is this realistic ?
> >   - Does it perform well ?
> >   - + : It should not be too complex
> >- build a new "Asynchronous sampler":
> >   - Is this realistic ?
> >   - + We could gain more performance
> >   - - It is a huge piece of work as we need to change JMeter model
> >
> > *Recorder:*
> >
> > I think we need to introduce a new more generic Recorder as the current
> > Test Script Recorder is too tightly linked to HTTP 1.X protocol
> >
> >
> > Regards
> > Philippe M.
> > @philmdot
> >
>
>


-- 
Cordialement.
Philippe Mouawad.