Hi, > > Section 4.6 of RFC 9205 provides guidance to on how specifications should use > HTTP status codes, and advises against being excessively specific about which > status codes to use, due to the fact that they are often generated by > components other than the application itself. > > Given that, 409 seems definitely wrong, so we decided to revert it. Remember > it was not itself the outcome of a WG discussion. >
section 4.6 of RFC 9025 also says: "Instead, applications using HTTP should define their errors to use the most applicable status code, making generous use of the general status codes (200, 400, and 500) when in doubt. “ To me this reads that you should first try to use a specific code like 409 and only when in doubt about what specific code is appropriate use a generic x00 code. > > NEW: > > Redirect requests for searches, where more than one object is > returned, and help queries, as described by [RFC9083], are not > supported. Servers MUST return a 4xx status for these requests. > > This would 400, 404, or similar, and is in keeping with the guidance in RFC > 9205. > i would not use 404, as the resource does exist, but the multiple objects are not supported. this is confusing for the client. but having a generic 400 might also be confusing for the client, because there is no explanation about what might be causing the problem? maybe something like rfc9457 could be used? - Maarten _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
