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
F12188615: D20147.id48107.diff
Mon, Sep 18, 9:27 PM
F12177957: D20147.id.diff
Mon, Sep 11, 5:47 AM
F12156937: D20147.id.diff
Tue, Sep 5, 3:15 AM
F12152134: D20147.id48115.diff
Sun, Sep 3, 11:33 AM
F12139934: D20147.id48107.diff
Mon, Aug 28, 12:40 PM
Unknown Object (File)
Aug 15 2023, 5:30 PM
Unknown Object (File)
Jul 22 2023, 5:45 PM
Unknown Object (File)
Jul 16 2023, 2:38 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.