HTTP Post under the hood

Viewed 120

We have 2 Windows services (same machine) that communicate on top of HTTP Protocol.
On specific machine we see the HTTP POST being sent from the client (Windows service) and arrives to the server (Windows service listening to REST CALLs) - 2 times, meaning i get 2 exact HTTP Post request on the service, but we see on client it was executed only 1 time.

Before going to wireshark/analyze the HTTP protocol, I wish to understand what explain this behavior.
When going to https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3
"the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created"

I guess we should look in wireshark for 201 response? And if no response? Does the HTTP or network framework for my C# application is retrying the POST on the server side? because we dont see 2 requests sent from client code.

2 Answers

POST reply behavior

While true, more often than not the server replies with a 200-ok status code and some extra information.

Whether this is by mistake or to avoid chatty apis or some other architecture/design consideration, only the developer can tell.

So in theory you get a 201 with an identifier and then make a GET request with said identifier to retrieve details.

In practice a lot of times this does not occur. So it is not safe to assume this behavior.

Your problem

I highly doubt that there is a built in mechanism that retries post. There are plenty of reasons for that:

  1. Duplicating entries. Imagine creating a PayPal payment. If the network has an error and you just did not receive the answer, the built in mechanism will charge you twice.
  2. There are libraries that do that only when you are sure that the request is idempotent, that is the post contained some sort of identifier and the second request will fail.

First, the calls are HTTP GET (not POST).
We define the URL with hostname/FQDN, the solution to avoid duplicated calls was to work with ip address instead of hostname when sending the Rest API.

This is the long explanation of the problem, no root cause yet.
Used both Wireshark/Process Monitor to diag, not sure for the root cause.
Process Monitor: Filtering to display network calls
Wireshark: Filter to show only HTTP

The Client send a single HTTP Get request to:
/DLEManagement/API/Engine/RunLearningPeriod

The call was executed at 11:08:16.931906
We can see 2nd call at 11:08:54.511909 - We did not trigger.

HTTP Get executed from *Server.exe (in red) and the Server is at *Management.Webservice.exe (in red).

We see that a *Client.exe (Antivirus process, in blue) is sending TCPCopy packets in the window between we sent and received.

Also, we can see that the first request was made with APIPA IPv6 and the 2nd call is IPv4, We checked the network interface and it was disabled.

Wireshark screenshot:
enter image description here

Process Monitor screenshot:
enter image description here

Network configuration:
enter image description here

enter image description here

Related