Page MenuHomePhabricator

Fix "AphrontRequest->getRequestURI()" for requests with "x[]=1" parameters in the URI
ClosedPublic

Authored by epriestley on Feb 12 2019, 1:42 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 24 2024, 7:50 AM
Unknown Object (File)
Feb 10 2024, 6:33 PM
Unknown Object (File)
Feb 4 2024, 9:09 AM
Unknown Object (File)
Jan 4 2024, 7:44 AM
Unknown Object (File)
Dec 25 2023, 2:13 AM
Unknown Object (File)
Dec 22 2023, 1:35 AM
Unknown Object (File)
Dec 16 2023, 2:54 PM
Unknown Object (File)
Nov 30 2023, 3:31 AM
Subscribers
None

Details

Summary

Ref T13250. See PHI1069. This is a small fix for getRequestURI() currently not working if the request includes "x[]=..." PHP-flavored array parameters, beacause they're parsed into arrays by $_GET and setQueryParams(...) no longer accepts nonscalars.

Instead, just parse the raw request URI.

Test Plan

Visited /search/hovercard/?phids[]=X, no more fatal. Dumped the resulting URI, saw it had the right value. Tried ?phids[]=x&x=1&x=1&x=1, saw the parameters correctly preserved.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Feb 12 2019, 6:49 PM

There's some small possibility that $_GET and REQUEST_URI do not agree in some environments and that this will create even more problems. However, they agree locally, and we already use REQUEST_URI in some other cases without issues, and I couldn't find any internet evidence that REQUEST_URI is suspect.

We do have some code to turn a bag of PHP-flavored parameters into a query string (AphrontRequest::flattenData()) so we could just flatten $_GET, but that code is pretty icky so I'm hoping we can get away without increasing our reliance on it.

This revision was automatically updated to reflect the committed changes.