You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following code throws a Http\Exception stating that the HTTP request for SPARQL query failed, and doesn't return any information about the response:
$sparql = new EasyRdf\Sparql\Client('http://uri/returning/a/redirecting/response');
$sparql->query('...');
Expected behavior
When there is a 301/302/303/307/308 HTTP response to the query and the Location header is set, we could automatically try again the query with the new Location instead of imediatly throwing the error. We could easily keep in sight the previous automatic redirections in order to make sure there is no circular redirections and throw the Exception it happends.
It would be useful to return the response headers in the thrown exception to better identify the error and take the appropriate steps (this second option could also be useful when we have other HTTP errors such as 401 where the body of the response doesn't always carry as much information).
The text was updated successfully, but these errors were encountered:
Mostly handled by PR #379, as the PSR HTTP client provided by implementor can be configured with desidered behaviour (handle as many redirects as required, or just fail when a redirect is found).
Current behavior
The following code throws a Http\Exception stating that the HTTP request for SPARQL query failed, and doesn't return any information about the response:
Expected behavior
When there is a 301/302/303/307/308 HTTP response to the query and the Location header is set, we could automatically try again the query with the new Location instead of imediatly throwing the error. We could easily keep in sight the previous automatic redirections in order to make sure there is no circular redirections and throw the Exception it happends.
It would be useful to return the response headers in the thrown exception to better identify the error and take the appropriate steps (this second option could also be useful when we have other HTTP errors such as 401 where the body of the response doesn't always carry as much information).
The text was updated successfully, but these errors were encountered: