Hi Felix,
Am 29.04.2008 um 10:55 schrieb Felix Meschberger:
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.
So if I send the redirect flag with my XHR I would get the location
header, right?
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.
Too bad. It's an important issue.
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.
Will do.
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.
OK, maybe it is a bit much flexibility to define the response code you
want to receive and a flag for the special case is enough.
Regards,
Alex
