Change Details

Router::execute should call a new method Router::setBodyData, which should: - should throw for GET, HEAD, and DELETE if there is body data. Compare the code in Use the code from Validator::validateBody. - should throw for POST and PUT if there is body data but no content type. Be careful not to try and loat the entire body in order to check, since it may be very large. Use the code from Validator::validateBody. - should not throw for POST and PUT if there is no content type but also no body - call Handler::parseBodyData (if appropriate) - call RequestInterface::setParsedBody if Handler::parseBodyData returned an array. Note that we should throw a 415 exception if the handler doesn't support the given body type. Since Handler::parseBodyData can legitimately return null even for a supported type (if the handler wants to process it as a stream and avoid parsing), this means Handler::parseBodyData should be changed to throw on unsupported types. The only type that should be supported per default is application/json. It should however be easy for handlers to opt into supporting form data by calling $handler->getPostParams().

Router::execute should call a new method Router::setBodyData, which should: - should throw for GET, HEAD, and DELETE if there is body data. Compare the code in Use the code from Validator::validateBody. - should throw for POST and PUT if there is body data but no content type. Be careful not to try and loat the entire body in order to check, since it may be very large. Use the code from Validator::validateBody. - should not throw for POST and PUT if there is no content type but also no body - call Handler::parseBodyData (if appropriate) - call RequestInterface::setParsedBody if Handler::parseBodyData returned an array. Note that we should throw a 415 exception if the handler doesn't support the given body type. Since Handler::parseBodyData can legitimately return null even for a supported type (if the handler wants to process it as a stream and avoid parsing), this means Handler::parseBodyData should be changed to throw on unsupported types. The only type that should be supported per default is application/json. It should however be easy for handlers to opt into supporting form data by calling $handler->getPostParams(). To support the changes to Handler::parseBodyData, we will probably want to move some constants from Validator into RequestInterface, namely NO_BODY_METHODS, BODY_METHODS, and FORM_DATA_CONTENT_TYPES.

Router::execute should call a new method Router::setBodyData, which should: - should throw for GET, HEAD, and DELETE if there is body data. Compare the code in Use the code from Validator::validateBody. - should throw for POST and PUT if there is body data but no content type. Be careful not to try and loat the entire body in order to check, since it may be very large. Use the code from Validator::validateBody. - should not throw for POST and PUT if there is no content type but also no body - call Handler::parseBodyData (if appropriate) - call RequestInterface::setParsedBody if Handler::parseBodyData returned an array. Note that we should throw a 415 exception if the handler doesn't support the given body type. Since Handler::parseBodyData can legitimately return null even for a supported type (if the handler wants to process it as a stream and avoid parsing), this means Handler::parseBodyData should be changed to throw on unsupported types. The only type that should be supported per default is application/json. It should however be easy for handlers to opt into supporting form data by calling $handler->getPostParams(). To support the changes to Handler::parseBodyData, we will probably want to move some constants from Validator into RequestInterface, namely NO_BODY_METHODS, BODY_METHODS, and FORM_DATA_CONTENT_TYPES.