[10.x] Enhance malformed request handling #50470
Closed
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.
Solves #50466.
This PR aims to have better handling of malformed requests; in particular those which throw exceptions when certain methods on the request are called, like
getMethod
with content as described in issue mentioned above.To Do:
SuspiciousOperationException
inRouteCollection
#50466RequestExceptionInterface
Implementation notes:
SuspiciousOperationException
toRequestExceptionInterface
, given that Symfony recommends this per documentation in this interface. This is a separate that can be removed if wanted, however it seems more accurate and should generally not make any difference for valid requests. No additional tests have been added for other possible exceptions as part of this broadening; this can be part of a follow-up issue/MR.CompiledRouteCollection
using a copy of theRequest
instance in the scope of thematch
method (due torequestWithoutTrailingSlash
call), thegetMethod
call is never called on the 'original' request within the route handling and thus causes an exception whenisMethod('HEAD')
is performed in the scope of preparing the error response. This is once again caught by the exception handler and then correctly rendered on the second attempt. Albeit technically a little ugly, this is probably not worth addressing further as the outcome is correct and these types of requests should be extremly rare anyways.Bad hostname provided
message seems to be based on this line, but given that the exception also happens on incorrect method values (see test), a generic message seems to be more appropriate.