Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect correct type on request when there are multiple media types mapped to the same content type #1335

Open
wants to merge 7 commits into
base: 1.2
Choose a base branch
from

Commits on Jul 19, 2018

  1. In the case where multiple types are registered to `lithium\net\http\…

    …Media` with
    
    the same content types, even when distinguished by `conditions`, an instance of
    `lithium\net\http\Request` will fail to determine the correct type to use to
    decode the request body. For example, if we register another type which use
    'application/json' as a content type like this:
    
    ```php
    use lithium\net\http\Media;
    
    Media::type('json_base64', ['application/json'], [
        'encode' => function ($data) {
            return base64_encode(json_encode($data));
        },
        'decode' => function ($data) {
            return json_decode(base64_decode($data), true);
        },
        'cast' => true,
        'conditions' => [
            'http:content_transfer_encoding' => 'base64'
        ]
    ]);
    ```
    
    In this case, a call to `Media::type('application/json')` will return an array
    like:
    
    ```php
    [
    	'json_base64',
    	'json'
    ]
    ```
    This case is not handled by `lithium\net\http\Message::type`, which causes
    `lithium\net\http\Request::$_type to be assigned as the content type of
    'application/json'.
    
    Futhermore, when `Request::body` is called to decode the request body, the
    Media class fails to find a handler for 'application/json' (it expects a short
    name like 'json').
    
    To fix this, `lithium\net\http\Message::type` must be extended by
    `lithium\net\http\Request`. In the case that the type is still a full content
    type like 'application/json', we can loop over each short name returned by
    `Media::type` and attempt to match the request like this:
    
    ```php
    public function type($type = null) {
    	$type = parent::type($type);
    	$media = $this->_classes['media'];
    	if (strpos($type, '/') !== false) {
    		$data = $media::type($type);
    		if (is_array($data) && !isset($data['content'])) {
    			foreach ($data as $short_type) {
    				$conf = $media::type($short_type);
    				if ($media::match($this, $conf)) {
    					$type = $short_type;
    					break;
    				}
    			}
    		}
    	}
    	return $this->_type = $type;
    }
    ```
    
    This will correctly determine a single short name to use for the type of the
    request data, and it can now correctly decode the request body.
    gscherer committed Jul 19, 2018
    Configuration menu
    Copy the full SHA
    98051c9 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    67448ea View commit details
    Browse the repository at this point in the history
  3. Configuration menu
    Copy the full SHA
    07d6206 View commit details
    Browse the repository at this point in the history
  4. Configuration menu
    Copy the full SHA
    b7a515f View commit details
    Browse the repository at this point in the history
  5. Clean up line length

    gscherer committed Jul 19, 2018
    Configuration menu
    Copy the full SHA
    875ea22 View commit details
    Browse the repository at this point in the history

Commits on Jul 20, 2018

  1. Move type override to `lithium\action\Request, since it depends on

    `lithium\net\http\Media::match`, which expects the Request::get() method to
    be available.
    gscherer committed Jul 20, 2018
    Configuration menu
    Copy the full SHA
    5ac829c View commit details
    Browse the repository at this point in the history

Commits on Jul 25, 2018

  1. Don't reset \lithium\net\http\Response::$_type from Content-Type head…

    …er if it is already set via configuration
    gscherer committed Jul 25, 2018
    Configuration menu
    Copy the full SHA
    56151e5 View commit details
    Browse the repository at this point in the history