Slashdot Mirror

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

This one I didn't understand. If you wanted to do this, why not have something like

ftp://example.com 2001:f00:ba7:2::5:21
http://example.com/ 2001:f00:ba7:2::5:8080

In the above case, you can use ftp port# 21 to indicate that it's FTP, and 8080 to indicate http. Since the port# are from 0 to 65535, you could even convert that into HEX, if there were a wide range of protocols you were using.

So I didn't exactly get your issue w/ this one.

Too bad. Now every time I want to switch to a backup ISP (when the main connection goes down) I'll have to reconfigure all computers in the internal network (maybe some script will be able to do it automatically).

This is what router advertisements are for. You switch ISP, your router starts advertising the new prefix, everything carries on working. (If you're really smart you'll use IPv6 mobility extensions, although that would require some support from your ISP since your connection has died).

If I ever wanted to load balance between two ISPs and use standard software that would be impossible.

Now this one is something that I haven't seen a good solution to (without having a PI prefix and support from the ISPs). But then again, I haven't looked very hard.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too.

That's what SRV records are for (although admittedly I doubt any FTP clients and web browsers support them, but they work well for a lot of other protocols).

If I wanted to make a server believe that two clients are actually the same one - that would be impossible too.

Uh.. why would you want to?

No more transparent proxies - remember the special URL to log in to the ISP (now you just get redirected there)

Transparent proxies work just fine.

NAT has more uses other than the "share one external IP to multiple computers".

Very few. Most of which can be better implemented without NAT (e.g. using IPv6's mobility extensions, etc.) On the other hand, the fact that practically everything goes through a NAT causes all sorts of brokenness that I would be more than happy to not have to deal with. I'm willing to live without the relatively minor benefits of NAT if I get to avoid having to put up with the brokenness it induces.

Too bad. Now every time I want to switch to a backup ISP (when the main connection goes down) I'll have to reconfigure all computers in the internal network (maybe some script will be able to do it automatically). After all, the other ISP will give different IPs and instead of the router just using whatever external IP it has and the PCs not caring, now the connection will be disrupted for some time until all PCs realize that the main connection is dead.

If I ever wanted to load balance between two ISPs and use standard software that would be impossible.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

If I wanted to make a server believe that two clients are actually the same one - that would be impossible too. Well, I could use a proxy server, but that requires that the client software supports using proxies.

No more transparent proxies - remember the special URL to log in to the ISP (now you just get redirected there) and no more upside-down-ternet.

NAT has more uses other than the "share one external IP to multiple computers".

So, user uploads a file - say, a picture for a forum avatar. Your image validation misses that malicious_flash.jpg is really a SWF file, and now you're executing flash all over the place "in the context of your domain." Which I guess means any SWF file I manage to upload anywhere can eat the hosting webserver.

Also, from the article:

To be sure, any server that allows unvalidated uploads of contents will let an attacker upload html pages with cross-site scripting or other attacks, but SWF files do not require a .swf extension or special content-type headers to execute.

This is what I don't get: I understand that if a JPG is also a SWF (as per GIFAR and other manglements), it'll fool the browser into loading the content as flash.

Simply chucking a SWF on a server, renaming it to foobar.jpg, and visiting it at http://example/foobar.jpg doesn't load it as flash. Unless I'm really missing something here, I don't see how you can get the JPG to run as flash without also mucking around with content-type headers.

Can someone enlighten me, please? :-)

If I can go off and register http://example/ wont I also be able to set up subdomains?

http://forums.mysite/
http://chat.mysite/

and so on? Isnt this just the same as giving people the right to register their own TLDs?

For example, on a medical page, its quite possible they want you to acknowledge that using their website does NOT constitute actual medical advice, and that you should seek a doctor's professional opinion if you are having issues.

What's wrong with placing something along the lines of "This is not medical advice nor legal advice. This document is provided under these disclaimers" at the top of the page? (Or was that just a bad example?)

If the operators of a web site really want to authenticate users who have read and agreed to a contract, they should set up nick/pass authentication and serve all pages with SSL.