Use cURL instead of file_get_contents

[MusikAnimal]

This is because file_get_contents is slower and can't handle as big of
responses.

Also ensure our response code is the same as WikiWho's

Bug: T231492

[samwilson]

Works in my (limited) testing.

It is returning Content-Type: application/json even for things like HTML 404 errors. That's not the fault of this patch, but now the response headers are available here maybe it should copy that the same way it does the response code? Hardly a big concern though.

[MusikAnimal]

It is returning Content-Type: application/json even for things like HTML 404 errors. That's not the fault of this patch, but now the response headers are available here maybe it should copy that the same way it does the response code? Hardly a big concern though.

Good point! I think I have this fixed. cURL apparently doesn't give us the full headers as an associative array or what have you, so I'm just copying over the content type, specifically (in addition to the response code).

This all makes me wonder if the proxying should be done entirely with Apache, but I suppose this will do for now.

[samwilson]

Works in my testing.

[samwilson]

I've also wondered about doing a webserver-only proxy, but it doesn't look like it's possible with a toolforge account; we'd need a VPS. So, if this works I think it's better to just stick with it: less to maintain.

[MusikAnimal]

I've also wondered about doing a webserver-only proxy, but it doesn't look like it's possible with a toolforge account; we'd need a VPS. So, if this works I think it's better to just stick with it: less to maintain.

We're actually using VPS now, https://wikiwho.wmflabs.org/ . I couldn't get it to work on Toolforge, but I think that was because it was using file_get_contents. So we could go back to Toolforge, I suppose.