How Browser download files (via HTTP or FTP) - http

Please forgive me if it seems a silly question, I have this doubt and couldn't find the answer on the web.
How browser and any other downloader downloads a file, which protocol is working at the backend HTTP or FTP.
As we all know HTTP can be used to transfer text, which can be rendered by the browser. It can also send binary data.
Let's say I want to access a webpage at www.xyz.com/index.aspx which has a static webpage with 2 images. As we all know a total of 3 HTTP requests will be made, one for webpage and other 2 for images.
But what about other files which have a big size. I mean suppose I'm downloading an mp3/mp4 files (having link given on the webpage). So, what protocol is working at the backend HTTP or FTP.

It depends on the url :
ftp://www.example.com/bla/bla/bla01.zip
will be fetched via ftp, and
http://www.example.com/bla/bla/bla01.zip
will be fetched via http
Of course we cannot simply change http:// with ftp:// as http need an http server, and ftp need an ftp server.

Related

Encryption in Transit: HTTP to HTTPS

When sending data from a server / device through HTTP, to a destination that is enforced by https, is that data encrypted in transit?
HTTP -> HTTPS
Or does the source and the destination both have to enforce HTTPS?
A protocol is the language between a client and the server. This language might have features including ones related to security. HTTP is basically for browsers requesting web resources from web servers without any encryption, authentication or integrity protection. HTTPS is the same, but one that provides these features (HTTPS is actually HTTP, protected by TLS).
Each tcp connection between components uses one protocol (it's sometimes a little more difficult than that, but let's stick with this, it's good enough for now). In case of web components, it's typically either http or https. Each resource that is downloaded (a page, an image, a javascript file, any resource) is typically downloaded in its own separate connection. Whether that will be http or https depends on how the page references it.
So in practice, if you have a look at a html page that you downloaded over http, it can still reference resources with https urls, in which case those will be downloaded by your browser via https. It can also happen the other way round, a page downloaded over https can reference resources over plain http, but your browser will then warn you.
In short, your question doesn't make sense because you don't "send data through http, to a https destination". If the destination is https, the connection will be using https. In a web application, the page itself can be downloaded via http (in which case the html code and any data embedded in the html itself will not be protected against man-in-the-middle attackers), but it can reference further resources, images, css, javascripts via https, which your browser will then download securely.

Can I send HTTP headers on an FTP URL?

Is there any possibility to send HTTP headers on an ftp:// URL? How would I go about it?
What I want is HTTP based crawlers to see an HTML Response (in the headers) while human users see the pure FTP Content.
What would be the smartest way of solving this problem? I thought about user agent specific redirection, however this seems to be against most search engine's guidelines.
What I want is for bots to index an HTTP version of the content, while normal users can get access to the FTP version, all while using a single ftp:// URL.
Is this doable?
It's NOT doable.
You cannot redirect ftp:// URL to http:// URL. The FTP protocol has no redirects. FTP protocol does not even know what URL is. Nor does a web browser (acting as an FTP client) send "user agent" or anything similar to the FTP server.
There are also no headers in FTP protocol (but that's just a technicality, comparing to the fact above).
FTP protocol is completely different to HTTP.
You are obviously confused by the web browsers (all of them) presenting an FTP resource the same way as an HTTP resource. But it's just a "game" by the browsers. They are nowhere near similar.
Note that FTP was invented eons before Internet, HTTP, web and URLs.
Though note that you may be able to do it the other way around. You should be able to redirect HTTP to FTP.
But I still do not think it's a good idea. If the clients need FTP, they probably want to use a real FTP client, not a web browser. And a real FTP client won't understand HTTP (redirects).
But this question is kind of meaningless, now that all major web browsers are gradually removing a support for FTP anyway.

How web server sends a file to a client

I am trying to create a web server which has some clients, the webserver has some users(unregistered) which request some files and web server should send the requested file to users. Now my question is how the web server should send back the file? I do not want to make it like a ftp server, so should I create a socket and send file? what are other web servers doing to send the file?
The server will have to listen on some interface. Clients will start the process and connect to the server by opening a socket and request some content. On the same connection the server will respond with the requested content or an error.
Clients (usually browsers) communicate with Web servers using HTTP. At http://www.ietf.org/rfc/rfc2616.txt you can find the description of the protocol. For basic stuff it is quite simple.
Not much changes if the client asks for an HTML file (a web page) or some other file. In the header of the server's response (the first part sent), the client will find some information about the type of content, so that he knows how to display it. The header is followed by the actual data (file or some program generated data).
Hope this helps

Buffered uploading via HTTP Proxy

I am trying to solve an issue with uploads to our web infastructure.
When a user uploads media to our site, it is proxied (via our Web Proxy tier) to a Java backend with a limited number of threads. When a user has a slow connection or a large upload, this holds one of the Java threads open a long period of time, reducing overall capacity.
To mitigate this I'd like to implement an 'upload proxy' which will accept the entire HTTP POST data of the upload and only when it has received all of the data it will proxy that POST to the Java backend quickly, pushing the problem of the upload thread being held open to a HTTP proxy.
Initially I found Apache Traffic Server has a 'buffer_upload' plugin, but it seems a bit bleeding edge and has no support for regex in URLs, although it would solve most of my issues.
Does anyone know a proxy product that would be able to do what I am suggesting (aside from Apache Traffic Server)?
I see that Nginx has fairly detaild buffer settings for proxying, but it doesn't seem (from docs/explanations) to wait for the whole POST before opening a backend connection/thread. Do I have this right?
Cheers,
Tim
Actually, nginx always buffers requests before opening a connection to the backend. It is possible to turn off response buffering using proxy_buffering or setting an X-Accel-Buffering response header for per-response buffering control.

does http transfer files over FTP?

I've read something that looks wired to me!
I was reading an article that said HTTP uses FTP to transfer files!
I want to know is it true? if yes, how it transfers?
I mean how it can distinguish if it's a file and it's transferable over FTP? for example I can read a file with PHP and send it to user or just create a link to file! in both, headers can be same but in first case, it's impossible to transfer it over FTP!!!
Edit: I really appreciate if you provide me a good resource on this issue!
HTTP doesn't use FTP to transfer files. HTTP is a protocol in it's own right (HyperText Transfer Protocol) rather than FTP (File Transfer Protocol) but both use TCP transport layer.
the protocol hierarchy is
{http,ftp,xxx} -> {tcp,udp} -> ip
http and ftp are on the same layer(application layer)
have a look at Internet_protocol_suite
Yeah HTTP and FTP both run on the TCP protocol and do not piggy back on one another.
No HTTP don't use FTP for file transfer, but some HTTP client libraries like curl can handle both HTTP & FTP, and of course a web page can have ftp://some.org/some/ftp.link links
FTP is perhaps slightly faster, but is more complex and uses 2 connections (one for data, one for control).
There are many resources (and even books) on HTTP and FTP. I found good Shiflett's HTTP Developer's Handbook but there are many many others. Go to a library to find them.

Resources