I am able to consistently reproduce this problem where I request a URL from my server and I get back a 200 code but the response headers and response body are empty. If I monitor incoming traffic on my web server I never see the request come in. My web server sits behind a proxy server, if I monitor traffic there, I also do not see the request come in.
Any ideas as to where this empty response might be coming from, or tips as to what situations can result in an empty response like this?
This turned out to be a GET request size limit on our internal firewall proxy server. We were able to reduce the size at which we switch from a GET to a POST request in our code to avoid the limit.
Related
I have a working console app, which sends data to an API. However as soon as I launch fiddler, I get the message:
[Fiddler] ReadResponse() failed: The server did not return a complete response for this request. Server returned 257 bytes.
The first header shown in Fiddler is: HTTP/1.1 504 Fiddler - Receive Failure
which seems to be generated directly by fiddler rather than having come from my API server (.NET).
How can I debug why this is happening, given that fiddler will not show me the raw results from the server? I presume there is an HTTP header error of some sort, which is compatible with my console app but not compatible with Fiddler.
I have been playing with gzip compressed requests, so perhaps one of the headers is incorrect (Content-Length), but with no way to view the raw response, it's very hard to debug this problem.
In the end I got some help from #ErikLaw on this:
Download DebugView https://learn.microsoft.com/en-us/sysinternals/downloads/debugview
In Fiddler's black QuickExec box under the session list, type !spew and hit Enter. Fiddler will begin spewing verbose logging information to DebugView, including all reads and writes to/from the network.
Far more information about the failed request is then shown in DebugView, which led me to the root cause that my web server was closing the connection early, before sending all content.
All credit to Eric.
How can I debug why this is happening, given that fiddler will not show me the raw results from the server?
Use Wireshark to see the actual network traffic. Fiddler's good (it's great), but it's not Wireshark. You'll need to jump through some hoops if your traffic is HTTPS, though.
Wireshark is not as easy to use as Fiddler, but it is significantly more powerful.
Also, if you're on Windows, you need to use your machine's local network IP address (e.g. 192.168.x.y), rather than localhost. See this question.
I have an internal component passing request to Nginx. Logs on my internal component show 96500 ms as response times. But the same request shows 0.010 ms in Nginx. I did check the network connection between the components but all look ok. Is there any way to know the time request reached Nginx? I guess the request reached time might be different. Can someone put some light into this? Let me know if anyone needs any config for the same?
Make sure your client and server are synced using a NTP server. You can then add a request time to the url before making the request
http://example.com/url/?start_time=xxxxxx
Then on server logs you can log time taken using $request_time and also add the time to response using add headers
add_header X-Request-Time $time_iso8601;
On the client side you can then log when you get the response. So you will almost have all the time points with you.
start_time on client when you sent the request
X-Request-Time in response header for when request reached nginx
$request_time in nginx log telling you when it started responding to the request
end_time on client when you received the response
Just a quick question, and probably a stupid one.
But usually when a client connects to an http server, the server sends them the header and the html, correct?
I'm packet sniffing a realtime-chat, and attempting to reverse engineer a plain text protocol, and it's connected to a http server. This is why I ask, for verification.
Basically, this is correct. Anyways, you have to differentiate between for example GET and POST Requests.
While POST Requests normally have a "real" body with information that they are delivering to the Server, the body of GET Requests is empty for most of the time.
For the responses, your Claim is correct. The Header is sent to tell how big the response is, which MIME Type is used, etc.
I'm working on a custom webserver and I was wondering if it's possible to send a http response before the browser starts sending the body? Very important, I'd like to keep the connection open and if anybody's interested, the http response I'd like to send is a 509 (Bandwidth Limit Exceeded).
For now, it seems what I've been able to do is to prevent the server from downloading the body and it's trying to send the response back but the browser (Chrome) hangs at 'Uploading (0%)...'.
Thanks in advance
I'm trying to diagnose a web service that sits behind some load balancers and proxies. Under load, one of the servers along the way starts to return HTTP 504 errors, which indicates a gateway timeout. With that background out of the way, here is my question:
When a proxy makes a request to the destination server, and the destination server receives the request but doesn't respond in time (thus exceeding the timeout), resulting in a 504, what happens when the destination server does eventually respond? Does it know somehow that the requestor is no longer interested in a response? Does it happily send a response with no idea that the gateway already sent HTTP error response back to the client? Any insight would be much appreciated.
It's implementation-dependent, but any proxy that conforms to RFC 2616 section 8.1.2.1 should include Connection: close on the 504 and close the connection back to the client so it can no longer be associated with anything coming back from the defunct server connection, which should also be closed. Under load there is the potential for race conditions in this scenario so you could be looking at a bug in your proxy.
If the client then wants to make further requests it'll create a new connection to the proxy which will result in a new connection to the backend.