From: regext <[email protected]> On Behalf Of Jasdip Singh Sent: Tuesday, April 4, 2023 11:38 AM To: Mario Loffredo <[email protected]>; Andrew Newton <[email protected]> Cc: [email protected] Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-reverse-search-20
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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 [SAH] Nit: as alluded to by Jasdip above, RFC 7231 has been obsoleted by RFC 9110. The 501 text is 9110 is consistent with 7231, but I don’t think it’s limited to an invalid method. If the operative text is “the server does not support the functionality required to fulfill the request”, the response can be returned for *any* condition in which the server does not support the functionality required to fulfill the request. It doesn’t say that “the server does not support the requested method”. I still believe that 501 would be the best response. Note that for a 405 response “The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods”. How would a client interpret that response when it sends a request using the GET or HEAD method, and it gets back a 405 response that includes GET and HEAD in the response’s Allow header field? That sounds very likely to be confusing. Scott
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
