hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Motes <davidmo...@gmail.com>
Subject Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?
Date Fri, 19 Aug 2016 16:12:41 GMT
You are dealing with 2 different HTTP client implementations, the browser
and the Java HTTP client.

>The section for 201 says it should be returned when "The request has been
fulfilled"

 Sending a 201 back says the request has been fulfilled, there is nothing
more to do.
If you have fulfilled the request then what data are you sending in the
post?  It is obviously not needed if you can fulfill the request without it.

 I have not looked at the code but I would imagine when the Java client
gets the 201 response it thinks the request processing is complete so why
should I continue to send data. I will just FIN the connection and get out.

 The browser code just works differently.

This is not a problem with the Java client.

On Fri, Aug 19, 2016 at 11:42 AM, Sachin Nikumbh <sanikumbh@gmail.com>
wrote:

> Hi David and Stefan,
>
> Thanks for your responses. When the client sends the POST request, we are
> sending the Content-Length to the correct value. Since the client is using
> a duplex channel to write/read data, why would the server sending 201 cause
> any issues with client writing all the data? Shouldn't the client make sure
> that it is writing all the data corresponding to Content-Length? Is the
> async client aborting request explicitly?
>
> I would like to add that the same server can successfully talk to a browser
> without any issues with similar request payload. We also made sure that we
> were successful in communicating with the server using a python client
> applications.
>
> We have verified using wireshark that when browser (javascript) or python
> sends the request, we receive the 201 while client is still in the middle
> of sending the request payload. After receiving 201, thew browser and
> python still continue with sending the data and successfully send all the
> data.
>
> I looked at the RFC : https://www.ietf.org/rfc/rfc2616.txt. The section
> for
> 201 says it should be returned when "The request has been fulfilled" and we
> have fulfilled the request by creating our resource and by sending the
> resource uri as part of Location header.
>
>
> Thanks once again,
> Sachin
>
>
>
>
> On Fri, Aug 19, 2016 at 11:01 AM, David Motes <davidmotes@gmail.com>
> wrote:
>
> >  The response code should be sent back after the entire request has been
> > processed. You cannot send a 201 created back after the headers and then
> > discover something is wrong with the body and change the response code to
> > some kind of error, it is too late.
> >
> >  Your server needs to be changed to send that response code upon
> completion
> > of the request.
> >
> > On Fri, Aug 19, 2016 at 10:47 AM, Sachin Nikumbh <sanikumbh@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I realized that in my previous post, I did not do a good job of
> > explaining
> > > the problem that I am facing. My sincere apologies for that.
> > >
> > > We have a custom server that my client Java application is
> communicating
> > > with using the async client. To be specific we are using an instance of
> > > CloseableHttpAsyncClient from the client application. The client sends
> a
> > > POST request with few kilo bytes of data. The server reads the headers,
> > > sends a 201 back to the client acknowledging the receipt of request and
> > > continues reading with the request body. What I see using wireshark on
> > the
> > > client side is that the client receives 201 when it is still in the
> > middle
> > > of sending the data. But then the client sends a FIN even before it has
> > > sent all the data. This results in server not receiving all the data.
> > >
> > > Now, if we remove the server 201 response, everything works fine. I.e
> > > client sends all the data to the server. We also don't see this
> behavior
> > if
> > > the client sends small amount of data < 3 kb.
> > >
> > > Is this a known issue? Are there any client side hooks that I can use
> to
> > > fix/debug this issue?
> > >
> > > Any help would be greatly appreciated.
> > >
> > > Thanks
> > > Sachin
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message