Repository navigation
Review 405 - Method not Allowed on multiple frameworks #12
Description
Activity
Also, it seems like there should be some notes about configuration used.
For example, by default Flask restricts methods to a whitelist, only allowing GET, HEAD and OPTIONS. This limits the testing of request smuggling, as POST requests are rejected. The configuration I suggested is ideal for testing request parsing, as it accepts arbitrary methods, but it also compromises tests for method support. With that comfiguration, it is possible to test how Flask handles lowercase or other malformed methods, but
CONNECTorTRACEare treated the same way asFOOBAR.Also, it might be interesting to check for actual behavior, to know where dangerous features are supported and where they are just ignored, as well as to see specific implementation details, like header priority.
Currently only one scored test METHOD-CONNECT is an issue because as you mentioned some servers will accept it due to configuration, METHOD-TRACE and METHOD-CASE (small get) are not scored, to help this issue maybe improving visibility of the used configuration on the results website could help and have more than one configuration per framework.
Also, it might be interesting to check for actual behavior, to know where dangerous features are supported and where they are just ignored, as well as to see specific implementation details, like header priority.
This would be following up on tests with both CL and TE on 2xx cases and see which one was used for example? Also double CL or even check in cases where TRACE is accepted what exactly was returned?
Also, it might be interesting to check for actual behavior, to know where dangerous features are supported and where they are just ignored, as well as to see specific implementation details, like header priority.
This would be following up on tests with both CL and TE on 2xx cases and see which one was used for example? Also double CL or even check in cases where TRACE is accepted what exactly was returned?
Yes, if website supports CL+TE or double CL, it would be interesting to see what is actually being processed. Also, both CL+TE and TE+CL could be tested, as it might be based on the order rather than on the headers themselves.
Also, the system could check actual feature support. For example, check if
CONNECTactually allows connections,Upgradeheader actually causes an upgrade etc. Also it would be nice to check which malformed headers are processed and which are ignored or treated as different names.
I'll add something like this for all tests, hover to see the sent request and received response plus a behavior note on top.
For the CONNECT/Upgrade those might need to be created as a separate entity/test suite for the CONNECT at least as we likely need to configure the servers to work as proxies.
- linked a pull request that will close this issueAdd feature - ON mouse hover or click show a detailed info on request… #27
on Feb 12, 2026 - linked a pull request that will close this issueMake server configs acccessible in the website #28
on Feb 12, 2026 - pinned this issue
on Feb 12, 2026 - linked a pull request that will close this issueHeader normalization section #32
on Feb 13, 2026
Most frameworks were initially configured to accept a GET endpoint, later on when a POST test was added not all were properly updated.
Check all 405 and fix frameworks that are not configured properly.