Is there a way I can configure the information that comes back from an http TRACE request? Or disable this method altogether? Security have raised that they don't want to see the allowed methods in the 'Allow' response header.
Example attached showing allowed http methods.
Hello scott-apitalent ,
The TRACE method is already disabled, the 405 means method not allowed.
The return Allow header is as per RFC,
RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.
We have got the same issue from our security test. The 405 is correct, but the allow headers is filled with all the methods, even we do not allow these methods on the service. Could the allow header be filled with only the allowed methods?
Sounds like a defect, what version of gateway you have? Could you please open a support ticket ?
We use version 9.3. It is only the TRACE method which returns the header Allow: HEAD, DELETE, POST, GET, OPTIONS, PUT without validating the service. It does not use the global policies where we create the correct responses for the forbidden methods. I will open a support ticket to get more information and will post it here.
This is actually working as designed: The Gateway product is conforming to the RFC requirements to display the allowed methods when using the TRACE method when it is disabled (see response from Mark ). The methods being returned are the methods supported by the Gateway in general and not to the service level because the request never gets that far.
If you would like the option to modify the response (which would violate the RFC) or if you would like the product to return only the methods of the service attempted, this would be an enhancement request. Please submit an idea on our community page for this.
The RFC states that it must return the allowed methods, but I think it is not correct to return some generic values from a hidden device between the requester and the service. I think the current implementation is in violation with the (meaning of the) RFC.
I create a service on the gateway that only allows the POST method. The requester use a trace and gets a response that he cannot use the TRACE method but could use PUT, DELETE e.d., but when he tries this it gives him an exception. He should be confused.
Why is the TRACE method implemented in another way than the other methods?
Why do the other methods not conform the same RFC and return a 405 and must we build some custom handling to conform the RFC?