I’ve been working for the scientists over at the North Atlantic Bloom 08 as part o the team making their collaboratory. This project has mostly been based on Drupal, which is a content management system (in the web sense, not the ECM sense) based largely on PHP.
One part of this is taking a lot of content over email — the scientists creating a lot of the content on the site are in the middle of the North Atlantic. Because of this, I’ve been using the drupal module mailhandler for a lot of things that would normally be done directly through the site.
Basically, changing the comparison from $data[0]=='taxonomy' to a case-insenstive comparison:
if ((0==strcasecmp($data[0],'taxonomy')) && !is_numeric($data[1][0])) {
allows users to send in messages and have their mostly unambiguous intention followed. This is, in general, a good thing, and reflects the general net protocol practice of “be conservative in what you send, be liberal in what you accept.’ This is a general guide to good behavior and successful implementation and is generally called the Robustness Principle. I advise everyone to check out RFC 1122, because it has many entertaining things to say about the nature of the Internet at the protocol level.
Anyway, so when you can actually figure out what the person meant to be doing, you should probably accept it. This is a generic problem that pops up every now and then with computers. Surprisingly often, it pops up with case sensitivity at the protocol level. Here’s another moment for me with that same issue from about 7 years ago in Apache SOAP:
I proposed changing it to:
for (int i = 0; i < pds.length; i++) { if (0 == propertyName.compareToIgnoreCase(pds[i].getName())) { return pds[i].getWriteMethod(); } }
from:
for (int i = 0; i < pds.length; i++) { if (propertyName.equals(pds[i].getName())) { return pds[i].getWriteMethod(); } }
This does more or less the same thing, but is in Java. This was a case where the apache implementation wasn't interoperating with the Microsoft implementation because the MSFT implementation had a different valid interpretation of the SOAP specification than the Apache server did. Both implementations had completely reasonable behavior, but when the MS SOAP implementation responded to Apache, it did so with its own capitalization semantics (based on COM -- PropertyName) instead of the Apache SOAP capitalization semantics (based on Java -- propertyName). So, this is an ongoing problem that keeps showing up again and again.
I appear to be destined to run into it and advocate for the robustness principle in every technology i use, apparently. Either that, or it's just a slow day and I'm rambling.