On Mon, Mar 8, 2010 at 9:44 AM, Felix Meschberger <fmesc...@gmail.com> wrote: > Hi, > > 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? > > 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)? 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 -- 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
