GuzzleHttp Hangs When Using Localhost
Asked Answered
C

7

17

Here is a simple code snipplet but this just hangs and unresponsive.

    $httpClient = new GuzzleHttp\Client(); // version 6.x

    $headers = ['X-API-KEY' => '123456'];

    $request = $httpClient->request('GET', 'http://localhost:8000/BlogApiV1/BlogApi/blogs/', $headers);
    $response = $client->send($request, ['timeout' => 2]);

    echo $request->getStatusCode();
    echo $request->getHeader('content-type');
    echo $request->getBody();
    die();

Any pointers much appreciated. When I tried above with the github api using my username and password, I do get a 200 response and a lot of info.

Cormier answered 29/4, 2016 at 21:39 Comment(4)
What happens when you try http://localhost:8000/BlogApiV1/BlogApi/blogs/ in your browser?Adenovirus
@teko the browser keeps try to load something but never does.Cormier
So the problem is with the script located at http://localhost:8000/BlogApiV1/BlogApi/blogs not the snippet above.Adenovirus
The script that's at /blogs is fine and produces nicely formatted Json (works well with postman get, post, put, delete). The script above accessing it is the problem.Cormier
P
4

I was having the same issue. I got around it by defining base_uri as below.

$client = new \GuzzleHttp\Client([
    'base_uri' => 'http://localhost:8000',
    'defaults' => [
        'exceptions' => false
    ]
]);

$response = $client->get('/api/user/1');
Penile answered 18/9, 2017 at 16:37 Comment(1)
This is working fine but while using sendAsync with localhost URL it's not workingFlung
G
27

The issue is when using php artisan serve, it uses a PHP server which is single-threaded.

The web server runs only one single-threaded process, so PHP applications will stall if a request is blocked.

You can do this solution:

When making calls to itself the thread blocked waiting for its own reply. The solution is to either seperate the providing application and consuming application into their own instance or to run it on a multi-threaded webserver such as Apache or nginx.

Or if you are looking for a quick fix to test your updates - you can get this done by opening up two command prompts. The first would be running php artisan serve (locally my default port is 8000 and you would be running your site on http://localhost:8000). The second would run php artisan serve --port 8001.

Then you would update your post request to:

$request = $httpClient->request('GET', 'http://localhost:8001/BlogApiV1/BlogApi/blogs/', $headers);

This should help during your testing until you are able to put everything on server or a local virtual host.

Grow answered 29/11, 2019 at 4:2 Comment(4)
Yes, this is exactly what i'm facingSelenaselenate
Very nice solution, I did the same too.Roswell
Very well explained, I spend whole day to figure out whats wrong, I was thinking that there is some issue with curl but its as of single threaded serverCoact
This solved my issue! Thanks a lotVolcanology
A
4

Finally resolved it. Guzzle (or CURL to be specific) is denying the requests if you're running from non-standard ports.

Also, this appears to be random, sometime it works, sometime it doesn't. I moved to port 80 and Voila everything worked.

Airship answered 7/11, 2016 at 8:34 Comment(3)
Thanks for sharing above. I couldn't figure out what the problem was. I moved my entire site off my laptop to a web service provider. It works there but of course now I realize that is because obviously they use port 80. Locally, I was using port 8000. Thanks again!Cormier
For Laravel developers: I solved this problem using Laravel Valet. it seems that Guzzle don't like localhost.Allpowerful
@louisfischer: not localhost but multiple requests for a single-threaded web server are the problem. You still can use artisan, but you have to run another instance on another port e.g. with php artisan serve --port=8001 and tell Guzzle to use this base_uri (http://localhost:8001) instead (see https://mcmap.net/q/743802/-guzzle-cannot-make-get-request-to-the-localhost-port-80-8000-8080-etc).Octo
P
4

I was having the same issue. I got around it by defining base_uri as below.

$client = new \GuzzleHttp\Client([
    'base_uri' => 'http://localhost:8000',
    'defaults' => [
        'exceptions' => false
    ]
]);

$response = $client->get('/api/user/1');
Penile answered 18/9, 2017 at 16:37 Comment(1)
This is working fine but while using sendAsync with localhost URL it's not workingFlung
C
1

You could run another web server instance with another port and configure your application to use this base_uri when connecting to your API:

php artisan serve \ defaults to port 8000 \ in another console php artisan serve --port=8001

$client->request('GET', 'http://localhost:8001/api/tests')

Cordelier answered 28/4, 2022 at 10:53 Comment(0)
A
0

If the script at http://localhost:8000/BlogApiV1/BlogApi/blogs works well, my bet it that the X-API-KEY is not being sent.

If you look at the docs (http://docs.guzzlephp.org/en/latest/request-options.html#headers) it seems that you malformed the options array.

It should be

 $headers = ['headers' => ['X-API-KEY' => '123456']];
Adenovirus answered 30/4, 2016 at 7:29 Comment(4)
Tried above but same thing. Browser keeps trying to load. Apache becomes unresponsive.Cormier
So, moved my code to a FQD on a webserver and no problems! Received the json reply as expected. Therefore, it has something to do with localhost of :8000 on my Mac OSX. Any ideas?Cormier
Is there any known bug for guzzle on localhost? Exactly the same script works on my webserver under and fqd.Cormier
Have tried localhost and 127.0.0.1 with port 8000 and same results.Cormier
M
0

Setting connect_timeout to false worked for me on local development (Laravel), it just takes very long for the request to go through!

$client = new Client([
    'connect_timeout' => false,
    'timeout'         => 30.0, // set higher if timeout still happens
]);
Mujik answered 21/4, 2019 at 17:15 Comment(0)
S
0

This issue fixed in my end. Try this -> Configure your Laravel files into IIS or XAMPP server and then try to run via your local IP address like (192.168.X.X).

Sanbenito answered 25/6, 2019 at 11:8 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.