According to the specc, frameworks must accept URIs as defined in RFC 3986, which means they have to accept percent encoded URLs. The typical use case for this are special characters in file names. Handling this adds an additional layer of complexity that is usually skipped when the server recognizes there is no % in the URI.
So to force the frameworks to decode the incoming URL, I would suggest to add a static file with a non-ASCII character in it's name which is requested by the client with percent encoding applied.
For example, we can add a file named ~@file name.txt which translates to %7E%40file%20name.txt and is a valid file name on both Linux and Windows.
Include this file request in the validation as well as the benchmark itself to see whether there is a slow down in some frameworks.
According to the specc, frameworks must accept URIs as defined in RFC 3986, which means they have to accept percent encoded URLs. The typical use case for this are special characters in file names. Handling this adds an additional layer of complexity that is usually skipped when the server recognizes there is no
%in the URI.So to force the frameworks to decode the incoming URL, I would suggest to add a static file with a non-ASCII character in it's name which is requested by the client with percent encoding applied.
For example, we can add a file named
~@file name.txtwhich translates to%7E%40file%20name.txtand is a valid file name on both Linux and Windows.Include this file request in the validation as well as the benchmark itself to see whether there is a slow down in some frameworks.