Hi, On 08.03.2010 11:26, Vidar Ramdal wrote: > On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <[email protected]> wrote: >> Hi, >> >> On 08.03.2010 09:08, Vidar Ramdal wrote: >>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <[email protected]> wrote: >>>> Finally, we implement the logic for choosing either sendHtml() or >>>> sendJson(), based on: >>>> 1. The format of the posted data - if JSON is posted (SLING-1172), >>>> return JSON, otherwise return HTML >>>> 2. The Accept HTTP header - if set to "application/json" return JSON, >>>> otherwise return HTML >>>> 3. Possibly also an :accept form field, with the same value as the >>>> HTTP header, in case it is proven that setting the HTTP header does >>>> not work in some browsers >>> >>> I have a patch for this ready at >>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12446912 >>> >>> Here's how it's implemented: >>> 1. A class JSONResponse which extends HtmlResponse (for backward >>> compatibility) >>> 2. A class MediaRangeList for parsing the HTTP Accept header >>> 3. A method SlingPostServlet.createHtmlResponse for determining which >>> format (HTML/JSON) to return to the client >>> >>> The JSON format is kept as close to the HTML format as possible. >>> >>> JSON is only returned if the client sends "application/json" in the >>> Accept header, with a greater preference than text/html. Also, the >>> Accept header can be simulated by a the :http-equiv-accept query >>> parameter. >>> I dropped the automatic return of JSON on JSON posts (SLING-1172) - I >>> think the client should specify application/json in Accept anyway, if >>> it wants JSON returned. >>> >>> WDYT? Is this a sensible way of implementing this? >> >> It hink this is basically a good idea. Esp. having the overwrite parameter. >> >> Though for symmetry with GET requests, where the .json extension ask for >> a JSON response, we might want to also support this for POST ... Don't >> have a very string preference, though. > > Yes, I think we have been discussing this before. The problem is, what > if you want to post to a JSON file (e.g. > http://localhost:8080/content/file.json)?
Hmm, what is the target resource's name ? Is it "/content/file" ? Then it is a .json request but you post to /content/file. Is it "/content/file.json" ? Then it is not a .json request because there is no request extension. > You probably want a JSON response in those cases too, but I fear this > could become inconsistent. > > Also, strictly speaking, the Accept header will probably say that the > client prefers a text/html response (which is what web browsers do as > default). So, to strictly comply with RFC 2616 [1], we should return > HTML when we're able to, and the client has not specified a preference > for something else. > > [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 But probably you are right. If we want to have JSON requests we are probably in more control over the request (app request or XHR request) than using a regular post and requiring the Accept header (or the overwrite parameter) might be correct). (in fact sending back JSON as a response to a .json request is already bending the standard because we are ignoring the Accept header altogether) Regards Felix >
