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
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.
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 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.
How HTTP request works:(if i have mistake, please write)
user type in browser http://www.website.com
the server send him html page with links to images+css+js files
browser read html and where included images/css/js file send http request to get the file
where browser send request to get file, does he waiting for response or he send request for next file?
Thanks
Most browsers will have an internal queue of requests which are handled as follows:
Request the first item. If a fresh copy is in the cache, this will mean a request to the cache. If a stale copy with validation information (last-mod and/or e-tag) this will be a conditional request (the server or proxy may return a 304 indicating the stale copy is actually still fresh). Otherwise an unconditional request.
As rendering of the entity returned requires other entities, these will be put into a queue of needed requests.
Requests in the queue that have already been in that same queue (e.g. if a page uses the same image more than once) will have the same entity immediately used (hence if a URI returns a random image, but you use it more than once in the same page, you will get the same image used).
Requests will be processed immediately, so in the case of a webserver, images, css, etc. will begin downloading before the HTML has finished rendering or indeed, finished downloading.
Requests to the same domain with the same protocol (HTTP or HTTPS) will be pipelined, using a connection that has already been used, rather than opening a new one.
Requests are throttled in two ways: A maximum number of simultaneous requests to the same domain, and a total maximum number of simultaneous requests.
The browser usually initiate more than one socket to the target server, and thus getting content on more than one socket at the same time. This can be combined with HTTP Pipelining (what you are asking about), where the browser sends multiple requests on the same socket without waiting for each of their responses.
From Wikipedia page:
HTTP pipelining is a technique in
which multiple HTTP requests are
written out to a single socket without
waiting for the corresponding
responses. Pipelining is only
supported in HTTP/1.1, not in 1.0.
Suppose I click on a link to website A on a page and just before the current page gets replaced, I click on a different link to a different website say B.
What happens to the request that was sent to website A? Does the webserver of site A reply back and the browser just rejects the HTTP reply?
There is no specific HTTP provision for canceling a request. I would expect this to happen at the socket level.
I would expect the associated TCP socket to be closed immediately upon canceling the request. Since http uses only 1 socket, the server will get the close after the request. If the close was processed before the data is generated, generated data down won't be sent to the client. Otherwise the data is sent to the client and ignored since the socket is closed. There may be wasted work, but a special http message to "cancel" would have the same effect.