Since I'm doing my share of both FTP and HTTP hacking in the curl project, I quite often see and sometimes get the questions about what the actual differences are between FTP and HTTP, which is the "best" and isn't it so that ... is the faster one?
FTP vs HTTP is my attempt at a write-up covering most differences to users of the protocols without going into too technical details. If you find flaws or have additional info you think should be included, please let me know!
The document includes comparisons between the protocols in these areas:
- FTP Command/Response
- Two Connections
- Active and Passive
- Encrypted Control Connections
- Persistent Connections
- Chunked Encoding
- Name based virtual hosting
- Proxy Support
- Transfer Speed
With your help it could become a good resource to point curious minds to in the future...
When I got to work this morning I immediately noticed that one of the servers that host a lot of services for open source projects I tend to play around with (curl, Rockbox and more), had died. It responded to pings but didn't allow my usual login via ssh. It also hosts this blog.
I called our sysadmin guy who works next to the server and he reported that the screen mentioned inode problems on an ext3 filesystem on sda1. Powercycling the machine did nothing good but the machine simply didn't even see the hard drive...
I did change our slave DNS for rockbox.org and made it point to a backup web server in the mean time, just to make people aware of the situation.
Some 12 hours after the discovery of the situation, Linus Nielsen Feltzing had the system back up again and it's looking more or less identical to how it was yesterday. The backup procedure proved itself to be working flawlessly. Linus inserted a new disk, partitioned similar like the previous one, restored the whole backup, fixed the boot (lilo) and wham (ignoring some minor additional fiddling) the server was again up and running.
David M. Kristol is one of the authors of RFC2109 and RFC2965, "HTTP State Management Mechanism". RFC2109 is also known as the first attempt to standardize how cookies should be sent and received. Prior to that document, the only cookie spec was the very brief document released by Netscape in the old days and it certainly left many loose ends.
Mr Kristol has published a great and long document, HTTP Cookies: Standards, Privacy, and Politics, about the slow and dwindling story of how the work on the IETF with the cookie standard took place and how it proceeded.
Still today, none of those documents are used very much. The original Netscape way is still how cookies are done and even if a lot of good will and great efforts were spent on doing things right in these RFCs, I can't honestly say that I can see anything on the horizon that will push the web world towards changing the cookies to become compliant.
They'll rely on more libraries to be present in the system rather than provide them all by themselves in their own install. This apparently includes libcurl.
So if you get the RPM of the pre-release player, you'll notice that it requires "libcurl.so.3" which is the old SONAME for libcurl (libcurl 7.15.5 was the last release which used the number 3) which no up-to-date distribution should provide anymore. Since october 2006 we've shipped libcurl.so.4.
Apparently, this made the Fedora people first implement a work-around for this that re-introduces the SONAME 3 from the same source the SONAME 4 is made from, only to a short while afterwards revert that decision...
An interesting side-note is how the Fedora people repeat over and over in those threads that libcurl with SONAME 3 and SONAME 4 use the same ABI, although that is not true (at least not by my definition of what an ABI is). The bump was not accidentally made.
Update: it seems some blame this 3 == 4 thing on Debian...
Apparently Internet Explorer 7 and earlier just don't care much for the Content-Type: header that servers reply, but they instead scan the body and guess what type it is. Thus "knowing better" than the content provider what content it truly is.
So in IE8 they're (according to that blog entry) introducing a new attribute to the Content-Type header. If the site also sets "authoritative=true" it means it really means the type and the browser will then actually believe the site. I can't stop giggling.
And yeah, some of the other craziness on that page is also good reading and they truly make you wonder what they are smoking during their brain storm meetings.
I won't be joining the attempted world record of Firefox downloads on the release day June 17th 2008 since I dist-upgraded my Debian unstable just a few days ago and I got my Firef... eh Iceweasel version 3 then.
Of course, others have also noted that Firefox will miss a few Linux users downloading that version as Linux users all over will prefer to get it using their distros' ordinary means of getting packages and updates...
I thought I'd just mention Patrik WallstrÃ¶m's interesting project named Creeper. He basically offers a URL for an image to display on the site you run/admin, and then his server checks which IP addresses that gets the image and then cross-checks those addresses against a list of IP ranges of known swedish organizations, government agencies, political party headquarters and more.
I mean, you can possibly (I mean if you hold on to your chair hard and really really try to extend your mind and be open) show sympathy and understanding for far-fetched stuff like "ping" and "prefetch" (or for that matter "author" and "contact"), but when they come to editing, drag-and-drop and how to deal with undo they certainly lost me. My favorite chapter in the draft is however this:
It takes a while just to suck up the concept of a HTML draft discussing broadcasting data. Over bluetooth. Man, these guys must have the best meetings!