Computing desk
< August 23	<< Jul \| August \| Sep >>	August 25 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

August 24

Making an FTP connection secure

If I have a FileZilla server on a machine, what steps should I take to make it secure? This is my first time using an FTP server. Or client, for that matter. KyuubiSeal (talk) 04:22, 24 August 2011 (UTC)[reply]

Check out SFTP. It's a purpose-built protocol that adds FTP-like functionality to the SSH encryption protocol. FileZilla Server can't do SFTP yet, but it's fairly easy to set up with OpenSSH; FileZilla Client can connect to SFTP servers. See here (the link was written for OpenBSD, but it should be fine with any OpenSSH install). If you'd rather stick with FileZilla Server, there's also FTPS, which tunnels FTP through an encrypted SSH connection. See here. CaptainVindaloo ^{t c e} 13:56, 24 August 2011 (UTC)[reply]

Should I check 'disallow plain unencrypted FTP' and 'force PROT P to encrypt file transfers in SSL/TLS mode'? Pretty sure what the first one does, but what's the second? KyuubiSeal (talk) 17:58, 24 August 2011 (UTC)[reply]

Yes, it looks like you probably should check both - they'll stop your clients from accidentally using plain FTP and force them to use secure FTP. Google round a bit as well just to make sure - personally, I'm more familiar with the OpenSSH SFTP route. CaptainVindaloo ^{t c e} 20:32, 24 August 2011 (UTC)[reply]

Okay. Thank you! KyuubiSeal (talk) 00:27, 25 August 2011 (UTC)[reply]

History of computers

I have studied Dell and Lenova computers on Wiki. Only on rarest occasions is the time of introduction to market of these products mentioned. Hundreds of different products are described in considerable detail but the time of intro appears some sort of secret. Can this info be brought to light? Tnx — Preceding unsigned comment added by 74.77.208.180 (talk) 11:29, 24 August 2011 (UTC)[reply]

Can you provide a link to an article you need information added to? I checked Dell Optiplex and it has dates in it. I checked Lenovo Thinkpad and it has dates in it. -- kainaw ™ 12:41, 24 August 2011 (UTC)[reply]

Reloading without re-caching

Is there any logic to the fact that many modern browsers will not force a re-caching of a page when reload/refresh is hit? I've found it very odd to have to hold down extra keys to do it manually, or to empty caches, and so forth, and trying to explain to people who are not aware of such practices that indeed, reload often does nothing without extra prompting, makes me feel like an imbecile. What's the logic behind this common "design choice"? --Mr.98 (talk) 17:08, 24 August 2011 (UTC)[reply]

Web pages were not designed to change. Web browsers were note created to be the main interface for applications. So, once you downloaded a web page, that was good enough. The likelihood that it would change anytime soon was very small. In recent years, some people have decided to abuse the overall web functionality to try and turn web servers into application servers and web browsers into thin clients. It hasn't worked out very well because that is not the purpose of web servers and web browsers. However, it has worked well enough that the main browsers are continuing to increase support for web-based applications. In time, it may be accepted that the norm for a web page is that it will change often. Then, the function of "reload" will change. -- kainaw ™ 17:18, 24 August 2011 (UTC)[reply]

The rationale is presented in RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1, Section 13, Caching in HTTP.

I agree in principle with what Kainaw's saying above; it's symptomatic of the larger problem of "the web browser has become a crappy, broken, type of virtualized operating system." The root-problem is that "web browser" was originally a single-use piece of software; it contained nothing but a tiny piece of network-transfer logic, and a special-purpose document-rendering algorithm for the HTML file format. That was the design decision. Hypertext is a great idea; interactive content is a great idea; but implementing a major application in browser-hosted Javascript is not a good idea. For reasons that completely baffle me, web developers have decided to run with this approach anyway, leaving browser vendors with few options: either support this inane "design-choice" foisted on the internet community by inept web developers; or appear "incompatible" with popular websites. Nimur (talk) 17:47, 24 August 2011 (UTC)[reply]

The reason people used web browsers as an application platform is that they were widely deployed. A web browser was the only network application you could assume was present on the average Internet-connected computer. I am also sad that we've ended up with such a crappy application platform as a result. It's not too late to fix it. Google probably has the power to fix it, but they seem disinclined to. -- BenRG (talk) 20:07, 24 August 2011 (UTC)[reply]

I highly recommend this article by Mr. Stallman, The JavaScript Trap. Have a look at a sample "web app": VUpekTt_V6c.js from Facebook.com. They honestly want me to run that on my machine? No thank-you. Send me an .exe file; at least if native code turns out to be malware, I can trust my operating system to sandbox it. But major corporations prefer to hide their privacy-invading malware in javascript. Personally, I don't want VUpekTt_V6c.js sharing a PID and an address space with my email client. Nimur (talk) 21:18, 24 August 2011 (UTC)[reply]

I don't think that machine code has any advantages over JS in that way. Memory isolation is good, but native applications can do whatever they want with my home directory. On the other hand, browsers do a great job of ensuring that JS can't see anything outside the browser, and there are tools available to further control what JS applications can do. It seems sort of silly that browsers are reliving the history of the operating system, but the fail-soft nature of the Web makes it easier to selectively disable the intrusive parts. Paul (Stansifer) 16:21, 25 August 2011 (UTC)[reply]

Even with an assumption of general static behavior, it still doesn't make much sense to me that "reload" doesn't reload the page, and instead reloads the cache. The utility of the latter seems quite limited to me, while the former seems obvious. In the case I was dealing with today, it was not a dynamic page at all that needed reloading, but a static one that had happened to be updated (as pages occasionally are!). Ugh. --Mr.98 (talk) 18:40, 24 August 2011 (UTC)[reply]

You are reading "reload" as meaning "reload the content from the server" when it actually means "reload the content into the HTML rendering engine". -- kainaw ™ 18:46, 24 August 2011 (UTC)[reply]

Like BenRG says below, this shouldn't be a problem - the server should tell the browser the content is new, and the browser should put the new content into the cache during a soft reload, instead of using the old content. This should also work on a per-object basis (e.g. for images) so that unchanged content can be re-used where it still appears on the page. For slow connections, and for the sake of reducing server load and generally being bandwidth-friendly, this is a good thing. 213.122.43.26 (talk) 09:57, 25 August 2011 (UTC)[reply]

Web servers have the power to control client caching behavior. They can:

send an "Expires" or "Cache-Control: max-age" header with the response; the client won't contact the server again until the expiration date has passed.
send a "Last-Modified" header; the client remembers the date and sends it back to the server when refreshing the page; the server responds with 304 Not Modified if the page hasn't changed since then.
send an "ETag" header, which is like Last-Modified except that it's a magic cookie instead of a date.

If you're getting stale page data, something has gone wrong with this mechanism. One possibility is that the server is sending an expiration date in the future for the static web page, not knowing when it will actually change. Another is that there's a caching proxy between the browser and the server that is out of sync with the server, or is just plain broken. Also, when the server doesn't send any cache control information, I think that browsers use their own heuristics rather than re-downloading the data on every refresh, since people refresh pages a lot, and the uncooperative servers tend to be older ones hosting static pages anyway. In particular, I think browsers will assume that inline images in a page change rarely if ever. You can override all of this by instructing the browser to pretend that it doesn't have any of the page data cached, or by sending a header that instructs intermediate caches to update themselves. This system is probably the best possible, overall. Redownloading everything every time would incur significant extra expense for the people who provide free services on the web. -- BenRG (talk) 20:07, 24 August 2011 (UTC)[reply]