enapps-enorman commented on pull request #6: URL: https://github.com/apache/sling-org-apache-sling-servlets-post/pull/6#issuecomment-730617491
> @enapps-enorman The explicit status you mentioned is in [1] and happens as a last step of handling. But this mechanism works only based on the instructions of the client. My intent is that I want to get rid of these ISEs irrespective of the useragents requests, and in my case the useragent is not aware that such a parameter actually exists. > > [1] https://github.com/apache/sling-org-apache-sling-servlets-post/blob/master/src/main/java/org/apache/sling/servlets/post/impl/SlingPostServlet.java#L396 Yes, I understood how that works. Maybe I didn't explain myself very well, but I was never suggesting that the existing/current user requests would require any changes to achieve the desired default behaviors. A reasonable default server side "exception -> status" mapping should work for most scenarios. I guess my thinking and suggestion had a couple of goals in mind: 1. A path for backward compatibility. Imagine if some hypothetical client already exists that expects and relies on a 500 status code for all errors. This is bad, but who can say what people would do. So a mechanism to remap the status codes via "configuration" back to 500 could give the client library author a workaround while their bad client library is updated to compensate for the new status codes. 2. A path for extensibility. Imagine some custom PostOperation component that throws some other family of exceptions that should be mapped to a specific status code. For example, perhaps some validation (400) or access (403) exceptions? It is easier to see it than explain it so I did a quick prototype of what I was suggesting in a fork at: https://github.com/enapps-enorman/sling-org-apache-sling-servlets-post/tree/improvement/SLING-9896-statuscode-mapping-for-client-errors ---------------------------------------------------------------- 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]
