period to underscore (non) conversion

[yivi]

I was just hit by an unexpected behaviour which broke an app for something I hadn's thought to test, in which an application worked differently from stock PHP when hosted over roadrunner.

According to PHP docs, periods/dots in request variables are silently converted to underscores by the engine.

Note:

Dots and spaces in variable names are converted to underscores. For example becomes $_REQUEST["a_b"].

To my surprise, this does not happen when running my application with RR.

E.g. submitting a POST request with an abc.qwer variable gets me this result with "plain" PHP:

But the same request, when served via RR:

Might be a small thing, but this was a webhook dealing with an external integration where I do not control the name of the variables, and started failing when my according to all my tests it should have been working fine. But of course, our functional tests are not served via RR.

Haven't found anything on the docs, but maybe I suck at searching.

I'm personally inclined to file this as a bug 🐛 , since I believe the behavior should be the same if the application was hosted on RR or not, otherwise I have to write logic dealing with both behaviors.

If not considered a bug, it should at least be documented more prominently somewhere on the docs.

Looking for feedback about this behavior.

Thanks, regards.

[rustatian]

Hey @yivi 👋🏻

RR doesn't touch the user data (or even read it, except to pass via IPC to the worker). I'm not a PHP dev, but according to your link, PHP is doing that substitution: to maintain compatibility with the deprecated register_globals feature..

This is not a bug, but we should have docs somewhere about that behavior, you're right. Thanks for pointing that out.

[yivi]

Yes, PHP does that substitution, but it does so in the PHP superglobals ($_REQEST, $_POST, $_GET).

Since when running RR the superglobals do not get created, but it looks like the request objects get instantiated directly, the end result is that a consumer application that expects to be able to do $request->request->get('some_var') suddently finds out that needs to write $request->request->get('some.var'), or worse (and more likely, IMO) write the application doing both things, to account for the application being run via RR or not.

I understand that RR currently does not touch user data, but I think that in this case maybe it should (if possible), to maintain compatibity with the "normal" PHP behaviour.

Documenting this would be a very good step forward, but I belive that if it would be possible to account for this conversion automatically, it would be a much better solution.

[rustatian]

Yeah, I understand your point, but we can't change the current behavior because it would be a BC and affect many people 😢.

But, still, you may create a feature request, discuss it in the ticket/our discord, and if I see considerable interest in that, for sure, I'll add the ability to choose the behavior.

If that is a blocker for you, you may fork the http plugin, change the std behavior and build your RR binary with Velox (video tutorial: https://youtu.be/h5PPvc_YOtg). If you have any problems during the build, feel free to ping me here or on our discord server.