enapps-enorman commented on pull request #6: URL: https://github.com/apache/sling-org-apache-sling-servlets-post/pull/6#issuecomment-730641622
> Hi @enapps-enorman > > I don't think that it makes sense to have this configurable. The HTTP standard gives clear recommendations what status code to use when, and I am just trying to fix current behavior, which I think is incorrect. And honestly I haven't payed much attention to backwards compatibility, because a 500 is always non-actionable from a client perspective. > Yes, but your conclusions about backward compatibility and standards doesn't change the fact that it returned 500 in the past and others may have written code to compensate for that. So perhaps it is worth considering? > And regarding extensibility: In that case I would introduce new subtypes of PersistenceException (or change the Exception hierarchy used here completely) and map them in the SlingPostServlet to a different status code. But right now I don't see the need for it. Well, I would say that is not extensible at all. A custom implementation should not have to change the SlingPostServlet every time they start using a new type of exception. Especially for exception types that are not open sourced and cleared to be included in sling. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
