Page MenuHomePhabricator

PhpHttpRequest doesn't return response body if HTTP != 200
Closed, ResolvedPublic

Description

Translate extension needs the response body the detect the type of error with translation memory suggestions. It works with apparently.


Version: 1.18.x
Severity: normal

Details

Reference
bz27924

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:24 PM
bzimport set Reference to bz27924.
bzimport added a subscriber: Unknown Object (MLST).

I'm struggling to reproduce this.

<?php
header( "ERROR: I'm a teapot!", true, 418 );
echo 'teapot!';

See below. Output from execute is hacked in on the read....

$req = MWHttpRequest::factory( "http://192.168.0.195/teapot.php", $options );

$status = $req->execute();

teapot!

var_dump( $status );

object(Status)#14 (7) {

["ok"]=>
bool(false)
["value"]=>
int(100)
["successCount"]=>
int(0)
["failCount"]=>
int(0)
["success"]=>
array(0) {
}
["errors"]=>
array(1) {
  [0]=>
  array(3) {
    ["type"]=>
    string(5) "error"
    ["message"]=>
    string(15) "http-bad-status"
    ["params"]=>
    array(2) {
      [0]=>
      string(3) "418"
      [1]=>
      string(6) "unused"
    }
  }
}
["cleanCallback"]=>
bool(false)

}

var_dump( $req->getContent() );

string(7) "teapot!"

I also can not reproduce (tried with 404 page).

The Http::get wrapper won't return content for non-200 pages it seems, but MWHttpRequest::factory seems to work fine.

Created attachment 8299
patch to still get response body for non-200 response codes

After discussion on irc, turns out the issue is in PhpHttpRequest, not CurlHttpRequest.

Here's a patch that should in theory fix it, and does fix it for Nikerabbit, but doesn't work for me :(

I'm not entirely sure whats going on, but I get http-read-errors (aka $fh is null) for any request that isn't a 200.

Attached:

When I tried on TW, I got returned an instance of CurlHttpRequest

Weird.

Well, the Curl works now on twn, I don't know why it didn't earlier (I maybe the server needs multiple restarts for it to take action). I switched manually to php version to test the patch.

That's possible, I know the webservers need bouncing after PHP modules etc are added...

If it works, it might aswell be applied minus the var_dump() and closed...

Applied minus var_dump() in r84168