Problems

In the world of software development, there is always problems. For developers, we may have problems using a certain third party tool, in which maybe it has quite a few bugs or is not configured the way we want it too, because these tools are made by other humans after all. Sometimes the problem stems from the developer himself or herself, such as lacking the understanding of a certain concept or unable to utilize the tools they are using. I know how it feels when things just don’t go your way.

JSON License

For this week, Dr Shawn had set up an account where I could install and run my Wt server application on Aeste’s very own web server. He had also given me access to the actual web store, but it is still in demo mode, so that I could test my application when it interacts with the real store itself. I had no issues getting my project’s code in to the server space, but then the first problem of the week comes shortly after. A part of my application is dependent on the Poco library’s JSON module, where it is used to parse and extract data from the JSON sent by the webhook. Apparently, Poco’s JSON uses the infamous JSON license, in which it has a controversial morality clause:

The Software shall be used for Good, not Evil.

This results in some legal ambiguity because how do you measure what is considered Good or Evil. It also kinda goes against the free software philosophy in which there should be no restrictions on software. Because of this, Debian has considered this license to be non-free and refuses to package software using this license. Before this, I did not abstract the usage of Poco’s JSON API in my own separate class, hence I had to do quite a bit of changes to the code and cost myself some valuable time again. It would be much smarter to abstract usage of third party libraries in your own self-defined APIs, as we could change to different libraries without affecting the class interfaces. I learn to use that method now with Wt’s JSON module instead.

PHP cURL and Lighttpd

Now, as I was attempting to test my application with the store, another issue had rose. My application couldn’t receive the payload that the webhook delivers. I had never faced this problem before, so I was scratching my head real hard. When I couldn’t figure out the problem myself, I had to consult Dr Shawn’s wisdom and guidance once more. From looking at the webhook delivery logs, the server was actually giving a 417 Expectation Failed HTTP status code for each delivery. Initial thought was to think that the problem comes from my own Wt application, but as mentioned it did not receive anything hence it could not log anything useful. This time, however, my server application is being hosted by another web server, so for some reason that server could not fulfill the POST requests sent by the webhooks. In the end, Dr Shawn was able to identify the issue. The issue comes from the fact that the PHP cURL library used to send these POST requests has an Expect: 100-continue header in its request headers. This means that the request headers are send to the server first to see if it could fulfill the request, and once the server responds back with a 100 status code, the request body is finally send out. Aeste’s web server uses Lighttpd as its webserver-software, and it is a known issue for quite some time that it does not handle the Expect header properly. Thankfully, WordPress has a plugin that enables you to configure options for cURL. All Dr Shawn had to do is force cURL to to use HTTP version 1.0 instead of version 1.1, where the Expect header is not enforced, and voilà it worked!

I wish to talk more about the problems that I have faced this week, but then I would be writing a story and not a blog. However, this blog shows that every problem does have a solution to it. It just a matter of how and when it can be solved. I sincerely pray that there are no more problems like these for the rest of my journey in Aeste, although that probably won’t be the case. Problems will always come running to us no matter how much we try to avoid it like the plague.