haircut

'tis the season to get annoyed

Et tu, ThinkGeek? Like most of the sites I register for that actually support it, I registered for this one using an email address with a plus-sign in it[1]. Today, attempting to do a little Christmas Shopping, I noticed that the email field on the shipping address was empty, and filled in the exact same address as I'd registered with. And the site not only told me it looked incorrect, but the text of the error suggested that I could go ahead with it anyway, except there was no way to do that. On top of this, my phone number, which, being an international number, I also helpfully added a plus-sign to, had said plus-sign dutifully replaced with a space[2]. Which is the only reason I can think of that my payment was declined when I got to the checkout; I checked every other single bit of information, and it was all correct. I wound up paying via Paypal, and sending the ThinkGeek folks a little friendly feedback suggesting they fix this mess.

[1] For those of you who haven't seen this before, it's a trick supported by some email systems that allows you to receive mail to your regular address, but also allows you to figure out where that mail came from. So if, for example, I'd registered on somesite.com using waider+somesite as the mailbox part of my address, and then I subsequently received spam from another source to waider+somesite, I'd have a good indication that somesite.com leaked my info to spammers. Of course, I'm mildly surprised that no spammers appear to try to fake this.

[2] This is old-school web stuff: once upon a time, you represented spaces in a data submitted to a web form by replacing them with plus-signs. This has various technical explanations, but ultimately it boils down to laziness on the part of the guys who developed the system. As soon as people figured out that, hey, this made it difficult to enter actual plus signs, a new means of submitting data was decided upon, but the old pluses-to-spaces thing remains in place for backward compatibility with, like, the 500 people who were using the web before it was determined that this was a bad idea. And this bad idea still trips people up, even big-name people who really should know better.

Comments

It never ceases to amaze me the frequency with which people write Yet Another Email Or Phone Validation routine when plenty of established, tested OSS packages out there to use.
See comment below from the ThinkGeek monkeys (publicity fixes bugs faster than bug reports...)

(Anonymous)

ThinkGeek monkey update

Greetings. I come bearing good checkout news. We caught your issue after @bosca fed this post into the Twitterverse this morning, and have just taken care of the plus sign problem.

The backstory: We updated our checkout process a few weeks ago with some new AJAX code that happened to be a bit buggy. It is now bug-free.

Thanks for the catch,

ThinkGeek Monkeys
@thinkgeek
"...a trick supported by some email systems..."

It's also required by the SMTP standard. Systems that don't honor it are broken from a standards perspective.
Accepting the plus sign as a valid email character is. Having a RFC (2)822 parser which can cope with it, written in Javascript or the back-end language of your choice, is an entirely separate issue. It's not the ThinkGeek mailer that doesn't cope, it's their front-end (see comment above from the monkeys themselves).
Yes, the issue you're kvetching about here is one of my ongoing peeves, too. I should write a list of all the stupid things Internet coders do because they don't read the fabulous documentation.

Just this morning I helped somebody figure out why their $UNRELEASED_PRODUCT takes so much goddamned longer (two orders of magnitude) to download $LARGE_FILESET from the Akamai servers when the thing is behind a particular DSL modem (in Ireland, naturally!), and the answer is that some routers ignore DNS queries with any kind of questions except those for A records. They even ignore PTR queries. And, there is code in various places (which I can't talk about) that serializes DNS queries one after the other until either they all fail or the first one succeeds.

What are these people doing on my planet?
To be honest, what annoys me most about the plus-is-space problem is that it's in the same bucket, more or less, as the spaces-vs.-tabs problem in Makefiles: it could have been fixed a long time ago by dropping support for the plainly broken behaviour, but (and I am assuming here) this was not done to avoid breaking the user experience for the miniscule userbase that existed at the time. Stupid, shortsighted, and stupid once again.
Grr, you found another one of my sore spots.

The problem with /usr/bin/make isn't that whitespace is syntax. There are many find languages, e.g. Python, Haskell, OMake, etc., where the whitespace-is-syntax thing is not a problem. The problem with /usr/bin/make is that the whitespace grammar is stupid and the proper way to fix it is to specify a lexical extension that allows an improved grammar to be used. Yet this still has not been done by the people who maintain the major /usr/bin/make implementations.

Stupid and short-sighted, followed by stupider compounded with stubborn. Grrr.
haircut

November 2011

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
27282930   

Tags

Powered by LiveJournal.com