Test the PHP action API with a bad hostname #102
Conversation
| return filtered; | ||
| } | ||
|
|
||
| function find(xs, predicate) { |
There was a problem hiding this comment.
AFAIK, Array.find() is part of Harmony, and is provided by es6-shim, with the difference being it returns the value, not the index in the array, so maybe we should use that one?
There was a problem hiding this comment.
Thanks for pointing that out - I have much to learn about the various JS std libs. I'll switch to that and toss out this ad-hoc implementation.
|
Rebased and switched to es6-shim's |
This revealed a problem in the forwarding a 'localhost' host header out to external Web services, which makes the PHP action API rather unhappy.
|
Reased on master. |
| @@ -17,7 +17,12 @@ module.exports = { | |||
| body.format = 'json'; | |||
| return restbase[req.method](req) | |||
| .then(function(res) { | |||
| if (res.status !== 200) { | |||
| if ( | |||
| res.status !== 200 | |||
There was a problem hiding this comment.
This would likely be simplified if we raised exceptions / rejected the promise like in preq.
There was a problem hiding this comment.
What about non-rejected statuses (e.g. 201, 30x)?
There was a problem hiding this comment.
Is there a legitimate case where the body is empty, but the return status is 200?
I'm actually not sure about res.body.query{,.pages} either. For example, this query still sets query and pages despite not matching any page.
There was a problem hiding this comment.
$ curl -s 'http://en.wikipedia.org/w/api.php?format=json&action=query' | python -mjson.tool
{
"warnings": {
"query": {
"*": "Formatting of continuation data will be changing soon. To continue using the current formatting, use the 'rawcontinue' parameter. To begin using the new format, pass an empty string for 'continue' in the initial query."
}
}
}
There was a problem hiding this comment.
Well, that's the reply to an empty query, which we (afaik) never send. Can this actually happen with queries we are sending?
There was a problem hiding this comment.
The action API wrapper is really a very embryonic internal thing right now. Once we start thinking about how we could integrate the PHP API into a more general REST API we'd probably want to give it a more systematic treatment.
In the meantime, internal uses that don't actually supply a proper query should probably fail loud & early, rather than just seeming to succeed without results. It did so far (by accessing something that wasn't defined), but we could make it more explicit with a check & an explicit throw.
There was a problem hiding this comment.
Cool, I'll make these cases result in errors.
There was a problem hiding this comment.
Does a 400 make sense for these cases?
There was a problem hiding this comment.
Hmm, maybe a 500 is better. We don't necessarily know that the request was poorly formatted -- all we know is that the PHP action API didn't give us back what we expect.
There was a problem hiding this comment.
Yeah. Anything that throws is good ;)
| @@ -272,5 +272,24 @@ util.inherits(HTTPError, Error); | |||
|
|
|||
| rbUtil.HTTPError = HTTPError; | |||
|
|
|||
| rbUtil.httpErrors = { | |||
| offline: new HTTPError({ | |||
There was a problem hiding this comment.
Minor: It might be more consistent to make both httpErrors functions.
Test the PHP action API with a bad hostname
This revealed a problem in the forwarding a 'localhost' host header
out to external Web services, which makes the PHP action API rather
unhappy.