Databases
StackOverflow2013
Postsdbo
POServer always sends RST to some destinations and proper responses to others
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POServer always sends RST to some destinations and proper responses to others
    primarykey
    data
    text
    <p>We have a server which servers our API.</p> <p>I'm using it for a while now and nowadays I'm experiencing what I'm calling now a sort of <strong><em>server prejudice</em> from our API server to some destinations</strong> (being nice to some senders and bad to others) and I'd like to know exactly what's going on.</p> <p>Some <strong>requests are being responded with a TCP reset</strong> (RST), but others <strong>do get to be responded properly</strong> (200 status, expected content).</p> <p>I want to clarify that this is not explicitly done in the server (we are not actually picking some destinations to reject) and that, for each client I've tried, I always get the same result (I mean, the behavior is deterministic, depending only on the sender - at least apparently).</p> <p>This is the actual request I'm sending:</p> <pre><code>GET /api/guilherme@buddycloud.org/metadata/posts HTTP/1.1 Host: demo.buddycloud.org </code></pre> <p>This is the python code I wrote and that I'm running at different places:</p> <pre><code>from requests import Request, Session headers = { 'Accept' : '*/*', 'Accept-Encoding' : 'gzip,deflate,sdch', 'Accept-Language' : 'en-US,en;q=0.8,pt-BR;q=0.6,pt;q=0.4', 'Cache-Control' : 'no-cache', 'Host' : 'demo.buddycloud.org' } req = Request('GET', 'https://demo.buddycloud.org/api/guilherme@buddycloud.org/metadata/posts', headers=headers) r = req.prepare() print r.url s = Session() resp = s.send(r, verify=False) print resp, resp.ok print resp.content </code></pre> <p>Couple different scenarios I've tried:</p> <p><strong>Windows 7 64 bits, Python 2.7.3, Requests 1.2.3</strong></p> <p>Ran this code and this exception was raised:</p> <pre><code>requests.exceptions.ConnectionError: HTTPSConnectionPool(host='demo.buddycloud.org', port=443): Max retries exceeded with url: /api/guilherme@buddycloud.org/metadata/posts (Caused by &lt;class 'socket.error'&gt;: [Errno 10054] An existing connection was forcibly closed by the remote host) </code></pre> <p>Using Wireshark I noticed this is happening because I get a TCP reset from the server. <img src="https://i.stack.imgur.com/ii9K1.png" alt="Wireshark output image"></p> <p><strong>Ubuntu, Python 2.7.3, Request 1.2.3</strong></p> <p>I ran the exact same code and got no problems, but the expected response:</p> <pre><code>https://demo.buddycloud.org/api/guilherme@buddycloud.org/metadata/posts &lt;Response [200]&gt; True { "title" : "guilherme@buddycloud.org Channel Posts", "description":"This is my buddycloud channel =)", "access_model":"open", "creation_date":"2013-04-13T15:24:53.471Z", "channel_type":"personal", "default_affiliation":"publisher" } </code></pre> <p>At this point in the reading, one could guess it is a Windows x Linux problem, but you will see that one of the scenarios is a Linux enviroment but I still got the same problem.</p> <p><strong>Through Postman</strong></p> <p>It works just fine, as one might expect. <img src="https://i.stack.imgur.com/oInV6.png" alt="Postman printscreen"></p> <p><strong>At our Heroku server, Python 2.7.4, Requests 1.2.3</strong></p> <p>We have an app that issues the same call to our API. A pretty similar error happens there and I'm sure the reason is the same (server sending TCP resets). This is the exception raised:</p> <pre><code>HTTPSConnectionPool(host='demo.buddycloud.org', port=443): Max retries exceeded with url: /api/guilherme@buddycloud.org/metadata/posts (Caused by : [Errno 104] Connection reset by peer) </code></pre> <p>So I'm dying to know why is our server behaving like this. I spent a lot of time thinking that the problem was on my end but I'm guessing it isn't and that it is being caused by something at the server, maybe some misconfiguration or something SSL-related.</p> <p>Note that the headers my code is sending through <em>python-requests</em> are the same that Postman sends - I'm actually trying to mock Postman's successful request, but that won't work.</p> <p>Also please note that I have Python and Requests in the exact same versions everywhere I tried executing this.</p> <p>Can somebody help me know what's going on? Thanks in advance and I'm open to any further questions you might have.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USrhashimoto
    1. USGuilherme Santos
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POServer always sends RST to some destinations and proper responses to others
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POServer always sends RST to some destinations and proper responses to others
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POServer always sends RST to some destinations and proper responses to others
      1. USGuilherme Santos
      1. VTFavorite
    1. COI assume you've looked for info in the server logs? Also, perhaps you should compare the SSL ClientHello details between working and non-working packet captures.
      singulars
      1. POServer always sends RST to some destinations and proper responses to others
      1. USrhashimoto
    2. COIt would be helpful to see the headers from the successful Requests request and from the unsuccessful one. [mitmproxy](http://mitmproxy.org/) can probably help you get them if you're strugging with the HTTPS.
      singulars
      1. POServer always sends RST to some destinations and proper responses to others
      1. USLukasa
    3. CO@Lukasa It does not appear to be an issue with HTTP headers. The packet capture shows that the connection is dropped in the SSL handshake, before HTTP headers are sent. Using a proxy will alter the behavior (i.e. it may work when the real client doesn't and vice versa) as the proxy will be performing the client side of the handshake.
      singulars
      1. POServer always sends RST to some destinations and proper responses to others
      1. USrhashimoto
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload