Hi Alex, Am Dienstag, den 29.04.2008, 10:17 +0200 schrieb Alexander Saar: > Hi all, > I tried to create nodes with random names using Sling Post Servlet and > XHR, but I always receive responses with status code 200 and not 201 > as expected.
Yes, because currently the SlingPostServlet calls the HtmlResponse.send method with a "setStatus" flag of false, thus the response status is always set to 200 and the actual status code is in the HTML response. > Also the Location header is missing in the response. This header is only set for a redirect after the post. > Lars > pointed me to the discussion around this issues in [1]. But I'm > wondering if there is a consensus on how to solve this? Discussion stopped, actually. > In my eyes > parsing a XML files to find out what happened is a "no go", because > this is not standardized in HTTP (which is the interface contract we > are using here) and it is not funny to deal with this in client side > JS. On the other hand normal form posts and XHR requests are likely to > occur more frequently than hidden iframes. Depends on the use case. I tend to agree, that normal XHR should be the majority. But reality shows that some use cases make heavy use of iframes .... > So I would suggest to implement the proposal from Felix, which means > the response always contains the correct response codes and header > fields (like Location) The Location header seems to in fact not be set for a content creation request. I agree, that this is a bug in the SlingPostServlet. Could you please create an issue for that one ? Thanks. > 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. 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. Regards Felix
