Aws-sdk-php: GuzzleHttp\Psr7\Uri class has deprecated "resolve" method

[karllhughes]

I updated GuzzleHttp/Psr7 to version 1.4.0 this week, and started seeing errors in my logs. It looks like the Uri::resolve() method has been deprecated in favor of UriResolver::resolve().

I'm happy to submit a PR to help fix this, but I don't know all the uses as I'm not very familiar with this library's internals. I found it in two classes:

• Aws\Api\Serializer\RestSerializer
• Aws\Sqs\ SqsClient

Does anyone know of other uses of this method? Is there any harm in upgrading to use the new method?

Thanks!

[fernandoval]

There is some bizarre dependence.

When updating guzzlehttp/psr7 to v1.4.0 (or when this occurs by updating guzzlehttp/guzzle to v6.2.3) the aws/aws-sdk-php is automaticaly downgraded to version 3.18.23 by Composer.

I has an application the use guzzle and I have a require to guzzlehttp/guzzle ^6.2.1 into my composer.json, before the require to aws-sdk-php. After running an update today, this started to happen.

I moved the require of aws-sdk-php to before of the require of the guzzle. Then the guzzlehttp/psr7 was downgraded to v1.3.1 and guzzlehttp/guzzle was downgraded to v6.2.2.

[jeskew]

@fernandoval Version 1.4.0 contained a potentially breaking change that would affect customers using S3 presigned posts. The SDK's dependency constraint allows for version 1.4.1.

@karllhughes Since UriResolver::resolve was only added in 1.4.0, a change to use it instead of Uri::resolve would need to check whether UriResolver::resolve exists before invoking it. Continuing to use Uri::resolve means we do not need to make that check at run time, so I'd be in favor of leaving those uses of Uri::resolve unchanged.

[fernandoval]

@jeskew I did not use Uri::resolve nor UriResolver::resolve in my project and I will not change the aws-sdk-php code.

I use only GuzzleHttp/Client to send a POST request (only).

My mistake was put the require to Guzzle before the require to AWS-SDK. I use the same dependency as guzzlehttp/guzzle that aws/aws-sdk-php.

This is not OK:

"require": {
        "guzzlehttp/guzzle": "^6.2.1",
        "aws/aws-sdk-php": "*"
}

This is OK:

"require": {
        "aws/aws-sdk-php": "*",
        "guzzlehttp/guzzle": "^6.2.1"
}

This is OK too:

"require": {
        "aws/aws-sdk-php": "*"
}

I put dependency on GuzzleHttp/Guzzle in my project, because if in future I stop to use the AWS SDK, I will have to remember to include the dependency back.

[xmeltrut]

I think this needs fixing, either by switching to the new UriResolver class or by updating the composer version tag to ensure it does not upgrade to Guzzle PSR-7 1.4.

You can use the workaround to re-order your dependencies. However, if AWS and Guzzle are brought in as a dependency, you do not have any control over it.

[Christoph-Harms]

When updating guzzlehttp/psr7 to v1.4.0 (or when this occurs by updating guzzlehttp/guzzle to v6.2.3) the aws/aws-sdk-php is automaticaly downgraded to version 3.18.23 by Composer.

I think this could also be caused by the issue pointed out in #1205.

[fernandoval]

After update to v3.23.2, the GuzzleHttp/Psr7 v1.4.1 was installed. Then deprecated error came back.

Now I had to include a request to v1.3.1 of the PSR7 in my composer.json file.

    "require": {
        "guzzlehttp/psr7": "1.3.1",
        "aws/aws-sdk-php": "*",
        "guzzlehttp/guzzle": "^6.2.1"
    }

[freefri]

I think the problem was introduced with this commit https://github.com/aws/aws-sdk-php/commit/62c6666292146e972fccc8711068d4dc5e83e56b by @jeskew I think guzzlehttp/psr7 it should still be ~1.3.1.
Was there any reason to make this change? Maybe we can revert this change?
In the meanwhile I'm adding it to my composer.json as @fernandoval has proposed, since this problem is breaking an important functionality in my system.

[jeskew]

Can I ask what's breaking? Using Uri::resolve in version 1.4.1 triggers a deprecation warning which is immediately silenced. It should only appear in logs if you have enabled scream mode and set error reporting to include E_USER_DEPRECATED-level notices.

[freefri]

Aha, so that's the trick. I've actually didn't have a close look to the problem. I've just got execution stopped in my php script. But now that you said so, I realize that we are handling errors and warnings as exceptions in a module of our system (this is a long story), so the problem is only in our system (that's explaining why people is not complaining). Since it is only a critical issue for me and nobody else, I will just force to keep guzzlehttp/psr7 1.3.1, and I will keep an eye in this issue in case the status is changing.

[fernandoval]

@jeskew ignore a "deprecated error" is not a solution. This is to hide the trash under de carpet.

In my application, this is not silenced with a single "E_USER_DEPRECATED -level notice" because the thrower error invokes an exception handler that stops the normal operation of the program.

[marklocker]

@jeskew What was the reason for specifically excluding 1.4.0, and not anything greater than that? I guess your reasoning was unrelated to the issue discussed here because I still get the deprecation warning with 1.4.1, which makes sense, they're not likely to randomly "un-deprecate" the method in future versions.

I also agree with @fernandoval, a deprecation message isn't something to ignore. I haven't had time to look unfortunately but surely it's an easy fix to switch to using the new method?

[jeskew]

@marklocker Version 1.4.0 contained a backwards-incompatible change that was reverted in 1.4.1 (see https://github.com/guzzle/psr7/issues/138 for context). Since UriResolver was only added in version 1.4.0, switching to the new method would mean dropping support for earlier versions of Guzzle's PSR7 library or introducing a shim method into the SDK.

The deprecation notice was added to inform consumers that Uri::resolve will be removed from version 2.0.0 of the library, so I think continuing to use the deprecated method is the best of the three available options. I'll open a PR on the PSR7 library to replace the call to trigger_error with a @deprecated annotation.

[dstevenson]

Just wanted to post here since this might help anyone else who may be wondering why they have an issue here.

If you utilize SplFileObject to handle your S3 objects via the StreamWrapper then you will get a RuntimeException when using the PSR7 library that triggers the E_USER_DEPRECATED warning.

SplFileObject internally replaces the error handler during its constructor and thus will throw a RuntimeException on the trigger_error.

I reported this behavior in the issue jeskew opened above. This isn't an issue with AWS library nor the PSR7 library, but since it's something we can't control in the PHP source, hopefully this will help convince them to not use trigger error in this way.

[bs-thomas]

@dstevenson I'm facing the exact issue you're talking about. I was wondering though, if there is any temporary workaround that works for the scenario. Thank you!

[jeskew]

The calls to trigger_error have been removed in version 1.4.2 of guzzlehttp/psr7, and the master branch of the SDK has been updated to require ^1.4.1 and to invoke UriResolver::resolve.

[dstevenson]

@jeskew thanks for your help in the battle getting this pushed through