> > > > 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. > > > > > > > I rather suggest we define a parameter, which will be used as a flag - > > > for example :ignoreStatus - whether the real response code is expected > > > (such as 201, 404, etc.) or a 200 response containing the intended > > > response code. > > > > > > And I think the default behaviour (in the absence of this flag) is to > > > use the real response code and only send a 200 response (for iframe > > > support) in case of the flag being present and set. > > > > > i think it's the opposite (see below). that the normal case 1) is the > > most natural and this could not respond with 201, or something. > > > > there are 3 use cases of the post servlet: > > > > 1) Normal HTML forms that users fill in content they want to store in > > the repository. imo, this is mostly the case for normal apps like > > blogs, wiki, application forms, shopping carts, etc. > > > > I agree that (1) is the most likely use case, for (2) and (3) I think the > order is debatable. Haven't tried it but is it really a problem for the > browser if it receives a 201? What happens in that case? > > > > 2) Special HTML form handling in hidden frames that are used by > > frameworks that have 'dialogs'. > > 3) XHR requests for ajax apps > > > > the desired responses are quite different though: > > > > 1) wants a redirect to the edited or created content after the post. > > 2) wants a human/machine (browser) readable response. that's why we've > > chosen an XHTML response that can easily be accessed though the DOM in > > javascript. > > 3) wants probably a json response that easily can be transformed into > > an object structure in javascript. > > > > 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 that's even better. we once though about doing it like this, but i can't remember why we didn't.
> 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. true. -- toby
