You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Review 405 - Method not Allowed on multiple frameworks #12
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 CONNECT or TRACE are treated the same way as FOOBAR.
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 CONNECT actually allows connections, Upgrade header 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.
Activity
vladko312 commentedon Feb 12, 2026
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.
MDA2AV commentedon Feb 12, 2026
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.
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?
vladko312 commentedon Feb 12, 2026
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.MDA2AV commentedon Feb 12, 2026
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.