I'm using a extension of my PHP website for SSO which uses guzzle. It gives this error when running it.
Fatal error: Uncaught GuzzleHttp\Exception\ConnectException: cURL error 35: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) in.....
When I went to the website mentioned in the error for error 35 it says:
CURLE_SSL_CONNECT_ERROR (35)
A problem occurred somewhere in the SSL/TLS handshake. You really want the error buffer and read
the message there as it pinpoints the problem slightly more. Could be certificates (file formats, paths,
permissions), passwords, and others.
Top of the website tells this.
No matter what, using the curl_easy_setopt option CURLOPT_ERRORBUFFER is a good idea as it will
give you a human readable error string that may offer more details about the cause of the error
than just the error code.
As mentioned in the website how do I use CURLOPT_ERRORBUFFER in guzzle.
Any answers are appreciated.
Please let me know what I should do.
Related
I am using GuzzleHttp to send post request to another project. But when I have error I can't see all error it is always truncated.
Can anyone know how to remove the (truncated...) so that I can fully see the error?
GuzzleHttp\Exception\ServerException
Server error: POST http://127.0.0.1:8000/api/api resulted in a 500 Internal Server Error response: <!doctype html> <!-- TypeError: Argument 1 passed to Illuminate\Database\Query\Builder::inser (truncated...)
The error is only truncated in the Guzzle Exception message. You find the error in full in the other projects' PHP error log if you enable error logging there -- and -- in the response body.
Right now you've enabled display errors (or you're displaying errors in some variant that inserts the message into a HTML comment), check error logging is enabled and locate the appropriate log file.
Alternatively you can configure Guzzle to not throw on "HTTP errors"[1], verify the response status is 500 and if so have the non-truncated information in the response body.
The truncation is only for convenience as exception messages often end up in some line of their own in the PHP error log (of the applications that don't catch it) and such lines have a common limit of 1024 bytes for portability reasons.
Most details of the error situation can only be available within the system (here: the HTTP server you send requests to) and if you want to obtain the least filtered information, always go towards the source. Don't look for things, just obtain them.
c.f. Catching exceptions from Guzzle for the version of the Guzzle API you have in use.
Enabled app insights on php project, it is working on host machine. However, during running the same code on local box getting following error: [seems some IIS config issue or update not sure]
Fatal error: Uncaught GuzzleHttp\Exception\RequestException: cURL error 0: The cURL request was retried 3 times and did not succeed. The most likely reason for the failure is that cURL was unable to rewind the body of the request and subsequent retries resulted in the same error. Turn on the debug option to see what went wrong. See https://bugs.php.net/bug.php?id=47204 for more information. (see http://curl.haxx.se/libcurl/c/libcurl-errors.html) in ....\vendor\guzzlehttp\guzzle\src\Handler\CurlFactory.php on line 186
and
Warning: curl_setopt_array(): Unable to create temporary file. in ....\vendor\guzzlehttp\guzzle\src\Handler\CurlFactory.php on line 56
Trace:
trace while running an application from IIS
check the plugins and look through the debug.log file in wp-content and most likely it is a plugin that is causing this issue. I found that Mailjet causes this issue when unconfigured. Simply activate the plugins found in the error log and this will help solve it. The Microsoft version of cURL in PHP will throw the error and the Linux variant will not.
I've prepared some scripts on my local, and everything works properly... but when I just upload all files on server, and run script I have following error:
*Fatal error: Uncaught ActiveCollab\SDK\Exceptions\CallFailed: Unknown SSL protocol error in connection to project.*****.com:443 in ......./activecollab/src/Connector.php:208........*
On server is php 7.1 , and cURL is also installed...
do you have any suggestions what could be a problem?
Thank you in advance!
ActiveCollab SDK uses cURL to execute HTTP requests. “Unknown SSL protocol error in connection” is error thrown by cURL, and there are plenty of articles online that offer advice how to troubleshoot it (for example: http://blog.techstacks.com/2010/03/3-common-causes-of-unknown-ssl-protocol-errors-with-curl.html). Just search for the error message up to the project.w-em.com ("Unknown SSL protocol error in connection to"), and you’ll find a lot of resources that cover this class of cURL errors.
Having the same problem while installing the latest Prestashop on my server. So as #Agnes Tom has recommended, I changed the define.inc.php file and this is the error it´s showing up:
Warning: session_start(): open(/var/php_sessions/sess_b3c24487f16e9dcc7ebe9b0897bee69f, O_RDWR) failed: No such file or directory (2)
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/install/classes/session.php on line 47 Notice: Use of undefined constant _NEW_COOKIE_KEY_ - assumed '_NEW_COOKIE_KEY_'
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/Cookie.php on line 79 Fatal error: Uncaught exception 'Defuse\Crypto\Exception\BadFormatException' with message 'Encoding::hexToBin() input is not a hex string.'
in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php:65 Stack trace:
#0 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php(164): Defuse\Crypto\Encoding::hexToBin('_NEW_COOKIE_KEY...')
#1 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Key.php(38): Defuse\Crypto\Encoding::loadBytesFromChecksummedAsciiSafeString('\xDE\xF0\x00\x00', '_NEW_COOKIE_KEY...')
#2 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/PhpEncryptionEngine.php(112): Defuse\Crypto\Key::loadFromAsciiSafeString('_NEW_COOKIE_KEY...')
#3 /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/classes/PhpEncryptionEngine.php(46): PhpEncryptionEngineCore::loadFromAsciiSafeString('_NEW_COOKIE_KEY...')
#4 /hermes/bosnaweb14a/b1 in /hermes/bosnaweb14a/b1900/ipw.danarostocom/public_html/zumashoes/vendor/defuse/php-encryption/src/Encoding.php on line 65
Warning: Unknown: open(/var/php_sessions/sess_b3c24487f16e9dcc7ebe9b0897bee69f, O_RDWR) failed: No such file or directory (2) in Unknown on line 0
Warning: Unknown: Failed to write session data (files).
Please verify that the current setting of session.save_path is correct (/var/php_sessions) in Unknown on line 0
Might anyone helping me to know how to solve this error??
Thank you for your time
It's throwing an error saying it can't find or write to '/var/php_sessions/'
Do you have full access to the server?
If so, check if that folder exists and if the user or web server has permission to write to it, or change in php.ini
session.save_path = "/var/php_sessions"
To something like :
session.save_path = "/home/user/sessions"
Again, must be an existing folder with read/write permissions for the user or web server (this depends if you run the web server as own user or as account user).
If it's a shared envoirement, you better contact you hosting provider. Some allow you to have a php.ini in your hosting root and you could use it to change the session.save_path, others ignore it.
How to recognize the Error 500
First, we need to go over the different ways you might see this error message on your computer. There are different forms of this message because each host/server is allowed to customize the way it’s displayed. Here are some common ways you might see this error.
“500 Internal Server Error”
“HTTP 500 – Internal Server Error”
“Internal Server Error”
“HTTP 500 Internal Error”
“500 Error”
“HTTP Error 500″
Most times you will see this message accompanied by various forms of this classic ambiguous line
“The server encountered an unexpected condition that prevented it from fulfilling the request by the client”
It’s important to note that this error can be shown on any browser and any operating system (sorry, but switching to the new Mac Pro will not solve this problem) Here is a screenshot of one of the ways this error might be displayed on your browser.
Internal error server
What is the 500 Error?
Put simply, the 500 error is the Web servers way of saying “Something went wrong but I can’t tell you what, sorry.” This is what we call a “server-side” error. That means that there is something wrong with the server who is hosting the website. It is an extremely general error usually caused by configuration issues with the websites programming, PHP or system permissions.
How Can I Troubleshoot?
Don’t fret; although this error message is absurdly vague, you still have ways to find more information. Web servers are almost always configured to hide specific error messages. If your PrestaShop store is suffering from this debilitating error, you can turn on PrestaShop’s Error Reporting from FTP or your hosting’s CPanel to get more details.
There are two ways to turn on Error Reporting in PrestaShop depending on what version you have.
For PrestaShop v1.4 through v1.5.2
Open config/config.inc.php
On or around line 29 you will find this line
#ini_set('display_errors', 'off');
Change that line to read
#ini_set('display_errors', 'on');
For PrestaShop v1.5.3+
Open config/defines.inc.php
On or around line 28 you will find this line
define('_PS_MODE_DEV_', false);
Change that line to read
define('_PS_MODE_DEV_', true);
Once you enable error reporting through your FTP or CPanel, you can navigate back to your PrestaShop’s front or back office and reproduce the error or issue you are having. For example, if you are not able to access your website because of the 500 error, you will need to turn on error reporting and refresh the page(s) that had the error. There will be additional information that you can use to investigate the problem.
Investigating the Error
Once you have the additional information, there are some standard ways to further investigate the error. First, let’s go over some the most common ways this problem is caused. Once we find the cause of this error, it is much easier to solve.
Permissions: Many times you will find that the permission setting on one of your folders is set incorrectly. It could be a simple fix as switching a file/folder permission from 777 to 755 or vice versa. In most cases permission sets of 777 are extremely unsafe and can allow even an amateur hacker to access your files and put malicious code in it. Make sure to check with your hosting provider for specific information about permissions set as some servers have different regulations.
Incorrectly configured .htaccess: Oftentimes you will receive an internal server error when the htaccess file is configured incorrectly. For PrestaShop purposes, the main culprits of the htaccess errors are “URL Rewrite” settings or Friendly URL enabling. The htaccess syntax is very strict so even one wrong character or command will cause the server to return an Internal Error 500. Make a backup of your htaccess and regenerate the htaccess file either through the back office or by toggling the Enable Friendly URL option.
Server timeout: Every server has their own timeout setting, which sets the time that any given script can run. If the function or script crosses that limit, you will receive an error 500. The most common scripts in PrestaShop that can take too long to load are CSV Imports, backups, translation loading, import/exports and thumbnail regeneration. Many times the server limit is 30 seconds, which is not long enough to run these scripts. You should contact your hosting provider and inquire about changing the limit, at least temporarily.
Now, if the problem is not solved by investigating these common causes, you should also take a look at the Apache and PHP Error logs. These are provided by your hosting provider but sometimes you will need to contact them directly in order to have access to these log files.
I am using an OAuth library to connect to my Etsy store (etsy.com) and try to retrieve some information regarding sold orders.
This is the library: https://github.com/Lusitanian/PHPoAuthLib/blob/master/examples/etsy.php
However, I keep getting an error after I "Allow Access". I receive a token but when I allow access the issue is happening.
Here is the full error:
Fatal error: Uncaught exception 'OAuth\Common\Http\Exception\TokenResponseException' with message 'file_get_contents(http://openapi.etsy.com/v2/private/users/__SELF__): failed to open stream: HTTP request failed!
HTTP/1.1 400 Bad Request ' in /hermes/bosoraweb013/b1151/ipg.tahara/APIs/PHPoAuthLib-master/src/OAuth/Common/Http/Client/StreamClient.php:70 Stack trace: #0 /hermes/bosoraweb013/b1151/ipg.tahara/APIs/PHPoAuthLib-master/src/OAuth/OAuth1/Service/AbstractService.php(137):
OAuth\Common\Http\Client\StreamClient->retrieveResponse(Object(OAuth\Common\Http\Uri\Uri), NULL, Array, 'GET') #1 /hermes/bosoraweb013/b1151/ipg.tahara/APIs/PHPoAuthLib-master/examples/etsy.php(47):
OAuth\OAuth1\Service\AbstractService->request('/private/users/...') #2 {main} thrown in /hermes/bosoraweb013/b1151/ipg.tahara/APIs/PHPoAuthLib-master/src/OAuth/Common/Http/Client/StreamClient.php on line 70
Would anyone have any input to identify what the issue is?
The error is telling you that the library was getting back a 400 error which means that the server does not like your request. If this is something that might happen more often than not then a try catch block is your friend if only to terminate gracefully and perhaps log the problem.
If this was me I would have the error, the request and the Library object print_r inside a tag or into a text document so I could get a better idea of what was going on.
I'd be wondering if this was an authentication issue, a need to use HTTPS rather than HTTP, a bug in the library, an end-point issue or just some bad data at some place or other. The more information you have and the more you can isolate and confirm as working the faster I could home in on the problem.
I wish you the best of luck debugging and tracing the fault. I know how insanely frustrating these things can be.