[PSR-7] Clarify superglobal usage #354
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Updated docblocks for query, cookie, and file parameters to indicate that the data sources MAY come from superglobals, or MAY come from other sources, but MUST mimic the structure for the corresponding superglobal. - Clarified that when injecting query parameters manually from values parsed from the URI, the rules that PHP's parse_str() follows MUST be followed.
- Return values are stipulated to be arrays in all cases. - Body parameters stipulate only arrays as well, not objects, for consistent runtime behavior between implementations. - `s/PathParams/Attributes/`, per @simensen
philsturgeon
added a commit
that referenced
this pull request
Oct 16, 2014
[PSR-7] Clarify superglobal usage
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Per this thread:
getQueryParams()to indicate that the value MAY come from$_GET, but may come from other sources, but MUST follow the same structure as$_GET.(get|set)CookieParams()to indicate that the value MAY come from$_COOKIE, but may come from other sources, but MUST follow the same structure as$_COOKIE.getFileParams()to indicate that the value MAY come from$_FILES, but may come from other sources, but MUST follow the same structure as$_FILES.Per this thread:
getQueryParams()to indicate that if the value injected is from the URI, the same rules that PHP'sparse_str()would use should be followed when dealing with duplicate query parameters and nested values.Per this thread:
(get|set)BodyParams()to ONLY use arrays, not objects. This means that you can only inject deserialized body parameters IF they can be coerced to an array. Note: you can get creative with this, and do something like$request->setBodyParams([ 'payload' => $anObject ]);. The point is having a consistent mechanism.IncomingRequestInterfaceto stipulate that arrays ONLY are accepted or returned; again, this is for consistency of implementation.(get|set)PathParams()to(get|set)Attributes(), per a suggestion from @simensen; the docblock was updated to indicate "attributes derived from the request."