CRM-19058 (Discuss) Add Civi::request() facade based on Symfony HttpFoundation

[totten]

This provides a Symfony-style $request object, which includes
ParameterBags for various inputs (GET/POST/COOKIE) along with
various helpers for validation.

Note: I don't expect this to be a large patch, but it's one we may want
to think about carefully. A few issues/questions:

• Symfony Standard Edition provides a request-stack service instead of
  a single request service. This is useful when processing nested
  requests. Should we be doing that?
• Should we be thinking about the Response object at the same time?
• In a D8 runtime, there's already a request object floating around.
  How should it relate?
• How often does civicrm-core include overrides for fields in
  $_GET, $_REQUEST, $_POST? (My sense is not very often, with
  the exception of a special field like q.)

---

• CRM-19058: Add Civi::request\(\) facade based on Symfony HttpFoundation

[eileenmcnaughton]

One note - there is some funky handling in CRM_Utils_Request::getvalues for '&ampq' - which is 'q' mangled by payment processors & other external manglers. We do kinda need that since we can't control the url mangling they get up to

[totten]

(Aside: There's also http://www.php-fig.org/psr/psr-7/ , but the part Eileen was looking for -- e.g. query->getInt('fooId') -- is specifically not part of PSR-7.)

[xurizaemon]

I'd be interested to see where that funky &amp handling is really coming from / required ... According to CRM-18384 the origin of the problematic URLs was event dashboard + link shortening, in which case maybe we could have been best to address it there rather than in the request handler. (The ticket makes it sound like the order of query params was the issue, which makes the premise sound all the more suspect.)

Can we leave that special handling out to start with, or until we at least know what circumstances make it necessary?

[eileenmcnaughton]

One example of $amp handling in PaymentExpress - it insists on url encoding any parameters in the array - so it will hit civicrm/payment/ipn/5 on wordpress as &ampq=civicrm/payment/ipn/5

[eileenmcnaughton]

So, this is stale but that is easily fixed. I don't think it's good to keep pull requests open forever. There comes a point where they should be merged or closed with a link to the commit for future reference.

To articulate the issue we are trying to solve. We have the rather clunky CRM_Utils_System::retrieve() function with something more modern. This provides an option, although no examples on using it which would not encourage adoption.

My inclination is about 60% to close this & track on JIRA until interest arises again (possibly squashing into one commit so we can link to the commit which is more enduring than a closed PR)

[totten]

I'm inclined to close the PR but keep the JIRA issue (categorized as "Improvement/Trivial") with a link to the PR.

Considerations:

• In retrospect, I'm feeling that PSR-7 makes more sense for Civi than Symfony HTTP. The PSR spec ought to be more stable over time.
• We need clearer problem statement/examples for the issues involving URL-encoding and payment-processors.
• I have a gut-sense that 'request stacking' is actually a necessary concept.