I am writing an embedded web server, and want to avoid unnecessary protocol aspects, to save limited flash memory. Is there a universal way to prevent browsers from sending the Expect: header when uploading a file?
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect:
No common browsers send the Expect header, but some other clients such
as cURL do so by default.
Does such language imply that future versions of common browsers will also not send the Expect header? If not, how would I prevent them from doing so?
Related
It may seem to be a trivial question but still.. I have a confusion over it.
Almost at every site I have read that HTTP persistent or keep-alive connections are better than the non-persistent one.
Ques: So, why do non-persistent even exists?
Some says that persistent has disadvantage if server is serving many clients as users are deprived of connection.
Ques: All the popular websites server millions of clients, does that mean they don't use persistent mode?
As per my understanding I can think search engines may not be using persistent connections.
Can someone please enlighten me on this topic.
Another doubt I have is regarding the HTTP requests. I have read that if a page contains link to several objects then web browser makes that many request to fetch all those (this is why persistent connections are used). My doubt is why all the objects are not embedded in the page and sent as one object? If argument is that it makes page heavy and not bandwidth friendly then anyways the browser open parallel connections to fetch multiple objects which again putting the same load on the network.
OK, I understand that this cannot be done for like image search but if a page contains few objects then can we embed them into the page and send.
These may seem foolish questions but I can't help. I have a doubt and I need to clear that and you can help.
Thanks
The original HTTP specification always uses non-persistent connections; HTTP/1.1 added persistence because it is more efficient for web pages that embed a lot of external objects (which were rare when HTTP/1.0 was written.)
However, even though HTTP/1.1 allows persistent connections there are implementations that don't support them, or which still only support HTTP/1.0. For this reason, HTTP/1.1 requires that the Connection: keep-alive header be sent in order to enable this feature, and Connection: close be sent to disable it.
It is possible to include media directly in the HTML by base64 encoding the data and including it in a data: URL. This is not usually done because it slows down your web browser. With a standard HTML page, the browser can start rendering the structure of the page without waiting for the (rather large) inline data: links to download.
As you say most of the webpages hosted over the internet will not only handle fewer data, and nobody can estimate that. The HTTP server should be generic and it should have a mechanism to avoid multiple requests in the name of dependencies. You say that the non-persistent method avoids the blocking of ports by a single client for a long time where as the server may have to serve more clients and it would give a lot of stress, that is not true. Persistent connections actually reduce the load for a server by limiting the number of queries it has to serve.
Hope this HTTP Persistent connection will help you understand.
I know that currently HTML5 video compatible browsers use the Accept-Ranges header to seek inside streams, but it is far from an ideal solution. The browser needs the full index information of the file to do this effectively, and this is not possible for live-stream optimized formats, like fragmented mp4 and chunked mkv (or WebM).
Is there a feature of HTTP or an extension which operates with timestamps (instead of bytes).
I know it is unlikely that such a standard is supported in browsers yet, with these early implementations. I am just interested if even such standard or proposition exists.
No, the http protocol is not aware of the content in the body as such. You might be able to run a cgi that delivers the file and it would accept a timestamp as a parameter to continue the stream from that position.
There are a specific set of process happens between a user hits www.google.com and see the page in the browser. Can anybody tell me what all things that happen during a similar process. Also how mobile browser is different from web browser.
This really depends on what browsers you're comparing. For example, Safari Mobile and Safari for Mac are quite similar to one another, so much so that you often see the same page on both. However IE for Pocket PCs is much different than IE8 and pages would render somewhat differently in those two.
Usually, site operators check the UserAgent string that all browsers have, to see which browser it is. Then, it's up to the site operator to show a mobile site or a regular site based on whether they want to or not.
PPK has a great list of all browser quirks and features, at quirksmode.org. It's a must-read for mobile development.
Name resolution. www.google.com gets resolved to an IP address through domain name
HTTP Request. The browser sends a GET request to server.
HTTP Response. The server sends back an HTTP response.
Parse. The client parses the resulting document and resolves referenced assets (css, images, etc)
HTTP Requests. For each referenced asset, the browser sends another request to the server.
HTTP Response. For each referenced asset, the server responds.
In this respect, how http is requested, mobile is not different than desktop.
Aame stuff happens, mobile browser(s) renders html documents like your pc browser(s).
Of course they might have have less memory, different rendering engine(s), run on a very small screen etc etc etc. But, at the end it is just another http request to google.com.
Depending on network or connection type to the net there might be another difference. Operator gateway/proxy. Some operators filter/proxy all communication to the net.
Also (usually) internet traffic from operator's customers to the net routed through couple of public IPs
when a web application serves a video file, is it stream automatically? what options are there?
Your question is vague. The behavior you get will depend on what Content-Type header your "web application" (or container) gives your file.
Different types will do different things depending the browser.
http://en.wikipedia.org/wiki/Internet_media_type
If you want to check what headers your application is sending, use Firefox + Live HTTP Headers.
By default, video files are sent from IIS to clients in burst mode, at the highest bandwidth that the connection can support.
There is an extension for IIS that provides support for streaming and bit rate throttling:
http://www.iis.net/extensions/BitRateThrottling
It support many media types, but not all of them--although it is extensible.
Is it possible to compress data being sent from the client's browser (a file upload) to the server?
Flash, silverlight and other technology is ok!
Browsers never compress uploaded data because they have no way of knowing whether the server supports it.
Downloaded content can be compressed because the Accept-Encoding request header allows the browser to indicate to the server that it supports compressed content. Unfortunately, there's no equivalent protocol that works the other way and allows the server to indicate to the browser that it supports compression.
If you have control over the server and client (e.g. using silverlight, flash) then you could make use of compressed request bodies.
For Silverlight there is a library called Xceed which amongst other things "Lets you compress data as it is being uploaded.", it is not free though. I believe that this can only be done via a technology such as Flash or Silverlight and not natively on the browser.
I disagree with the above poster about browsers doing this automatically and I believe this only happens with standard HTML/CSS/Text files and only if the server and browser both have compression enabled (gzip, deflate).