Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[Sachin Nikumbh <sa...@gmail.com>]

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

Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[Oleg Kalnichevski <ol...@apache.org>]

On Fri, 2016-08-19 at 14:28 -0400, Sachin Nikumbh wrote:
> If the client is aborting the request after it receives the 201 response,
> is there any way to overwrite this behavior from the user's point of view?
> If I were to look into the source code to see where it is done, can someone
> please point me in the right direction in the sense of which package/class
> I should be looking at?
> 

https://github.com/apache/httpcore/blob/4.4.x/httpcore-nio/src/main/java/org/apache/http/nio/protocol/HttpAsyncRequestExecutor.java#L297

Oleg

> Thanks
> Sachin
> 
> On Fri, Aug 19, 2016 at 12:12 PM, David Motes <da...@gmail.com> wrote:
> 
> > 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 <sa...@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 <da...@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 <sa...@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
> > > > >
> > > >
> > >
> >



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

Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[Sachin Nikumbh <sa...@gmail.com>]

If the client is aborting the request after it receives the 201 response,
is there any way to overwrite this behavior from the user's point of view?
If I were to look into the source code to see where it is done, can someone
please point me in the right direction in the sense of which package/class
I should be looking at?

Thanks
Sachin

On Fri, Aug 19, 2016 at 12:12 PM, David Motes <da...@gmail.com> wrote:

> 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 <sa...@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 <da...@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 <sa...@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
> > > >
> > >
> >
>

Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[David Motes <da...@gmail.com>]

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 <sa...@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 <da...@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 <sa...@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
> > >
> >
>

Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[Sachin Nikumbh <sa...@gmail.com>]

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 <da...@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 <sa...@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
> >
>

Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[David Motes <da...@gmail.com>]

 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 <sa...@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
>

Re: Can a 201 (Created) response cause HTTP async client to prematurely send a FIN to the server?

[Stefan Magnus Landrø <st...@gmail.com>]

How can you return a 201 without having read all the data from the client?  I believe you're violating the http spec

Sendt fra min iPhone

> Den 19. aug. 2016 kl. 16.47 skrev Sachin Nikumbh <sa...@gmail.com>:
> 
> 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

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