Page MenuHomePhabricator

Huge increase in cache_upload 404s due to buggy client-side code from graphiq.com
Closed, ResolvedPublic

Description

We've noticed a very significant increase in 404s on cache_upload starting on 2016-11-22.

The requested file is https://upload.wikimedia.org/wikipedia/commons/8/80/KrisKobach.jpg, and from the referal we've found out that graphiq.com is responsible for those requests.

The reason for such a significant increase seems to be a bug in graphiq.com's javascript code:

<img class='ew-image ' src='https://upload.wikimedia.org/wikipedia/commons/thumb/8/80/KrisKobach.jpg/250px-KrisKobach.jpg' width='180px' height=180px onerror='if(this.errr){$(this).remove();}this.errr=1;this.src="https://upload.wikimedia.org/wikipedia/commons/8/80/KrisKobach.jpg";'/>

Neither of the two URLs in the snippet above can be found on upload, resulting in a endless attempt to load the second one.

We might want to deploy a workaround (eg: returning 401s instead of 404s for such requests) in case the situation gets worse.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
ema triaged this task as Medium priority.Nov 23 2016, 10:42 AM

Change 323135 had a related patch set uploaded (by Ema):
cache_upload: stop graphiq.com buggy javascript

https://gerrit.wikimedia.org/r/323135

Leaving this ticket open though given that they still haven't fixed the javascript bug. The decrease in 404s is probably due to the fact that people are not opening the Kris Kobach page as much as they did last week apparently.

ema claimed this task.

404 rate back to normal, closing.

Change 323135 abandoned by Ema:
cache_upload: stop graphiq.com buggy javascript

Reason:
graphiq.com's bug seems fixed, 404 rate back to normal. Abandoning.

https://gerrit.wikimedia.org/r/323135