In our projects the index.php is typically in a src folder inside the task. We've set the handler as src/index.php and this successfully executes with the PHP layer.

However, when PHP's built-in web server is run and the router is supplied in a sub-directory (e.g. php -S 0:8080 src/index.php), the value of PHP_SELF becomes the path of the URL called, rather than /src/index.php/foo/bar etc.

If you run the code from the root (e.g. php -S 0:8080 index.php) this problem does not exist.

I'm not sure if this behaviour is intentional or not, and that ultimately it could be a PHP issue rather than the layer, but currently it breaks the behaviour of popular routing engines such as Slim as they attempt to strip PHP_SELF from the path before evaluating routes and, therefore, fall over when it's value is actually the path.

Just wondering if anyone else had any better insight on this problem?

On way it could be resolved, and how I'm tempted to fix it up in our codebase for now, is to tweak the behaviour of bootstrap so that it can detect a subdirectory in _HANDLER and change to that path to run the script from PWD.

Many libraries depend on this, and is usually part of a default PHP install.

It can be circumvented using the https://github.com/symfony/polyfill-mbstring library, but preferably it should be in by default.

And congrats and thanks for a nice PHP runtime lambda layer, very easy to use!

Hello, I have the following in php.ini:

extension=simplexml.so

However, it's not showing in phpinfo();.

To make sure php.ini is working, I tried loading another extension (e.g., extension=json.so), and it shows in phpinfo();

Any ideas how to make simplexml.so work? Thanks.

Note: I'm using layer:php73:2

Is version 5 of the layer expected to handle requests reaching lambda via the ALB? I keep getting 502 for such attempts. Cloud trail records a request but it appears that the error is generated in the layer, even before it reaches my application code. When I use application gateway, the request is making it all the way into the lambda function.

If you try and call $SERVER['HTTP_HOST'] to derive the requested host when running the Lambda function behind API Gateway or an Application Load Balancer, you receive localhost rather than the originating request's Host.

I presume this is because internally we're calling PHP's development HTTP server with a http://localhost/ URL.

This sort of comes back to a question in #11 about where the aim of the project lies in terms of PHP support in Lambda. If we aim to simulate an HTTP-driven hosting environment, we should fix this. If we're merely seeking to execute "any" PHP script in a Lambda fashion, then this doesn't necessarily need fixing. But then we should probably seek to expose the event object etc.?

I've presumed from the approach of writing HTTP headers etc. back out in the response, we're aiming for the HTTP-like execution of PHP within the function.

Hi, Testing in our environment we found a bug when sending the content-length Header via ALB. The curl call stucks which i think it's a bug: https://stackoverflow.com/questions/9340734/php-curl-data-not-posted-if-headers-are-set

I Managed to fix by making the header on-the fly with the actual sent body. For this i changed the order where we call the CURLOPT_HTTPHEADER to after the $body variable is defined.

I'm trying to add my own custom extensions. For example, I'm trying to add PDO. I've created a layer using this file: extensions-layer-1.zip

I've added extension=pdo.so to my php.ini file.

I'm loading the PDO extension layer after the PHP layer, but it's not showing up when I dump the list of enabled extensions.

I have no idea how to use your specified Docker image to build a php extension correctly, so I nabbed the pdo.so file from an EC2 instance I spun up. I suspect this is probably the problem, but I'm not sure where to go from here. Suggestions?

I've noticed that $_POST is not populated when sending fields (using HTTP POST) to a simple function given the sample template.

Related to #13, what is the specific aim of this project? If we are aiming to provide a fully functioning web-server, then this should be supported. If not, then this perhaps should be down to the implementing developer to expect some payload and parse it appropriately.

For example, developers from a REST background would expect a JSON body within a POST, but some PHP apps use application/x-www-form-urlencoded via HTML forms.

I see in bootstrap the body of the request is being sent to the PHP webserver, however, I can't see it with var_dump(file_get_contents('php://input')); - Any Ideas? We could then provide a snippet of processing for JSON or Form Data.

Whenever there are php warnings/notice/errors generated by the executing script/handler they are prepanded to the output generated by the script. These messages are formatted as html which really messes up the output (which at least in my case is json). Because that output is streamed first, the calls to the header() function generate their own warnings since that call may not follow actual output data. Furthermore, it appears that the returned html code in that case is always 200 ok, regardless of what the script actually returned.

This PR, fixes issue #38

In the end, it was a small fix. When building the php73.zip there were errors in installing remi repo, and it all came down to the order we installed epel and remi, reverting those instructions fixed the problem.

In term of adding the missing extensions required by Symfony 4, I only had to add php-xml and php-process to the list of php packages to be installed.

I tested and deployed the generated layer. phpinfo can be seen here (this page will be deleted once we merge this PR).

Side note: I did not explore, but I wonder why do we need to install httpd as part of building the image?! In my case, I'm using API Gateway to handle the requests and fire the lambda. I might be missing something but I do not think we need apache.

I'm using version 7.3 and tried adding mysqli.so extension to php.ini, but it simply won't load. On the other hand, pdo_mysql.so is loading correctly.

Any idea what may be wrong?

Regards,

Hi Guys I am trying to use php lambda layer to run my php script on lambda

Here's my python code

def lambda_handler(event, context):
    print(event["body"])
    result = subprocess.run(
        ['php', 'test.php', str(event['body'])],
        capture_output=False
    )
    print(result.stdout)
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

But I am getting below error when executing this function

php: error while loading shared libraries: libxml2.so.2: cannot open shared object file: No such file or directory

I used this layer to create a PHP lambda API. I then tried to create a PDO and connect it to a MySQL database. I got the following error "Uncaught PDOException: could not find driver in /var/task/index.php"

My php.ini file contains the following: extension=json.so extension=mysql.so extension=pdo_mysql.so extension=pdo.so extension=php_pdo_mysql.dll extension=pdo_mysql.dll

Here is my index.php code for creating the DB $conn = null;

$conn = new PDO('mysql:host=' . $host . ';dbname=' . $db_name, $username, $password); $conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

We have logic in our code that will write the response to S3 and redirect the client to the S3 URL if the content length is > 900,000. We have requests that are failing but yet that do not exceed the 900,000. I have added debug logs in the boostrap code as follows:

$totalResponseLength = strlen(print_r($response, true)); printf("Total response length: %d\n", $totalResponseLength);

For the request in question, the output was Total response length: 892878 which clearly is under 900,000 but yet when the lambda execution finishes, some 100K+ is added to the response length which fails the request with LambdaResponseTooLarge.

So my question is where is the 100K+ of addition bytes coming from

It implemented another bootstrap for other than web server purpose (to consume events of SQS, Kinesis, ..etc).

• Add make rule for building general event env.
• Add new bootstrap and php files to process general event.
• This runtime is naively ported ruby2.5 env.
• Change the handler specification rules as "FILENAME.METHOD" or "FILENAME.CLASS.METHOD" same as in other language.

I concern this may not be appropriate for PR, as it has largely fragmented the code. If you are interested in this and can accept it even partially, I will rework this PR.

If using this layer with an ELB, http header Content-Type is set to application/octet-stream instead of text/html; charset=UTF-8.

Bug or feature ? How can I change it ?