I did some more research on this. This has nothing to do with Spring or any of the Servlets, this is purely how Jetty handles TRACE requests. And it can be interpreted in different ways, but it could be argued that this is a proper behavior.
So demo app doesn't include any servlets from our side and is purely a set of client (http/js) examples. So some web servers probably intercept any TRACE calls and return error 403,405 or some 5xx status. Others first resolve the url fully and only if the URL is valid return TRACE disabled status. Jetty do this, so for example if you try
you'll get 404 as this URL doesn't exist. The url used in test
requires for Jetty to do a redirect to
and hence the 302 status code. If the security tool follow this new URL it will get 405 as expected.
There's even a blog post from a guy that's into this PCI compliant testings
and you can see that he discusses this case, so it's probably common.
We can raise issue against Jetty and I can even patch it if needed. but it'd be good to first communicate this with the customer,