Slashdot Mirror

A lot of servers we do security for have stuff at http://domain.com/employeeport... and http://domain.com/he/ or whatever, but nothing on the index page.

Another chunk are non-web servers. Domains aren't just for web sites, of course. Others are only accessible from certain networks and VPNs, something like DellTeamNet.com for Dell employees or whatever.

I wonder how many of the "empty", "error", "unused", and "no web server" are actually used - just not for a public web site with a normal index page.

A lot of servers we do security for have stuff at http://domain.com/employeeport... and http://domain.com/he/ or whatever, but nothing on the index page.

Another chunk are non-web servers. Domains aren't just for web sites, of course. Others are only accessible from certain networks and VPNs, something like DellTeamNet.com for Dell employees or whatever.

I wonder how many of the "empty", "error", "unused", and "no web server" are actually used - just not for a public web site with a normal index page.

The point is not where *you* want to go, but rather where the network administrators want you to go. DNS entries allow these to point to different servers and with good reason.

In my own case domain.com redirects to www.domain.com. However www.domain.com is not the host of any content, it's a front end transparent proxy to another server on the network. If I want to access this data: ftp://www.domain.com would put me in the wrong place which is why my dns entry for ftp://ftp.domain.com has a different IP address.

Your google example is a bit off for two reasons. Firstly they have an entirely different TLD for that: gmail.com, and secondly pop.gmail.com points to a different server than www.gmail.com. If you attempt to access your email with the latter you'll get a connection error.

If however you were talking about actually sending an email to example@google.com and pointing out that you don't need to differentiate, that's because DNS has a special entry for that case. Instead of an A record or an AA record, emails go via the MX record. That MX entry forwards your email to aspmx.l.google.com which will handle the email request.

The point is not where *you* want to go, but rather where the network administrators want you to go. DNS entries allow these to point to different servers and with good reason.

In my own case domain.com redirects to www.domain.com. However www.domain.com is not the host of any content, it's a front end transparent proxy to another server on the network. If I want to access this data: ftp://www.domain.com would put me in the wrong place which is why my dns entry for ftp://ftp.domain.com has a different IP address.

Your google example is a bit off for two reasons. Firstly they have an entirely different TLD for that: gmail.com, and secondly pop.gmail.com points to a different server than www.gmail.com. If you attempt to access your email with the latter you'll get a connection error.

If however you were talking about actually sending an email to example@google.com and pointing out that you don't need to differentiate, that's because DNS has a special entry for that case. Instead of an A record or an AA record, emails go via the MX record. That MX entry forwards your email to aspmx.l.google.com which will handle the email request.

Playing Devil's advocate for a moment, we already have ports to separate out different services.

Just give users queue cards then when they need to access services.

But the point of these was not to split services but to split servers. ftp.domain.com serving up a different website on port 80? That means going to ftp://domain.com/ will not give you the content you were hoping for.

favicon.ico, retrieved by default by Internet Explorer and now most major browsers (short for Favorites Icon) and before tabs was used to put an icon on favorites shortcuts and desktop web shortcuts. Go ahead and use Internet Explorer to retrieve http://domain.com/ and shortly thereafter, check your web server logs to see a request to http://domain.com/favicon.ico - this behavior seems to be default in most browsers now. It also serves as the sole identifier on tabs on browsers with too many tabs open to show title text, which is the point of the story post.

Since the early days, support has been added to HTML to set its location/format manually with <link rel="shortcut icon" href="">.

Apple decided to completely forego the existing HTML, and then defines <link rel="apple-touch-icon"> to define the image that appears when you make a web page a shortcut on your phone/tablet home screen.

favicon.ico, retrieved by default by Internet Explorer and now most major browsers (short for Favorites Icon) and before tabs was used to put an icon on favorites shortcuts and desktop web shortcuts. Go ahead and use Internet Explorer to retrieve http://domain.com/ and shortly thereafter, check your web server logs to see a request to http://domain.com/favicon.ico - this behavior seems to be default in most browsers now. It also serves as the sole identifier on tabs on browsers with too many tabs open to show title text, which is the point of the story post.

Since the early days, support has been added to HTML to set its location/format manually with <link rel="shortcut icon" href="">.

Apple decided to completely forego the existing HTML, and then defines <link rel="apple-touch-icon"> to define the image that appears when you make a web page a shortcut on your phone/tablet home screen.

What is the public internet?

If I have a private link https://domain.com/afdcp43q43p43wqpmcdcmcpqc3poicq it is every bit as secure as a site with a password, or do you mean public internet as in the internet is public, and therefore you have access to everything?

I think this is a hell of an approach for a country to ensure that it's business world doesn't try to offshore and outsource it's services to evade taxation.

I think using a country TLD is also a source of national pride. The .com may be international, but not all businesses are international in nature.

I was going to register a .ca myself, but I soon learned it's far more expensive to get a .ca domain than a .com. A .ca will have to wait until I can afford it, in the meantime the http://domain.com/tld-code/ approach will work, particularly as the concern is more to provide language options that country/region options.

4. IP addresses: This is a big one, if you host multiple websites on your server, and you only have a single IP address, you can't host more than one SSL certificate.

Any SSL cert that I've ever used was tied to a name, not an IP address. Try going to secure website and view the certificate. Do you see an IP address amongst the certificate details?

Using multiple names for the same site is an issue, however. If you want to accept both https://www.domain.com/ and https://domain.com/ for example, you need to pay for a more expensive type of certificate, or else your users will get a scary warning message when they connect with a name that's not on your certificate.

4. IP addresses: This is a big one, if you host multiple websites on your server, and you only have a single IP address, you can't host more than one SSL certificate.

Any SSL cert that I've ever used was tied to a name, not an IP address. Try going to secure website and view the certificate. Do you see an IP address amongst the certificate details?

Using multiple names for the same site is an issue, however. If you want to accept both https://www.domain.com/ and https://domain.com/ for example, you need to pay for a more expensive type of certificate, or else your users will get a scary warning message when they connect with a name that's not on your certificate.

As the sibling post said w=wikipedia, d=dictionary.com, etc., ...

But I do use Google sometimes. If I use Konq (which occasionally I need too, but only very occasionally) then ctrl-enter doesn't work to fill in the http://www.domain.com/ around the typed in $domain. It's therefore less clicks+presses to do "gg://$domain" and click the [what is usually the] first listing. YMMV.

If you're a keyboard user then aren't the search and address bars only one tab apart. That would account for a lot of misfires too.

Not only are they spamming the whole web, their code is buggy. For example, it does not pay attention to the directive. We use a load of rewrites on our website, and relative naming to js and css files. We started getting loads and loads of traffic to our site a few months ago. Looking at the logs, you could see requests like this:

http://www.domain.com/certain_rewritten_url/js/javascript.js
http://www.domain.com/certain_rewritten_url/js/js/javascript.js
http://www.domain.com/certain_rewritten_url/js/js/js/javascript.js

and so on. Because of our rewrite rules, our site was just ignoring everything after the "certain_rewritten_url", and serving up a real page. On this page was our js includes again, so the loop would continue. We thought it was some trojan bot, but we fixed it by using absolute URLs for js and css files and all is fine. I couldn't believe it when this AVG virus story hit the press that it was actually those bastards causing it! What they have done is simply unbelievable. If they want to do such a feature, they should setup their own spider and their own database of malicious websites. Then users can query their database if they want this feature. It's like Google saying "We're not going to spider the internet for everyone anymore, we'll give you our software and you call all spider your own copy and query that instead of us."

Not only are they spamming the whole web, their code is buggy. For example, it does not pay attention to the directive. We use a load of rewrites on our website, and relative naming to js and css files. We started getting loads and loads of traffic to our site a few months ago. Looking at the logs, you could see requests like this:

http://www.domain.com/certain_rewritten_url/js/javascript.js
http://www.domain.com/certain_rewritten_url/js/js/javascript.js
http://www.domain.com/certain_rewritten_url/js/js/js/javascript.js

and so on. Because of our rewrite rules, our site was just ignoring everything after the "certain_rewritten_url", and serving up a real page. On this page was our js includes again, so the loop would continue. We thought it was some trojan bot, but we fixed it by using absolute URLs for js and css files and all is fine. I couldn't believe it when this AVG virus story hit the press that it was actually those bastards causing it! What they have done is simply unbelievable. If they want to do such a feature, they should setup their own spider and their own database of malicious websites. Then users can query their database if they want this feature. It's like Google saying "We're not going to spider the internet for everyone anymore, we'll give you our software and you call all spider your own copy and query that instead of us."

Not only are they spamming the whole web, their code is buggy. For example, it does not pay attention to the directive. We use a load of rewrites on our website, and relative naming to js and css files. We started getting loads and loads of traffic to our site a few months ago. Looking at the logs, you could see requests like this:

http://www.domain.com/certain_rewritten_url/js/javascript.js
http://www.domain.com/certain_rewritten_url/js/js/javascript.js
http://www.domain.com/certain_rewritten_url/js/js/js/javascript.js

and so on. Because of our rewrite rules, our site was just ignoring everything after the "certain_rewritten_url", and serving up a real page. On this page was our js includes again, so the loop would continue. We thought it was some trojan bot, but we fixed it by using absolute URLs for js and css files and all is fine. I couldn't believe it when this AVG virus story hit the press that it was actually those bastards causing it! What they have done is simply unbelievable. If they want to do such a feature, they should setup their own spider and their own database of malicious websites. Then users can query their database if they want this feature. It's like Google saying "We're not going to spider the internet for everyone anymore, we'll give you our software and you call all spider your own copy and query that instead of us."

I dont underestimate the iPhone's impact, rather I disagree with most people posting here about how either won't matter, or will require every custom U/I Web 2.0 site be rethought immediately.

While it's true that it's Apple's responsibility to ensure compatibility - can we all be honest and say "they won't." Apples image is all about being edgy and fun, and DIFFERENT and if that means that some conformist IE "tested" sites don't work, it's not their problem. Apple has a track record of introducing disruptive products, so I don't think breaking a few websites will cause them to lose any sleep.

The reality is that the Web 2.0+AJAX is around to stay, and big popular sites offering "rich content" which utilize the latest and greatest technology to deliver a better experience will end up with more users, regardless of their impact of the iPhone. If your site gets enough traffic, you can afford to detect the browser type (even if it's just Safari in general and screw the rest of the mac population - let 'em use firefox) and then redirect + downgrade the experience e.g. http://www.safari.domain.com/ -- this will be necessary in order to monetize the most traffic possible - it's just common business sense.

If you run an e-commerce site, looking into a platform that offers a CMS (Content Management System) that allows you to have one product & content database, with multiple different websites is certainly what you're looking for if you want to maximize your revenue. Platforms like Zoovy http://www.zoovy.com/ offer the ability to display different sites to different users pretty easily, in addition to being able to do very cool A/B multi-variable testing. This makes supporting everything between Web 2.0/AJAX & .mobi domains incredibly easy. I'm not sure if anybody else in the e-commerce industry does that yet. ??

But having multiple websites built from the same content is relatively easy.
Hope that helps.

Which actually sucks, because I had just got done training my dad to log into his webhosting account with ftp://domain.com and to type in his password in the pop-up, and then to drag-and-drop his files in order to upload them (mostly pictures he takes of my kid, in the form of "look at my grandkid").

I had to wait until I could get back to my parents' house to install a real FTP client, and then train him on using FileZilla, after he installed IE7. I had also trained him to install microsoft updates when he goes to bed at night (they use AOL and are in the country, so they connect at 33600 at the best). He's a good guy and he means well. I don't really see what microsoft gains from this. I mean, heck, even I have my bookmark for totalfark in firefox set to http://totalfark.com./

~Wx

I just want to combat some misinformation I've been seeing.

Linking, at its most basic level, is not stealing. It's not even copyright infringement. A link is merely a reference to an existing resource. Nothing more. By linking to the PDF of your book on your website, I'm no more infringing your copyright than if I told someone where to find a free copy (perhaps in the free box of a yard sale.)

A lot of individuals seem to think that anything that prevents them from making money from their work is inherently a violation of their copyright, but I'm sorry. The internet just doesn't work that way. If you want to protect your work, put it behind some kind of basic barrier (a login, a CAPCHA, something.) Then you can sue deep linkers under the DMCA for circumventing your copyright protection mechanism. A blanket ruling stating that any webmaster can object to and remove a link to any "deep" (read: non-home) page on his site is just a bad idea. Many website TOS's already (unenforceably) forbid deep linking. If this ruling spreads, any website that generates ad revenue, or relies on branding, will start adopting similar language. And since that constitutes about 85%* of the useful web, this is unquestionably bad.

Some people can't seem to understand the role deep linking plays in the useful web. Almost any informational article or resource of any length references very specific pages on other websites. This type of thinking will eventually require any web developer to do careful research on any website he wants to link to, checking their TOS policies to find out if deep linking is illegal.

Now, one slightly more rational view seems to be that one can safely deep link, and need only remove links when a content owner specifically objects. Other more disturbing views insinuate that a web developer should "just send an e-mail" before he establishes a deep link. This would turn every website article into an arduous process of research and documentation, cataloging permission for every link in every page.

Eventually, this will lead to the web being broken down into mostly web sites linking to the homepages of other websites. References in articles will become like this (Click on Articles, click in the search box and type 'Pandas'. Go to page 3, click the 3rd article from the top ('Panda Lifecycle'.) The search results may be different, so you might have to hunt around.)

If you disagree, you obviously don't understand the nature of the web. To those of you who argue that "everyone should just be reasonable", nobody is ever reasonable when it comes to money. And believe me, the web is now very much about money.

Now, I'm not talking specifically about this ruling, which may or may not embody all of the above ideas. I'm speaking more to the concept of conflating deep linking with theft, and many of the ideas and beliefs which have been espoused in this thread. The bottom line, this is a technical problem that requires a (simple and inexpensive) technical solution. Attempting to involve the courts will only harm the useful web.

* Source: My Ass

My job uses Codomo too, they are a pretty good deal, especially for a wildcard cert (if you're running an ASP, using hostnames like [clientname].domain.com, then this is what you want.

Protip: While you might be wondering about that $10/server charge there, know this: apache 1.3.x (and I suspect 2.x) CAN in fact have SSL vhosts all sharing an IP provided that they all use the same SSL key and SSL certificate Since they all use the same key, the encryption will be negotiated, then the actual vhost to use will be determined. Since the certs for all the vhosts are the same in the *.domain.com case, the certificate will always match the hostname.

Gotchas: If you add a new SSL vhost, you must stop the server completely, then restart it. If you try an apachectl graceful you will be told the server was gracefully restarted, when in fact it died a horrible death. Our logrotate scripts now issue "apachectl graceful; sleep 5; apachectl graceful; sleep 10; apachectl graceful", just to be sure. Second, if someone attempts to connect to https://afsdafsdf.domain.com/ and you do not have an afsdafsdf vhost defined, apache will connect the user to the first SSL vhost available for the purposes of SSL negotiation, then leave them on that vhost.

There have been some good answers so far:

    must include company name
    mandatory salary ranges
    must give desired fill date
    search jobs within given distance of arbitrary location

Someone said:

> find a way to penalize recruiters who post non-existant jobs
> for resume collection.

    The ideal job site would be symmetrical -- as much a repository
of talent as of jobs. With appropriate search capabilities over
resumes, listing a filled or fake job should be pointless.
    Like craigslist, it should be funded by employers rather than
applicants (that includes selling ads for us to watch). This
also makes life hard for recruiters.
    Posts could vanish after the "desired fill date". To encourage
applicants, fill dates could still not be set too far ahead.

I'd like to add:

    suggest-a-job feature, ala Amazon

        'people who applied to this job also applied for...'

        'most popular jobs among people like you...'

    don't be trendy

        please, god, no tags

        please god no social networking

    foster dialog about jobs

        "more like an interview"

        avoid structured resumes, structured job listings

            ie 'willing to travel = 75% of time'

        create a culture that discourages laundry lists

            To offset standard job description BS, require that posts
            show a small org tree centered around the job. Offer an
            ajax tree-constructor tool to make the trees' appearance
            uniform. Require at least two nodes, with a title and one-
            line description at each node. In addition, require all of
            an employer's jobs be shown in his trees, up to some large
            number (like 20). Nodes are clickable.

        every job gets a number

            differentiates multiple openings with the same title

            access via http://domain.com/number

        have posts solicit problem-solving

            'We're building the world's best ___ system, and we plan to
            dedicate a person just to do testing of its ___ function.
            How would you do this? Is this really a full-time job?'

        replies

            visible reply rate for each position

                'BetterWidgets has replied to 82 of 1005 responses about
                this job, and 390 of 24,000 responses about all of their
                jobs since October 2004.'

This is not new. This is why IE stopped supporting direct login from the url an year or so back:

http://www.domain.com/

Phishers were using it to fake legitimate domain names:

http://www.microsoft.com?sid=2149wef07wefewf5e4f9f 8f6ewf68002@123.234.324.123/ (i.e. notice the true address is the IP in the end).

Phishers use everything they can get their hands on, it's not as if they're afraid of braking the law :)

Hyperlinking:
Domain.com

With a hyperlink, the owner of a site acknowledges Domain.com as the creator of content, and links to the site to show people its content.

Hotlinking:

With hotlinking, the visitor never knows that domain.com is the provider of the image used. Domain.com gets no exposure, has no opportunity to generate revenue, and has to foot a bill for bandwidth.

A few posters have mentioned that the game authors email and url were on the front of the game, but that is honestly irrelevant. Would Fudruckers have linked to him if he did not have the URL on his game? Also, if Fudruckers would have linked to an HTML page on his site, he would have had an opportunity to place banner ads on his page to generate some revenue. By displaying the game directly, only 1% of the visitors might actually click that link, which gives him less of an opportunity to generate revenue.

Nobody has the right to hotlink to content. Yes, there are ways to block hotlinking, but a webmaster should not be obligated to prevent people from doing so. If I leave my house unlocked, that does not give the public the right to walk in.

...if anyone has any information, please contact gefiltefish11@domain.com

;-)

[For the sarcasm-impared or clueless newbies: /. is
one of the most often-harvested places outside of usenet]

.....you know, the only way you can have a url in your message/sig and have it not show the trailing is if you are a moderator. (update...now the sig is missing?...hmmmmm)

Mr. Ricard (user #16563) is actually one of the locals....and that mail is clearly a flame/troll...anti-ms at it's best, I'd say, since the sig below is the message and the message above is superfluous.

P.S. When you guys fill out forms asking for an e-mail address, PLEASE PLEASE PLEASE do not use domains like that. Someone owns them. Use "domain.com" or "example.com" instead, which will never resolve to anything. "your.org" gets more spam than you could possibly imagine.