Forums

Topic subject describes problem...

New django project, link to homepage show "Unhandled exception", to adminpanel: same exception.

Hi kernie_xvid -- is it a site hosted at kernie_xvid.pythonanywhere.com that's causing the problem? I ask because we recently upgraded to a new version of Django, and it looks like it refuses to host sites which have underscores in the domain name.

It that is the case, then the best solution is probably for us to change your username. Perhaps kerniexvid? Just a warning -- changing usernames is a rather slow manual process on our side, so you won't be able to log in for half an hour or so while we do it.

kerniexvid is ok, change it please

OK, the rename is under way. Please don't do anything on PythonAnywhere until you see another post here!

OK, your account has been renamed and all of your files and web applications have been moved over, along with your payment settings. It looks like that's fixed the problem with your new Django app.

However, your MySQL databases are still associated with the old version of your account. I can migrate them over, but first you need to set your password on the MySQL tab (that link will only work for you). If you don't need the DBs to be migrated, just let me know.

I dont need DB's, thanks.

OK, thanks for letting us know!

Hi, I created my account yesterday and I have the same problem. There's no information that I can't use underscores in the name. Can I ask for rename my account, unless you fix it soon?

Hi mat -- as you're on a free account, is there any chance you could sign up again as (say) matlewandowski? Then we can copy all of your files across. That's much faster than renaming an account.

(The reason I did the rename for kerniexvid is because it's not much faster when someone's a paying customer, as then we have to move all of the payment settings across, which is error-prone.)

I want to use my current name in future when the problem will fix up. At this moment I'll sign up again but on another name. I hope can I create next free account for my tests only? If that I'll manage my files manualy.

All we can really do to fix the problem is block usernames with underscores, which we will do for new users shortly.

The problem is that underscores are not actually valid in DNS hostnames. They do work on many platforms, but that's because those platforms aren't implementing DNS properly. Because of this, as of the most recent version of Django, the developers decided that any request that comes to Django with an underscore in the hostname will generate a low-level error; our system hides that error from visitors to the site, but logs it in the web app's error log file (you can see that from your web app tab).

OK, thanks for your help giles.

Interestingly the restriction on underscores isn't part of the DNS specification - see RFC 2181 section 11. The restriction has become embedded in so much software by now, however, that the point seems a little moot.

Hmm, according to Wikipedia (I know, I know) they're invalid in hostnames but are valid in "other DNS names". So I think that means that we shouldn't allow them anyway, though my understanding is a bit weak when it comes to whether or not username.pythonanywhere.com should strictly follow the spec for a hostname. But as you say, it's all moot now that Django's started restricting it.

I think Wikipedia's assessment is less of the letter of the standards and more of the pragmatics of what should and shouldn't be allowed (which is probably more useful, I'll grant you).

My understanding has always been that RFC 952 originally laid down the requirements for a hostname such that it consist of characters from [-A-Za-z0-9] where the first character must be a letter and the last a letter or digit. RFC 1123 §2.1 relaxed this restriction slightly such that the initial character could also be a digit - I always suspected this was due to pressure from 3Com, who wanted the 3com.com domain.

RFC 1035 §2.3.1 seems to specify that the entire domain name must consist of the same characters, but if you read the text it's a sort of "best practice" rather than a hard requirement. In principle, therefore, you're probably allowed to use underscores in domains, just not in the host portion - in practice, this isn't a good idea due to the issues this causes in various bits of software (for example, IE used to ignore cookies from domains with an underscore).

Then RFC 2181 §11 came along and clarified the fact that underscores are entirely permitted within the DNS standard. This is to say that DNS servers are obliged to accept values with underscores and not fail to load and serve a zone file so specified. This is essentially saying that DNS servers aren't allowed to enforce restrictions for specific client applications.

The upshot of all this is that platforms which use underscores in domain names are implementing the DNS standard properly. If they use them in hostnames, however, they are in breach of RFC 952 and RFC 1123, although strictly only if the underscore occurs in the host portion (there is some debate on this interpretation). In practice, anybody creating hostnames or domain names should always avoid the use of underscores if only to work around the many known issues in software with it.

Note that for non-hostname purposes, underscores are still allowed - or at least Amazon thinks so. They use CNAME records for DKIM (instead of the more typical TXT records, where underscores are definitely allowed). I'm not sure which specific RFC he's referring to which allows underscores, however.

I'd hoped that RFC 3492 (AKA Punycode) might have made things better, but as far as I'm aware this only provides the ability to include characters above ASCII 127 by providing a defined translation from them into valid ASCII. Still, it's progress to be able to display internationalized domain names, even if it's an ugly, awful hack just for the sake of not having to change every single piece of software on the Internet. Pah, people are so lazy.

Anyway, that's probably more than anybody ever wanted to know. (^_^)