-
-
Notifications
You must be signed in to change notification settings - Fork 369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better support for querystrings (qs) #1437
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lovely.
Thank you. I got stuck with other things and it slipped my mind.
Im happy with the PR, I did two small comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you
Issue opened to address failing pipeline: crwlrsoft/query-string#4 |
@sladg Can I maybe help bringing it to Bref v2 as discussed in crwlrsoft/query-string#4? |
I've changed the target for this PR to master (now that v2 is released). @sladg could you rebase or merge master into your PR? That may make the build pass now. |
@mnapoli got it! thought that the change did not work at first, anyways, let me rebase and I will be back in a second |
@mnapoli rebased, we should be good to go :) |
@@ -4,7 +4,7 @@ | |||
"type": "project", | |||
"description": "Bref is a framework to write and deploy serverless PHP applications on AWS Lambda.", | |||
"homepage": "https://bref.sh", | |||
"keywords": ["bref", "serverless", "aws", "lambda", "faas"], | |||
"keywords": [ "bref", "serverless", "aws", "lambda", "faas" ], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated change shouldn't be included.
@mnapoli heya! checking if we can move forward with better qs support or there are some additional blockers :) thanks! |
All good, thank you for this beautiful work to everyone involved! |
Seems this PR introduced a bug for a rare edge case; if you have duplicate query string keys, only the final value will be passed through, these aren't treated as an array as expected. Just submitted a PR to resolve this here: |
Correct me if I'm wrong, but I think actually it didn't introduce that behavior? I think it already behaved that way in previous (1.x) versions of bref. I tried this, with both (v1.7 and v2.0): include 'vendor/autoload.php';
use Bref\Event\Http\HttpRequestEvent;
$requestEvent = new HttpRequestEvent([
'rawQueryString' => 'foo=bar&foo=baz',
'httpMethod' => 'GET',
'version' => '2.0',
]);
var_dump($requestEvent->getQueryParameters());
$requestEvent = new HttpRequestEvent([
'requestContext' => ['elb' => true, 'http' => ['method' => 'GET']],
'queryStringParameters' => [
'foo' => 'bar',
'foo' => 'baz',
],
]);
var_dump($requestEvent->getQueryParameters()); And in both cases the output is: array(1) {
["foo"]=>
string(3) "baz"
}
array(1) {
["foo"]=>
string(3) "baz"
} And looking at the bref source code, I think changing this behavior, would also require a change in bref, because:
So, in the second situation the incoming array would already have to be Further, I think it'd best to keep the current behavior and just use a query string like |
Seems you're right 👍
I don't believe that to be the case:
Completely agree the 'best' structure uses array notation[] on the parameters, but it's not uncommon to have query strings repeated. Even Google use it for Google Fonts for example when specifying multiple font families - for example: |
Yes, with API Gateway V2 I guess it would work with the changes from the PR, but I don't think it's a good idea if it works differently in different environments.
OK, I just read a bit further on https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html#multi-value-headers and in the comments in bref's source. So, when multi-value is enabled, it reads like the
So, maybe the solution in this case is to just create the crwlr |
Addition: I'll consider accepting your PR to the crwlr/query-string package @aran112000 👍🏻 have to take a closer look. |
I tried this route, API GW 2 doesn't provide |
Yes, that's why I then added, that I consider accepting your PR as well 👍🏻 I'm currently reviewing it...would you mind if I do some minor changes instead of requesting changes? |
Gotcha, sure thing. If I can help at all, just shout |
@mnapoli we changed the behavior in crwlr/query-string => crwlrsoft/query-string#5 |
@mnapoli OK, I found that the change introduced a new bug 🙈 already working on the fix. |
@mnapoli OK, the tests are succeeding again with crwlr/query-string 1.0.3 |
Awesome, thanks a lot @otsch! So anyone running |
@mnapoli Yes 👍🏻 and as 1.0.2 only was the latest version for about an hour, not a lot (if any) should have gotten that version. |
Support for getting array structure from duplicate query string keys without array syntax (brackets) was added in crwlr/query-string (v1.0.2) as requested in the discussion of this PR brefphp#1437. Example: foo=bar&foo=baz becomes ['foo' => ['bar', 'baz']] Add test case to make sure this actually works (and keeps working) in bref.
PR based on #1383. Credits to @Nyholm.
This pull requests removed reliance on build-in
parse_str
function in favour of @otsch's https://github.com/crwlrsoft/query-string.Allows to use dots and dashes in query parameters (won't covert them to underscores as
parse_str
does).Fixes #756.
Makes #1042 and #1383 redundant.
Extra reading on dealing with
parse_str
: