|
7 | 7 |
|
8 | 8 | class ServerRequestTest extends ServerRequestIntegrationTest
|
9 | 9 | {
|
| 10 | + /** |
| 11 | + * Guzzle accepts more types for parsed body. |
| 12 | + * |
| 13 | + * ServerRequestInterface::withParsedBody says |
| 14 | + * > The data IS NOT REQUIRED to come from $_POST, but MUST be the results of |
| 15 | + * > deserializing the request body content. Deserialization/parsing returns |
| 16 | + * > structured data, and, as such, this method ONLY accepts arrays or objects, |
| 17 | + * > or a null value if nothing was available to parse. |
| 18 | + * > As an example, if content negotiation determines that the request data |
| 19 | + * > is a JSON payload, this method could be used to create a request |
| 20 | + * > instance with the deserialized parameters. |
| 21 | + * |
| 22 | + * A JSON body payload can also be a json string, a json int etc. So withParsedBody would also need to accept that as well. Those two sentences contradict each other. |
| 23 | + * According to a slack discussion, this was based on rfc4627 |
| 24 | + * > A JSON text is a serialized object or array. |
| 25 | + * |
| 26 | + * But that is outdated since since rfc7158 in 2013 which does not limit it to array or object anymore. See current https://tools.ietf.org/html/rfc8259 |
| 27 | + * |
| 28 | + * > A JSON text is a serialized value. Note that certain previous |
| 29 | + * > specifications of JSON constrained a JSON text to be an object or an |
| 30 | + * > array. |
| 31 | + */ |
| 32 | + protected $skippedTests = [ |
| 33 | + 'testGetParsedBodyInvalid' => 'more types are accepted per rfc7158', |
| 34 | + ]; |
| 35 | + |
10 | 36 | public function createSubject()
|
11 | 37 | {
|
12 | 38 | return new ServerRequest('GET', '/', [], null, '1.1', $_SERVER);
|
|
0 commit comments