500 Errors With In-app Browsers

In-app browsers do some things a little differently than normal browsers, and that might result in 500 errors on your server, among other interesting things.

639 views
d

By. Jacob

Edited: 2020-07-23 13:56

As a user, I find in-app browsers incredibly annoying, since they tend to limit the features that are otherwise available when using the native browser on your iPhone or Android device.

Now, normally in-app browsers should work very similar to the native browser on a device. It is, after all, the same web standards we are dealing with. But, recently I encountered a 500 error, otherwise known as Internal Server Error, while trying to open a link to my website inside of Facebook messenger; and as you may be aware, that indicates a problem on the server, and not a problem with the client software.

I was suspecting my site was having issues, so I immediately opened it in the native browser to see if the site was down — it was not! Since it would only happen when viewing the site from the in-app browser in Facebook Messenger, I was completely lost as to what was causing this problem.

Debugging the issue

Since the error was Internal Server Error, I could just investigate the server error logs. The problem is, I have a lot of visitors, so I needed to look for a request coming from my own IP address in order to filter out everything not related to the bug; this is easy with the grep command:

grep 'xxx.xxx.xxx.xxx' /var/log/apache2/mysite_com-error.log

Luckily, by executing this simple command in the terminal, I was able to track down the exact line in my PHP code that was causing the error. In my case, it turned out to be a failing SQL query; but why was it only triggered in the in-app browser?

To find the specific error message, I had to try and manually submit the same query, and this would result in a Data too long for column error:

MySQL ERROR 1406: Data too long for column

So, as it turns out, my problem was caused by a long user agent string. The maximum of length of the user agent column in the database was 255 characters, and the length was also not properly validated before inserting the data.

The user agent string in in-app browsers can be quite long, as it turns out. In the case of the in-app browsing in Facebook Messenger, the user agent string I was having issues with was 274 characters long.

The solution

To solve the problem I simply trimmed the user agent before inserting it into my request log table, and then I also increased the column width.

Truncating a user agent string before inserting it in the database can be done like this:

$user_agent ?? $_SERVER['HTTP_USER_AGENT'];
if (strlen($user_agent) > 400) {
  $user_agent = substr($user_agent,0,400);
}

Of course, you should also normalize a request log table so that values are not repeated too much. User agent strings can take up quite a bit of space if your tables are not normalized!

Tell us what you think:

  1. An in-dept look at the use of headings (h1-h6) and sections in HTML pages.
  2. Pagination can be a confusing thing to get right both practically and programmatically. I have put a lot of thought into this subject, and here I am giving you a few of the ideas I have been working with.
  3. The best way to deal with a trailing question mark is probably just to make it a bad request, because it is a very odd thing to find in a request URL.
  4. How to optimize image-loading and automatically include width and height attributes on img elements with PHP.
  5. HTTP headers are not case-sensitive, so we are free to convert them to all-lowercase in our applications.

More in: Web development