Issues

ZF-1934: http client fails on redirects with malformed urls

Description

I have code failing with exception like this: Stack trace:

0 /home/kgrecki/ZendFramework-1.0.1/library/Zend/Uri/Http.php(528): Zend_Uri_Http->_parseQuery('source_id=a&ur...')

1 /home/kgrecki/ZendFramework-1.0.1/library/Zend/Http/Client.php(800): Zend_Uri_Http->setQuery('source_id=a&ur...')

2 /home/tests/Case/Abstract.php(84): Zend_Http_Client->request()

I use http client for functional testing, grabbing requests from apache log and comparing responses. The problem is when a redirect happens and the destination url has malformed query string. It fails on validating the query string, probably because the url is not encoded. I think the client should behave the same as the browsers ale letting this url through. Currently I cannot test the response even when using 'maxredirects' => 0 because the exception is thrown before the request.

Comments

Assigned to Shahar

Can you paste here the URL that the client tries to redirect to? You can do that using such code:


// Set the first URI and all...

$client->setConfig(array('maxredirects' => 0));
$respons = $client->request(); 

echo $response->getHeadersAsString();

and paste the output here.

This snippet will not work as it throws an exception on first ->request(), but it can be tested by commenting out this line //$this->uri->setQuery($query); in Http/Client.php The sample url would look like http://localhost/redirect.php/… bar

It triggers 'Zend_Uri_Exception' with message 'Invalid URI supplied' if I try to connect to it directly using the client. I can understand why it's invalid, the thing is that it's being accepted by browsers. So I think the client should behave the same or at least have a configuration option that would allow this. Also the exception may be thrown prematurely as this url is never requested in my code if I use maxredirects' => 0 so maybe the url validation should be done later before the actual request to redirected url. Hope that helps.

Zend_Uri_Http was fixed to encode query parameters which are not valid.

Should be resolved by revision 6654. If you can verify that, it would help greatly.

Confirmed resolved by rev 6654 Thanks Shahar