id	summary	reporter	owner	description	type	status	priority	milestone	component	resolution	keywords	cc
262	Mangle locker names that are invalid hostnames and MySQL usernames	andersk		"Certain locker names don’t entirely work with scripts:

 * #106: The `*.scripts.mit.edu` certificate doesn’t cover lockers with `.` in their name (and this is a fundamental limitation imposed by the RFC).
 * #171: Lockers with `_` in their name don’t always work since `_` is an invalid character in hostnames.  (In practice, many browsers accept internal `_`s but not an initial or final `_`.)
 * #176: MySQL limits usernames to 16 characters on both the server and the client, so lockers with longer names can’t use sql.mit.edu.

I proposed the following solution (see -c scripts -i 1621864 from 2011-06-09):

 1. Try to get a guarantee from accounts/Moira that locker names will remain unique under `lambda name: re.sub('[^A-Za-z0-9]', '-', name)[:16]`.
 2. Use `re.sub('[^A-Za-z0-9]', '-', name)` as your scripts vhost name.
 3. Use `re.sub('[^A-Za-z0-9]', '-', name)[:16]` as your sql username.

So 2.007 gets 2-007.scripts.mit.edu, mats_a gets mats-a.scripts.mit.edu, and stupidlylonglocker gets to use sql.mit.edu as stupidlylonglock.  We want a guarantee that nobody else gets lockers like 2_007 or mats.a or stupidlylonglockup.  (Note that 2007 is not a conflict, unlike with the current sql.mit.edu mangling scheme which simply deletes periods.)"	enhancement	new	major		internals