I'm sending from my server partial contents (206) with length 1mb. But video player does not make buffer this and make new request only if SHOWED this partial content. And if client has slow internet, he get delay, while new request executed. How may make buffer partial content? I would that browser make new request, when partial content full LOADED, but not SHOWED else.
A 206 can only be returned when the browser asks for a range via the Content-Range header. Then the server must fulfill the requested range exactly as requested with a 206. If the browser does not specify a Content-Range header, returning a 206 is illegal. You, as the server can not force the browser to make a range request, but you can tell it your server can accept ranges via the Accept-Ranges header.
Related
I input the URL in the address bar in the browser of the virtual machine, and the URL requests an HTML document in my host computer (this HTML document is also written by me). Then the HTML document is successfully displayed in the virtual machine browser. It seems that the HTTP request and response are successfully sent, otherwise the HTML document cannot be seen in the browser.
I tracked this process with Wireshark software and found the HTTP request (that is, the request for HTML document) sent by the virtual machine to my host computer, as shown in the following screenshot:(some personal information is masked with purple)
HTTP request
Double clicked this request to see the details and I found that:
request's detail
It showed the response is in frame 6.
However, the contents of the HTML document cannot be found after opening the details of the frame 6. I wrote the HTML myself. I know there are stuffs like "button", "input". Normally, the content of these HTML should be in the HTTP response, but I couldn't find it, not even a "body". There is no HTML document content in the HTTP response. The whole frame 6 is down below:
response's detail
You get a HTTP status code 304 Not Modified and not a status code 200 back. This means that the browser already had the response body and just verified with the server is the body is still the same as it has cached. You should see an If-None-Match field and/or If-Modified-Since
Since the body has not changed the server just informs the browser using status code 304 about this so that it uses the already cached response. It does not send the content again in the response body since it is not needed by the browser. If you want to get the actual content in the response make sure it is not already cached, i.e. remove all caches in the browser or use a client which does not cache, like curl.
I am trying to get a hang on analysing the performance of a web page using Firebug's Net panel.
The following screenshot shows an example of a google query. For the sake of this discussion I clicked twice, so some requests are cached.
So here are my questions:
1) What is happening between the end of the first request and the beginning of the next request (which is the third one). In the same context: Why is the third request starting earlier than the second request?
2) The next 6 requests are coming from the cache. The purple bar is indicating waiting time and I assumed this is the time the browser "waiting for the server to to something". So as comes from cache, what exactly is the browser waiting for. Also: What could be the reason, that the waiting time for for a 4,4KB response is longer (63ms) than for a 126,3 KB response (50ms).
3) In the next request there is a fairly long green bar indicating the time of receiving the response. How comes that this doesn't seem to be at least fairly proportional to the size of the response?
4) The red vertical line indicates the load event. According to https://developer.mozilla.org/en-US/docs/Web/Events/load this means: "The load event is fired when a resource and its dependent resources have finished loading." In the timeline you can see that there are still a couple of requests performed after the load event. How comes? Are they considered to be not dependent and if so why?
The response of the first request needs to be parsed to find out what else needs to be loaded. This parsing time causes the gap to the second request. See also my answer to a related question.
Responses coming from cache still have an associated network request, which returns the 304 HTTP status code. You can see the request and response headers as well as the response headers of the cached response when you expand the request.
In contrast to that there is also a response that is directly served from a special cache called Back-Forward Cache (or BFCache). These responses happen directly after the browser start when you have the option enabled to restore your tabs from the last session and also when you navigate back and forth in the tab history.
This depends on the network connection speed and the response's size in the first place but also on how long the server takes to send the full response. Why that one request takes that long in comparison to the others can't be explained without knowing what happens on the server side.
The load event is fired when the page request is loaded including all its depending resources like CSS, images, JavaScript sources, etc. Requests initiated after the load event are loaded asyncronously, e.g. through an XMLHttpRequest or the defer attribute of the element.
I have uploaded an mp4 video animation to Azure Blob Storage. The headers are are all default apart from setting the Content-Type to video/mp4. The video can be accessed at http://paddingtondev.blob.core.windows.net/media/1001/animation_default_headers.mp4
I have an Azure CDN sitting over that blob storage account. The URL for the same video through the CDN is http://az593791.vo.msecnd.net/media/1001/animation_default_headers.mp4
When I access the blob-stored video through an HTML5 video element on a web page, the browser (have tested in FF and Chrome) receives the entire video in a 200 HTTP response. Further requests for that video then receive a 304 response from blob storage.
However, when you request the video through the Azure CDN, it helpfully returns it to you as a series of HTTP 206 partial responses. This is in response to the browsers specifying a Range header with the request.
However, further requests for the video through the CDN are NOT cached, and the whole video is re-downloaded by the browser (through a series of further 206 requests).
How do I ensure the video is cached? I understand the usefulness of partial responses, but in our case the video won't be seekable and we only play it when the whole file is downloaded. I can see a few approaches here, but none have helped so far:
Forbid Azure CDN from returning partial responses
Remove range header from original browser request somehow
Persuade browsers to cache 206 partial responses
I have tried adding a max-age Cache-Control header to the file but this had no impact. Ideally we wouldn't even hit Azure at all when re-loading the video (as it will never change), but I'm happy to accept the cost of the HTTP request to Azure if it subsequently returns a 304 .
Caching 206 responses is tricky. The RFC for the client requires that in order to cache the content the ETAG and the range requested must match exactly.
There are a couple of things you can check -
1) Verify that the ETAGS did not change on the request. From the description of your environment (and setting the content expiration date), this sounds unlikely, but it may be an avenue to pursue.
2) More likely is that the range requests are not lining up. A request for byte range 1000-->2000 and a second request of 1500-->2000 would not (per RFC) be served from the client cache. So you may be in a situation of seeing exactly what is supposed to happen with that particular format/client.
I'm pretty sure HTML5 only supports progressive download, so unless you wanted to reconsider the delivery this may be expected behavior.
I am downloading an image using a GET request using XmlHttpRequest with cache disabled. In IE10, when I check the network panel, I see that the Received column shows different number of bytes and the content-length header shows the correct image size. Whenever I refresh the page several times, I see that the Received column shows different byte data always.
I need how much the size of the image is and how much time it took to download it for bandwidth calculation. For the time taken, I am getting the image entry from HTML5's performance.getEntries() and checking the duration. But for the image size, should I refer to the content-length header or the bytes received shown in network panel?
The Content-Length HTTP response header tells the browser how many byes the requested resource is. In your case, it should equal the size of the image on disk.
The Received column in the IE F12 Developer Tools shows you how many bytes were transferred across the wire, which will include the HTTP header and may or may not include the actual requested resource. For example, if the resource was already located in your cache, the Content-Length HTTP response header would list the requested resource's size, while the Received column in the F12 Developer Tools would show only the number of bytes of the HTTP 304 response header.
For your bandwidth calculation, on your dev machine, you should take the Received column to calculate how many bytes per interval were sent.
You will only be able to estimate the bandwidth "in the wild" since you can't access the developer tools on random visitor's machines. In that case, you would time how long it took to download the resource via window.performance.getEntries(), aka ResourceTiming.
To determine how many bytes were transferred for that resource in the wild, you can only guess. You know it was at least as many bytes as the file size, but you can only estimate the HTTP header size since it will vary per user / browser / proxy. You will also want to ensure the resource cannot be in the user's cache, so you should use a cache-busting URL parameter and/or set the appropriate HTTP Cache-Control headers.
I'd like to know if the POST method on HTTP sends data as a QueryString, or if it use a special structure to pass the data to the server.
In fact, when I analyze the communication with POST method from client to server (with Fiddler for example), I don't see any QueryString, but a Form Body context with the name/value pairs.
The best way to visualize this is to use a packet analyzer like Wireshark and follow the TCP stream. HTTP simply uses TCP to send a stream of data starting with a few lines of HTTP headers. Often this data is easy to read because it consists of HTML, CSS, or XML, but it can be any type of data that gets transfered over the internet (Executables, Images, Video, etc).
For a GET request, your computer requests a specific URL and the web server usually responds with a 200 status code and the the content of the webpage is sent directly after the HTTP response headers. This content is the same content you would see if you viewed the source of the webpage in your browser. The query string you mentioned is just part of the URL and gets included in the HTTP GET request header that your computer sends to the web server. Below is an example of an HTTP GET request to http://accel91.citrix.com:8000/OA_HTML/OALogout.jsp?menu=Y, followed by a 302 redirect response from the server. Some of the HTTP Headers are wrapped due to the size of the viewing window (these really only take one line each), and the 302 redirect includes a simple HTML webpage with a link to the redirected webpage (Most browsers will automatically redirect any 302 response to the URL listed in the Location header instead of displaying the HTML response):
For a POST request, you may still have a query string, but this is uncommon and does not have anything to do with the data that you are POSTing. Instead, the data is included directly after the HTTP headers that your browser sends to the server, similar to the 200 response that the web server uses to respond to a GET request. In the case of POSTing a simple web form this data is encoded using the same URL encoding that a query string uses, but if you are using a SOAP web service it could also be encoded using a multi-part MIME format and XML data.
For example here is what an HTTP POST to an XML based SOAP web service located at http://192.168.24.23:8090/msh looks like in Wireshark Follow TCP Stream:
Post uses the message body to send the information back to the server, as opposed to Get, which uses the query string (everything after the question mark). It is possible to send both a Get query string and a Post message body in the same request, but that can get a bit confusing so is best avoided.
Generally, best practice dictates that you use Get when you want to retrieve data, and Post when you want to alter it. (These rules aren't set in stone, the specs don't forbid altering data with Get, but it's generally avoided on the grounds that you don't want people making changes just by clicking a link or typing a URL)
Conversely, you can use Post to retrieve data without changing it, but using Get means you can bookmark the page, or share the URL with other people, things you couldn't do if you'd used Post.
http://en.wikipedia.org/wiki/GET_%28HTTP%29
http://en.wikipedia.org/wiki/POST_%28HTTP%29
As for the actual format of the data sent in the message body, that's entirely up to the sender and is specified with the Content-Type header. If not specified, the default content-type for HTML forms is application/x-www-form-urlencoded, which means the server will expect the post body to be a string encoded in a similar manner to a GET query string. However this can't be depended on in all cases. RFC2616 says the following on the Content-Type header:
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type field, the
recipient MAY attempt to guess the media type via inspection of its
content and/or the name extension(s) of the URI used to identify the
resource. If the media type remains unknown, the recipient SHOULD
treat it as type "application/octet-stream".
A POST request can include a query string, however normally it doesn't - a standard HTML form with a POST action will not normally include a query string for example.
GET will send the data as a querystring, but POST will not. Rather it will send it in the body of the request.
If your post try to reach the following URL
mypage.php?id=1
you will have the POST data but also GET data.