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)
Sat, Jan 18, 10:33 AM
Unknown Object (File)
Fri, Jan 17, 8:05 AM
Unknown Object (File)
Sun, Jan 12, 2:41 PM
Unknown Object (File)
Sat, Jan 4, 5:17 PM
Unknown Object (File)
Tue, Dec 24, 8:19 PM
Unknown Object (File)
Dec 12 2024, 9:08 PM
Unknown Object (File)
Nov 26 2024, 10:57 PM
Unknown Object (File)
Nov 19 2024, 1:14 PM
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.