Task #86458

Merge PSR-7 request and _GET/_POST parameters

Added by Benni Mack 10 months ago. Updated 10 months ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
Link Handling, Site Handling & Routing
Target version:
Start date:
2018-09-29
Due date:
% Done:

100%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Sprint Focus:

Related issues

Related to TYPO3 Core - Bug #86731: Frontend RequestHandler can set $_POST to null Closed 2018-10-24

Associated revisions

Revision a4ae5ffe (diff)
Added by Benni Mack 10 months ago

[TASK] Merge PSR-7 request and _GET/_POST parameters

When hooks modify _GET or _POST parameters,
it is important that these changes reflect the PSR-7 request
for now, as long as TYPO3 access the _GET/_POST parameters
via GeneralUtility::_GP().

In order to move away from global access, we still want to avoid
places where it is unclear to use $_GET/$_POST vs.
$GLOBALS['TYPO3_REQUEST'] until all parts are completely
"global-scope free" for GET/POST parameters.

The change adds the initial GET/POST parameters to the
request object in the very first middleware of the frontend.

If these have been modified when the RequestHandler builds
up the content, they are added on top of the PSR-7 request object.

Additionally, if the PSR-7 request object has been modified,
these changes are put back in the global scope to reliably use
_GPmerged within Extbase and

Additionally, if _GET/_POST have been modified, a warning will
be shown in the TimeTracker to find out that there have been
modifications.

Until then, it is safe to continue to access _GET/_POST within
Hooks and Frontend, however it is highly discouraged to modify
_GET/_POST directly as this functionality will be breaking in TYPO3 v10.0.

Bottom line: This safety net can now trigger deprecation warnings
if _GET/_POST have been modified during PSR-15 middleware hooks.

Bottom line 2: If these have been modified, they are put inside the
current request object.

Bottom line 3: If the request object has been modified, global state
will be modified ONCE in one place to ensure that we work with
the same object during the request phase.

Bottom line 4: We cannot get away from the current state of
running a TYPO3 Frontend Request from another source, and
we try to maintain compatibilty for legacy scripts for now. However,
this will be breaking in TYPO3 v10.0.

Resolves: #86458
Releases: master
Change-Id: Ic8f4f123bb5ea0d660e500494cf06a965dea03c4
Reviewed-on: https://review.typo3.org/58443
Reviewed-by: Andreas Fernandez <>
Tested-by: TYPO3com <>
Reviewed-by: Oliver Hader <>
Tested-by: Oliver Hader <>
Reviewed-by: Frank Naegler <>
Tested-by: Frank Naegler <>

History

#1 Updated by Gerrit Code Review 10 months ago

  • Status changed from New to Under Review

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58443

#2 Updated by Gerrit Code Review 10 months ago

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58443

#3 Updated by Benni Mack 10 months ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#4 Updated by Benni Mack 10 months ago

  • Status changed from Resolved to Closed

#5 Updated by Daniel Goerz 9 months ago

  • Related to Bug #86731: Frontend RequestHandler can set $_POST to null added

Also available in: Atom PDF