"[i]s out already" apparently does not mean "I can go buy one." Unless I'm missing something, I can't put my hands on one right now unless I want to buy 10,000 of them.
I'm also extremely interested in how they plan to handle the composite/s-video outputs and DVD decoding under Linux...
I'd buy a few of the boxes right now if they were available at a reasonable price. (I just bought two PIAs but this is what I really want.)
720KB?! I distinctly remember being in ComputerLand (of West Lafayette, IN) with my father purchasing my first IBM-PC (the Real Thing). I recall thinking "double- sided floppy disks?! Why would I ever need to use both sides?" (180KB/side)
Coming from my TRS-80 CoCo, I thought I was all set - two SSDS floppies *and* I had a cassette tape interface!
Years later, I got to work with *real* tape storage - VHS. (Neat idea, but it just didn't work reliably.)
Good point, but apparently not completely correct.
Equifax sells wildcard SSL certificates. Instead of $45 for a regular certificate, these are more like $1000. (I was thinking of buying one for purdue.org, but I ended up with one of the cheapo ones for engineering.purdue.org.)
Maintaining a query_string (as in your example) is non-trivial. I did it for an early "shopping basket" program. It worked nicely, but it took some effort. Some of the CGI modules modules available now make this easy.
Another route is to use URLs of the form http://somehost.com/ID1234/real/path/. This simplifies things a bit; you can at least use relative paths in your document. You're still hosed if you use an absolute path, though. That's what sticking the info in the host name solves.
By now, someone has probably already come up with the next step, right? What piece of the URL haven't we touched? No, not the protocol; that would be too limiting. The port number! Now you're going to have to have pretty complete control over the host, but you *could* use a port number for session/ID tracking. IP chains might even make this fairly simple. (I'm just starting to play with it.)
Now for some horrible kludges that you can play with on just about any server. These will typically break when a proxy server is used, but they're still fun.
Let's say that the host name is "goofygeeks.com". You'd normally use the URL "http://goofygeeks.com/" but note that you can add trailing dots to the hostname. So..."http://goofygeeks.com.../" will work just fine and you can pick it off of the HTTP headers. Sure, it's of limited use, but it might come in handy.
For more flexibility, treat the letters of the host name as binary digits with a lower case character being '0' and an upper case chacter being '1'. So...to encode decimal 5, you'd use "http://goofygeeks.CoM/". This is one time when being tacky and using a "www" prefix helps a bit. With "www.goofygeeks.com" you have 2^16=65536 combinations to use. (Add dots to the end to multiply that.)
(Good grief! Did I really write "There not only useful"?! I'm getting the Slashdot spelling disease!)
For kicks, I decided to do some digging through old files. I found that I started testing wildcard A records for this and other uses back in December of 1999. (I had talked about it quite a bit before then, but hadn't implemented it.)
I'm also trying to track down old messages about it just in case that helps.
This has been one of the features I've been trying to hype for our new Web server cluster. I love wildcard A records. There not only useful for non-cookie sessions (I *hate* cookies.) but I have been playing with them to support being able to "log out" an HTTP authenticated connection. (So you'd authenticate with auth1234.foo.com and then the server could invalidate your authentication with that specific host name.)
I have public examples of my use of wildcard A records through purdue.org:
Slashdot Mirror
OpenTicket
"[i]s out already" apparently does not mean "I can go buy one." Unless I'm missing something, I can't put my hands on one right now unless I want to buy 10,000 of them.
I'm also extremely interested in how they plan to handle the composite/s-video outputs and DVD decoding under Linux...
I'd buy a few of the boxes right now if they were available at a reasonable price. (I just bought two PIAs but this is what I really want.)
720KB?! I distinctly remember being in ComputerLand (of West Lafayette, IN) with my father purchasing my first IBM-PC (the Real Thing). I recall thinking "double- sided floppy disks?! Why would I ever need to use both sides?" (180KB/side)
Coming from my TRS-80 CoCo, I thought I was all set - two SSDS floppies *and* I had a cassette tape interface!
Years later, I got to work with *real* tape storage - VHS. (Neat idea, but it just didn't work reliably.)
If you want to give me $75-$100 for a small 2.5" IDE drive, let me know and I'll send you my address.
Good point, but apparently not completely correct.
Equifax sells wildcard SSL certificates. Instead of $45 for a regular certificate, these are more like $1000. (I was thinking of buying one for purdue.org, but I ended up with one of the cheapo ones for engineering.purdue.org.)
Maintaining a query_string (as in your example) is non-trivial. I did it for an early "shopping basket" program. It worked nicely, but it took some effort. Some of the CGI modules modules available now make this easy.
Another route is to use URLs of the form http://somehost.com/ID1234/real/path/. This simplifies things a bit; you can at least use relative paths in your document. You're still hosed if you use an absolute path, though. That's what sticking the info in the host name solves.
By now, someone has probably already come up with the next step, right? What piece of the URL haven't we touched? No, not the protocol; that would be too limiting. The port number! Now you're going to have to have pretty complete control over the host, but you *could* use a port number for session/ID tracking. IP chains might even make this fairly simple. (I'm just starting to play with it.)
Now for some horrible kludges that you can play with on just about any server. These will typically break when a proxy server is used, but they're still fun.
Let's say that the host name is "goofygeeks.com". You'd normally use the URL "http://goofygeeks.com/" but note that you can add trailing dots to the hostname. So..."http://goofygeeks.com.../" will work just fine and you can pick it off of the HTTP headers. Sure, it's of limited use, but it might come in handy.
For more flexibility, treat the letters of the host name as binary digits with a lower case character being '0' and an upper case chacter being '1'. So...to encode decimal 5, you'd use "http://goofygeeks.CoM/". This is one time when being tacky and using a "www" prefix helps a bit. With "www.goofygeeks.com" you have 2^16=65536 combinations to use. (Add dots to the end to multiply that.)
Enjoy!
(Good grief! Did I really write "There not only useful"?! I'm getting the Slashdot spelling disease!)
For kicks, I decided to do some digging through old files. I found that I started testing wildcard A records for this and other uses back in December of 1999. (I had talked about it quite a bit before then, but hadn't implemented it.)
I'm also trying to track down old messages about it just in case that helps.
So...don't use it for images! (Sheesh! Talk about things being obvious...)
This has been one of the features I've been trying to hype for our new Web server cluster. I love wildcard A records. There not only useful for non-cookie sessions (I *hate* cookies.) but I have been playing with them to support being able to "log out" an HTTP authenticated connection. (So you'd authenticate with auth1234.foo.com and then the server could invalidate your authentication with that specific host name.)
I have public examples of my use of wildcard A records through purdue.org: