The trace is captured on the client side, the one with private addressing (
communication in this case is established between two ec2 instances,
situated in the same availability zone ).
I've udpated to curl 7.50.2 in the meantime and appears like this version
gives some clues:

*100 3790M 0 3790M 0 0 1397k 0 --:--:-- 0:46:18 --:--:--
1333k* *
*Failed writing body (224 != 428)*
** Failed writing data*
** Curl_http_done: called premature == 1*
*curl: (23) Failed writing body (224 != 428)*

There is enough space for further writing to drive, so for now blaming and
investigating on wsgi/apache stack (believe wsgi daemon may silently
restart due to configuration issue, and discard some memory data still
waiting to be sent).
Tested with wget already and seems to behave similar, so I think I can put
this on hold for now.

Thanks a lot for your reply, Dan!

On Wed, Jul 5, 2017 at 7:59 PM, Dan Fandrich <dan_at_coneharvesters.com> wrote:

> On Wed, Jul 05, 2017 at 05:58:15PM +0300, Catalin Stoica via curl-users
> wrote:
> > Hi! I am using curl 7.35.0 to fetch a large chunked json from a remote
> server
> > running Apache/2.4.7, using https connection.
> >
> > It seems like after few hours, the transfer just stops on the client
> (curl)
> > side and the reason within server logs appears as user aborted.
>
> Is that trace as seen from the server side or the client side? Could it be
> a
> transparent proxy or NAT gateway that's actually sending that?
> -----------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
> Etiquette: https://curl.haxx.se/mail/etiquette.html
>

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-07-05