Contact support

We reply by e-mail, usually within two days.

Google reCAPTCHA checks this submission against abuse; data is sent to Google. The script loads only when this form is opened.

← All posts

An endpoint that answers with nothing

· Lukas Wojcik

There is a path on this server that does nothing. A rewrite rule catches it and returns 204: no content, no body, no work. On 30 August it was called 1,000 times.

calls to /ssl/mt/ on 30 August, by counter twelve counters with the most calls site 1 163 site 2 89 site 3 60 site 4 56 site 5 55 site 6 42 site 7 21 site 8 17 site 9 14 site 10 13 site 11 12 site 12 9 1,000 calls from 45 counters and 240 addresses in one day none of them from a crawler — these are people, and the answer is empty

What it used to be

The path is /ssl/mt/, and mt is mouse tracking. In 2015 a script recorded where a visitor's pointer went and sent the coordinates here. That feature is gone. The rule that answers 204 is what is left of it, and it exists so that the script on those pages gets a valid answer instead of a 404 in the console.

The calls come from 45 different counters and 240 different addresses. Not one of them is a crawler. These are browsers, on real pages, running a script that has been calling a dead endpoint for years, and one site alone accounts for 163 of the thousand.

Nobody is going to fix this

The script lives in the HTML of somebody else's page. It was pasted there once, and there is no mechanism by which it will ever be pasted again. The same thing is true of the 2006 counter address, which still carries almost all of the counting traffic.

Which leaves two honest options. Keep answering 204 forever, which costs a rewrite rule and no PHP at all. Or stop answering, which turns a silent no-op into an error in 45 people's browsers, for no gain to anyone.

We keep answering. It is the cheapest possible response and it is invisible to the person whose page it is.

What it actually costs

The rule sits in .htaccess and never reaches PHP, so the cost is a pattern match per request. A thousand of those a day is not a number worth optimising; the reason to measure it was not the cost, it was to find out whether anything was still calling at all.

The answer — forty-five sites, none of them crawlers — is the part that changes how removals look. Switching a feature off does not stop the requests. It stops the answers.

What generalizes

A removed feature leaves two footprints: the code that got deleted, and the callers that cannot be reached. The first is in the repository and it is easy to be proud of. The second is only in the log, and it keeps arriving.

The useful question before removing anything that other people embedded is not «is this still used» but «who will still call it, and what will they get». Both halves are measurable, and only one of them is in the code.

Advertisement