Skip to content

Throw an exception before invalid response is parsed by getResponse() #1022

wants to merge 6 commits into from

4 participants


to test: JHttpFactory::getHttp()->head('http://blah')

Parsing invalid response (false, "") throws PHP errors as getResponse() assumes $content is consists headers and content.


In case of JHttpTransportStream,
PHP shows a Warning:
Warning: fopen($invaliduri) failed to open stream: HTTP request failed! in ~libraries\joomla\http\transport\stream.php on line 125

But I'm not sure if it's the right thing to supress the errors

As I'm thinking about it, fopen should supress any PHP warnings.
Typical scenario may be when the response (after processing) is going to be output as JSON. Any PHP warnings are then appended to the response body, deforming the JSON output.

The check for no HTTP response that I added is supposed to handle it anyway

If the open fails, an error of level E_WARNING is generated. You may use @ to suppress this warning.


There is 1 error in Unit test ( but seems like it's triggered by something strange outside this PR

Does this PR have any chance to be merged? There are few other issues in JHttp package but I decided to wait so this one can be still merged

piotr-cz commented Aug 7, 2012

JHttpTransportCurl fixed by #1438

pasamio commented Aug 8, 2012

You'll need to update to master because of the curl changes and would you mind putting in some code to check $php_errormsg for the stream handler so that we can get some insight at least there why it failed?

@elinw elinw commented on the diff Aug 15, 2012
@@ -137,6 +137,12 @@ public function request($method, JUri $uri, $data = null, array $headers = null,
$content .= fgets($connection, 4096);
+ // Received empty response (invalid uri, connection reached timeout);
+ if ($content === "")
+ {
+ throw new RuntimeException('HTTP request failed');
+ }
return $this->getResponse($content);
elinw added a note Aug 15, 2012

What you are doing here is different than what I did in my pull request which relate to the warning from fsockopen() at line 256 similar to what you did with fopen() in stream.

piotr-cz added a note Aug 15, 2012

I've tested all transports against invalid url and var_dump'ed the result:

  • for socket it was: ""
  • for curl and stream: false

So I've checked for empty response in the request method to be able to throw an exception in about the same place as in other transports.

Probably emphasizing an convention may not be optimal here as every transport is different.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

@piotr-cz would you mind rebasing this so we can potentially getting it merged? I'm gonna want to give it a test drive for sure, but I'd love to have consistency here. Can you think of a way we might be able to test it?

Note: I'm closing this until it is mergeable again, not because I'm rejecting the work. Please re-open the request when you get it ready to go.

@LouisLandry LouisLandry closed this Oct 9, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.