"We have an internal website that shows, among other things, the daily availability of my coworkers for the next three months to help with scheduling, especially when planning vacations," writes Alexander.

"This vacation planner data is represented as a table. An image of a table to be more precise."

Displaying data as images is already a WTF. It's certainly not user friendly, it's definitely not accessible, and it makes one wonder whyyyy. That, however, is the least of the WTFs Alexander has in store for us.

First, the front-end sent its HTTP requests to a single end-point. Every request went to the same URL. When the user clicked the button to show the vacation planner, the browser would submit a form- yes a form, creating a body which looked like:

-----WebKitFormBoundary9lVf1utJmbYdQuZm
Content-Disposition: form-data; name="mode"

vacationplannerimage
------WebKitFormBoundary9lVf1utJmbYdQuZm
Content-Disposition: form-data; name="imgpath"

images/vacationplanner/July 1 2022.jpg
------WebKitFormBoundary9lVf1utJmbYdQuZm--

"Why," you might ask, "couldn't they just use an <img> tag pointing at the correct URL?" Then you remember what site you're reading this on, and realize there isn't a good answer to that question.

So, what does the API endpoint do with that request? It feeds it through a gigantic C# switch:

switch (mode)
{
	case "dosomething":
		Response.Write(DoSomething());
		break;
	case "dosomethingdifferent":
		Response.Write(DoSomethingDifferent());
		break;
	// ...more cases
	case "vacationplannerimage":
		Response.Write(VacationPlannerImage());
		break;
	// ...even more cases but no default case
}

Note the comment: there's no default case. So if a client sends an invalid request, we get back an empty response, not an error. So that's fun, and definitely not a recipe for future confusion. Especially because there's no documentation for what mode flags are valid- the only way to know is to read the gigantic switch block.

So how does the VacationPlannerImage get fetched?

public string VacationPlannerImage()
{
	string file = Server.MapPath(Request.Form["imgpath"]);
	try
	{
		if (File.Exists(file)) return $"{{\"isok\": true, \"message\": \"ok\", \"data\": {{\"idx\":{Request.Form["arridx"]}, \"img\":\"data:image/jpeg;charset=utf-8;base64,{Convert.ToBase64String(File.ReadAllBytes(file), Base64FormattingOptions.None)}\"}}}}";
		else return $"{{\"isok\": false, \"message\": \"No data to display!\"}}";

	}
	catch (Exception ex)
	{
		return $"{{\"isok\": false, \"message\": \"{ex.Message}\"}}";
	}

}

Ahh, now that's the stuff. Hand-crafted, artisinal JSON through string interpolation. The image served up as a field in the response, encoded in Base64, wrapped up in status fields which are handily re-inventing things that HTTP just already does for free.

Or, to let Alexander sum up:

Instead of a GET to an image URL, maybe handling security stuff in the server and returning an image this project takes a detour around every imaginable web standard to do its thing.

And this isn't some ancient, legacy project- the first commit to the project was in 2016.

Alexander closes:

Feel free to reach out if you have any questions or comforting words.

I have a lot of questions, but I don't think there are any good answers. As for comforting words, I don't think there are any that are sufficient.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!