The RESET means that the client and the server disagree on the state of the TCP connection that they set up. It usually means "you sent me a packet that claimed to be part of some connection but as far as I, the server, am concerned, that connection doesn't exist". The next step for me would be to look at the packets that lead up to the RESET to better characterize the disagreement. Perhaps it is actually the proxy that is messing things up.

A 60-second time-out is often an indication that a packet has been dropped. But that only makes sense if a packet was dropped in a way that would cause the client to try to send a packet. Or perhaps you have TCP keep-alives enabled?

To some extend, it should not be possible or at least not easy for the client software to cause a violation in the TCP protocol that would lead to a RESET. The closest scenario I was able to come up with for that would be the service sending the response and then closing the connection followed by the client, upon receiving the response (and perhaps even receiving the EOF in the server-to-client direction), trying to send something to the service. But that wouldn't explain the 60-second time-out before the RESET was received.

But you add a proxy into the mix and it might be:

  1. Service sends response and closes the socket
  2. Proxy receives response and forwards it to client
  3. Client receives response
  4. Client sends something more
  5. Proxy receives extra data from client and forwards to service
  6. Server OS sees data for a closed connection and sends RESET to proxy
  7. Proxy closes both sockets (one from client, one to service)
  8. Client hasn't heard a response after 60s and ignores that there is an EOF from the proxy (that it probably already read)
  9. Client re-sends
  10. Proxy OS sends a RESET to the client.

That's obviously just a guess. It was the only scenario I could come up with that didn't involve some device in the mix violating the TCP protocol. (A simple dropped packet is not a protocol violation, but I couldn't come up with a scenario with a dropped packet that would cause the observed behavior and a dropped packet should not be this predictable anyway.)

- tye        

In reply to Re: SOAP::Lite client request over HTTPS hangs until connection is reset by server (dig) by tye
in thread SOAP::Lite client request over HTTPS hangs until connection is reset by server by kiteboy

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.