Hi, Am Dienstag, den 29.04.2008, 15:47 +0200 schrieb Alexander Saar: > >>> and there will be another request parameter > >>> which allows to override the response code for special case handling > >>> like hidden iframes in forms. This parameter could be named > >>> sling:post:responseCodeOverride and the value could be the response > >>> code that should be used. If the parameter is not present the real > >>> response code will be send. > > and what do you do if you create and modify and delete several > > resources at the same time? what response code do you send? > > OK, that's indeed a problem I which I have not considered so far.
As I said, is this an issue with your Ajax use case ? You should do one-operation per request there to have better control anyway. > > > > we could include a flag that indicates the desired response: > > :responseType="xml" > > :responseType="json" > > > > where "xml" is the default and always responds with a 200. > > where "json" is a json representation of the response and also uses > > the correct response codes. > > What about using extensions to specify the desired behaviour? > > This could look as follows: > > POST to /foo -> 200 OK and a XHTML representation > POST to /foo.html -> 200 OK and a XHTML representation > POST to /foo.xml -> correct response codes and a XML > representation > POST to /foo.json -> correct response codes and a JSON representation What is the exact requirement and problem you want to solve with this ? In cases (1) and (2) we have the full information required. For use case (3) - Ajax - one operation at a time should be executed and thus status codes should be sufficient. If you need more inforamtion, I suggest you have XHR parse the XHTML (which is XML) response and access the DOM. > For the first case I'm unsure if it would be better to send correct > response codes, header fields and a XHTML. Changing the behaviour here > would break existing clients and thus all of them must be changed. The first case - direct user form submission - is generally submitted with a redirect request (in case of success). In case of failure, the XHTML is sent with status 200 (yes!). The problem is - as Toby said - with those browsers which pretend to be more intelligent than their users (and those users not disabling this behaviour). Regards Felix
