Hi all, while trying to assess a number of internal server errors, I came across the behavior that the SlingPostServlet is always returning a 500 if it has been invoked and wasn't able to write to the repository because of missing write permissions [2]. See https://issues.apache.org/jira/browse/SLING-9896 for a sample of such a stacktrace.
I don't think that this type of error qualifies for a HTTP statuscode 500, but it's rather an expected behavior, and therefor it should return with a 4xx statuscode. In the example mentioned above, the PersistenceException is thrown by the JcrResourceProvider [1], but this PersistenceException is generated on every RepositoryException. So technically, on the one hand side it could be caused by a defunct repository (and imo that would qualify for an internal server error) on the other hand side it might be caused just by missing permissions. Having that in mind, I would nevertheless argue to switch the behavior of the SlingPostServlet to return a 405 "Method not allowed" in the case of a PersistenceError [2]. It isn't 100% accurate either but still better than the internal server error. Making it more accurate would require major changes to the Sling-JCR implementation, and I am not sure if this improvement in semantics justifies it. All other exceptions are thandled the same way as before and continue to return an internal server error. WDYT? Jörg [1] https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/org.apache.sling.jcr.resource-3.0.22/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java#L476 [2] https://github.com/apache/sling-org-apache-sling-servlets-post/blob/master/src/main/java/org/apache/sling/servlets/post/impl/SlingPostServlet.java#L237 -- Cheers, Jörg Hoh, http://cqdump.wordpress.com Twitter: @joerghoh
