Hello Oleg, I have activated trace logs and the httpclient works just as intended.
[2012-08-25 07:15:16,656 org.apache.http.headers] DEBUG >> Expect: 100-continue [2012-08-25 07:15:16,662 org.apache.http.wire] DEBUG << "HTTP/1.1 100 Continue[\r][\n]" [2012-08-25 07:15:16,666 org.apache.http.wire] DEBUG << "[\r][\n]" [2012-08-25 07:15:16,667 org.apache.http.impl.conn.DefaultClientConnection] DEBUG Receiving response: HTTP/1.1 100 Continue And on the server side: 2012-08-25 07:15:16:662 ; Receiving request 2012-08-25 07:15:16:703 ; Responding with error code So it's not an httpclient related issue but a problem from my tomcat that immediately responds with a HTTP/1.1 100 Continue even before calling my servlet to handle the request. Now I know what to fix ;-) Thanks again for your help! David Le 24 août 2012 à 23:42, Oleg Kalnichevski a écrit : > On Fri, 2012-08-24 at 21:22 +0200, David Mencarelli wrote: >> Hello Oleg, >> >> Thank you for your answer it indeeds seems to be exactly what I am looking >> for. >> >> Nevertheless I have tried to use it by adding the following line of code >> before calling execute: >> ((HttpPut)httpRequest).getParams().setBooleanParameter(CoreProtocolPNames.USE_EXPECT_CONTINUE,Boolean.TRUE); >> >> And on the server-side I indeed find the following header: >> expect: 100-continue >> >> Problem is that it seems to have no effect :( >> >> If I have correctly understood how it should work the following should >> happen: >> 1) Client send request with expect: 100-continue , only headers are >> send not the content >> 2) Server responds to the request with either: >> - an error code -> in this case client doesn't send anything >> else >> - an ok code -> in this case client calls again with the full >> body >> >> Is it normal ? >> > > Yes, it is. This should be the spec compliant behavior. > > Oleg > >> Thanks >> David >> >> >> Le 24 août 2012 à 17:58, Oleg Kalnichevski a écrit : >> >>> On Fri, 2012-08-24 at 16:02 +0200, David Mencarelli wrote: >>>> Hello, >>>> >>>> I'm using httpclient-4 (more precisely 4.1.2) to send the content of a >>>> stream (a huge file in this case) to my Tomcat's upload servlet using the >>>> following code: >>>> >>>> HttpRequest httpRequest = new HttpPut(destination); >>>> InputStreamEntity entity = new InputStreamEntity(inputStream, >>>> contentLength); >>>> ((HttpPut)httpRequest).setEntity(entity); >>>> httpClient.execute(httpRequest,handler); >>>> >>>> It worked fine. >>>> >>>> I later added an authentication mechanism to prevent unauthorized user to >>>> upload files. If someone tries to upload without being authenticated the >>>> servlet directly responds with an HttpServletResponse.SC_FORBIDDEN without >>>> even processing the request's InputStream. >>>> >>>> The problem I am facing is that despite the fact that the request is >>>> rejected on the server side, my client keeps sending the whole content of >>>> the InputStream resulting in a waste of network resources. >>>> >>>> Here is a sample trace of execution: >>>> 12:00:32,813 -> call to execute >>>> 12:00:32:936 -> server sends an SC_FORBIDDEN error >>>> 12:00:44:883 -> response handler execute (and I detect the SC_FORBIDDEN >>>> status) >>>> Network activity shows that the whole content of the file has been sent on >>>> the line. >>>> >>>> I have tried several server sides trick like reading one byte of the input >>>> stream then closing it but nothing worked. >>>> >>>> Is there a way to tell the httpclient to stop streaming the content of the >>>> file when the response is forbidden (or any other status different of 200) >>>> ? >>>> >>>> Any insights will be appreciated. >>>> >>>> Thanks! >>>> >>>> Regards, >>>> David >>>> >>> >>> David >>> >>> The 'expect: continue' handshake is your friend. This is precisely what >>> it is intended for: to ensure requests meets the server expectations. It >>> is disabled per default. Try turning it on. >>> >>> Oleg >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
