>>> On 08.03.2010 09:08, Vidar Ramdal wrote: >>>> On Thu, Jan 28, 2010 at 3:10 PM, Vidar Ramdal <vi...@idium.no> 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 <fmesc...@gmail.com> 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 <fmesc...@gmail.com> 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. -- Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no Sommerrogata 13-15, N-0255 Oslo, Norway + 47 22 00 84 00 / +47 21 531941, ext 2070
