I am trying to make Http connections made by C# HttpClient helper class reusable. I read that there is KeepAlive header which has to be present in Http request.
I sniffed the traffic and I cant find any reference to KeepAlive.
It has GET and it has HTTP/1.1 strings in there. No KeepAlive no nothing.
P.S. I also tried to find KeepAlive property somewhere on HttpClient but couldnt...
Any ideas?
It should have a Connection header, which looks like this:
Connection: Close
Connection: Keep-Alive
The keep-alive header looks like this:
Keep-Alive: 115
Related
What is a good tactic to implement mechanism on server to read data from external device by http with keep-alive connection ?
Details.
I have camera device hosted on public address. i can use request to create connection beetween server and device ( get events in live ).
Sample request
GET /live/events HTTP/1.1
Host: x.x.x.x
Connection: keep-alive
Cookie: sid=id
and now i should get response if camera detect something.
I dont sure how i should do this. HttpClient will be enough to resolve my problem , or maybe something else ?
Regards
I'm aware that HttpWebRequest has a parameter available to set URL redirection to false (request.AllowAutoRedirect = False;).
How is this done when using a Socket connection directly?
I don't have any code to show since I'm just starting down the road of development on a project.
Unfortunately, I need to stick to using Socket connections and cannot use HttpWebRequest, WebClient or HTTPClient. :(
There is no such thing as a socket redirection.
An HTTP redirection is where you connect to the server specified, send your HTTP request, and server sends a HTTP response which tells you to go to a different URL instead. So then you go that URL instead.
It looks like this:
*** socket opened to example.com
*** client sends this part:
GET /some/address HTTP/1.1
Host: example.com
*** server sends this part:
HTTP/1.1 302 Found
Location: https://other.example.com/some_place?really=yes
*** socket closed to example.com
if you have auto-redirect disabled, this is the response your program gets. Otherwise, the HTTP library keeps going:
*** socket opened to other.example.com
*** client sends this part:
GET /some_place?really=yes HTTP/1.1
Host: other.example.com
*** server sends this part:
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 11
hello world
*** socket closed to other.example.com
If you are just using sockets you will be doing this yourself to begin with.
I iam working on a tool that let users check their API. One of the features is to show the actual send request headers.
Iam having trouble getting these headers though as the Headers property doesnt seem to include them all. I tried looking at tracelisteners but these seem to be more oriented to debugging and the config is global so it applies to all webrequests send by the app which is not what I want.
When I run this code on net48 (in core I seem to get 0 headers back):
// Create a new 'HttpWebRequest' Object to the mentioned URL.
HttpWebRequest myHttpWebRequest=(HttpWebRequest)WebRequest.Create("http://www.contoso.com");
// Assign the response object of 'HttpWebRequest' to a 'HttpWebResponse' variable.
HttpWebResponse myHttpWebResponse=(HttpWebResponse)myHttpWebRequest.GetResponse();
Console.WriteLine("\nThe HttpHeaders are \n\n\tName\t\tValue\n{0}",myHttpWebRequest.Headers);
I get the following output
The HttpHeaders are
Name Value
Host: www.microsoft.com
However in fiddler and with trace listeners I see these headers:
Host: www.contoso.com
Connection: Keep-Alive
Why can't I see the Connection header?
Now I see there is some redirecting going on. WebRequest seems to only show the headers send in the LAST request which didn't had the Connection header.
I am using HttpClient to make a post request. I get back 405 method not allowed. When capturing a trace in fiddler, it goes out as GET instead of POST!
using (var client = new HttpClient())
{
var url = AppSettingsUtil.GetString("url");
var response = client.PostAsJsonAsync(url, transaction).Result;
}
I am aware of the async/await issues. This is a simplified sample to show the issue.
Is there some sort of web.config or machine.config setting that could be affecting this? Other requests (sent through RestSharp) send Posts correctly
Here is what fiddler captures. Rerunning the trace in fiddler also returns the 405 (as expected). Manually switching it to POST and running works from fiddler.
Also, perhaps because the method was switched to GET, there is no body captured in fiddler, I had to manually paste in the JSON
GET /*URL*/ HTTP/1.1
Content-Type: application/json; charset=utf-8
Host: /*host*/
Connection: Keep-Alive
The problem appears to be that someone changed the URL without telling us, and they put a redirect in place. HttpClient is responding to the redirect, but ends up actually sending the request to the final destination as a Get.
This seems like a bug in HttpClient to me, that it should either send the ultimate request as a Post, or throw an exception saying it can't do what I asked it to.
See Forwarding a response from another server using JAX-RS
I'm using the HttpClient class to communicate to a web service in my WPF application.
When I make consecutive GET requests on the same connection, everything works fine. However, when I make consecutive PUT/PATCH requests on the same connection, the first request executes accurately and I receive a response but the second request does not include the body in the request and I receive the infamous error of "The server committed a protocol violation. Section=ResponseStatusLine".
My requests do complete successfully if I manually close the connection after every request by adding Connection: close to the header. This "solution" is a bad pattern and performance will not scale appropriately.
Below is a debranded version of a list of my TCP Stream Output from the requests being sent:
Wireshark: Follow TCP Stream Output
GET /domain/api/tenant/current/object?objectName=Lizbot HTTP/1.1
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 50
{"Data":[{"Id":123,"ObjectName":"Lizbot","Date":null}],"Errors":[]}
PATCH /domain/api/tenant/current/object/123 HTTP/1.1
Accept: application/json
Content-Type: application/json; charset=utf-8
Content-Length: 50
{"Id":123,"ObjectName":"Lizbot","Date":null}
HTTP/1.1 204 No Content
Content-Type: application/json; charset=utf-8
{"Data":null,"Errors":[]}
PATCH /domain/api/tenant/current/object/123/otherObject HTTP/1.1
Accept: application/json
Content-Type: application/json; charset=utf-8
HTTP/1.1 400 Bad Request</b>
Content-Type: text/html; charset=us-ascii
Connection: close
Content-Length: 311
Notice that the second PATCH is missing the object it's supposed to patch with. If I change the order of the PATCHing, the second PATCH is still missing its object.
This error appears to be common with a few known solutions which I have tried. They consist of this solution which involves setting the useUnsafeHeaderParsing property to TRUE and setting the Keep-Alive property to FALSE in the Web.Config. I also tried the solution of setting these properties in this manner shown below:
ServicePointManager.DefaultConnectionLimit = 2;
ServicePointManager.Expect100Continue = false;
None of these solutions worked. It should be noted that when using the Http Debugging proxy tool, Fiddler, to capture these requests, I don't receive any errors.
So what I am asking for is if anyone knows a good solution to alleviate this error so I can make multiple requests in a connection without losing the body of an update. If more details are needed, I am happy to supply them.
After much debugging and reading, I realized I was trying to edit the Web.Config file of the WPF application instead of the app.config file!
So if you drop this code in the app.config file at the root of the configuration tag for a WPF application, it fixes the problem.
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing = "true"/>
</settings>
</system.net>
The underlying problem is that the PATCH response includes content within the body of the response. Ensure that the server does not send content when sending a 204 No Content.