Hi, On 08.03.2010 12:07, Vidar Ramdal wrote: >>>> 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? > >>> On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <[email protected]> >>> wrote: >>>> 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. > >> On 08.03.2010 11:26, Vidar Ramdal wrote: >>> 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)? > > On Mon, Mar 8, 2010 at 11:47 AM, Felix Meschberger <[email protected]> wrote: >> Hmm, what is the target resource's name ? > > In my example the target resource is /content/file.json > >> 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. > > So, if I want to post a JSON file and have a JSON response, the > request URL would be /content/file.json.json? > >>> 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) > > Well, web browsers seems to always send */* as fallback. E.g., Firefox > sends this: > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > > So, it prefers text/html, but will accept anything (*/*) if the other > media types are unavailable. So "legally" we could return anything, > but since we "can" produce text/html, I guess we should. >
Ok, this lifted my last shade of doubt. Thanks. Regards Felix
