Table of Contents
The Cost of Fixing Response Codes and Metadata
Back when the software was written, 18 years ago, the authors didn’t have a clue about how to build web software that would work in 2018. Consequently, the structure was very weird, and lacked the Request/Response model used in other frameworks. The Response, in particular, was bad: it didn’t really exist, except as a dictionary of values that were merged with the page rendering code, and an error message.
That’s not enough: you also need to send back information about the status of the page, and set the rel=canonical and noindex tags, and return error messages. You may need to redirect to another page. Moreover, I needed to be able to set these values both at the “top” or then entry point, early in the request, and also deep down inside the code. (This is why most current frameworks use the middleware or pipeline design pattern.)
I didn’t add a response object, but just hacked on an array to accept some values, and then, before rendering the whole page, checked the values, and copied them into global variables. It’s just as bad as it sounds.
Sometimes, there isn’t much to be done to fix the code.
The good news is that events in the calendar now have canonical URLs. Bad event_ids return appropriate HTTP response codes, and a noindex tag, so the error pages don’t get indexed.
There’s also a JSON copy of the event data, whic
h is nice to have.