On Mon, Apr 3, 2023 at 7:57 AM Jasdip Singh <[email protected]><mailto:[email protected]> wrote:
What I gather from Andy’s suggestion is that 501 could also be returned for the reverse search queries that are not implemented (supported) on the server side. That said, your observation of applying HTTP 501 to unsupported request methods seems right. Not to muddle but wonder if we missed applying HTTP 501 correctly in RFC 9082? That is what I meant, but perhaps 405 is the more appropriate response. Kinda annoying that 9082 went through 2 IETF last calls and this wasn't caught. -andy AFAIU, RFC 7231 states that: - 404 must be returned to signal that the target resource is unknown to the server; The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists - 405 must be returned to signal that an HTTP method is unsupported on the target resource but known to the server; The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource - 501 must be returned to signal that an HTTP method is unknown to the server The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. Based on it, don't think rdap-reverse-search should add text to address these cases. As I wrote in my previous reply, the document had only to define the server operation when the client includes in the request an unsupported reverse search property or combination of reverse search properties. In this case, the server must return 400 (Bad Request). With regard to RFC 9082, my proposal is to remove the sentence in subject. [JS] If the intent vis-à-vis error codes is to differentiate a feature that is not implemented on the server side versus a bad request for an implemented feature, 400 (Bad Request) does not look like a good fit for the former since it is not a client error when a feature is not supported. Thanks to Mario, we learnt 501 (Not Implemented) is also not a good fit for the former since it is at the HTTP method level (GET in our case). That seems to leave 405 (Method Not Allowed) as a viable alternative to 501 since per RFC 9110, “The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.” Irrespective, 501 looks like an errata for Section 1 in RFC 9082. Thanks, Jasdip
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
