Loading ...
Sorry, an error occurred while loading the content.
 

Re: [json] Glad to be here, some questions?

Expand Messages
  • Kris Zyp
    ... Yikes, recommending inaccurate media types? This easily leads down the hideous road of content sniffing. Hopefully that wouldn t be suggested for
    Message 1 of 5 , Jul 21, 2009
      Tyler Close wrote:
      > On Tue, Jul 21, 2009 at 10:03 AM, Kris Zyp<kriszyp@...
      > <mailto:kriszyp%40gmail.com>> wrote:
      > > gearond@... <mailto:gearond%40sbcglobal.net> wrote:
      > >> (1) When sending a new record to a service, via POST, do you:
      > >> (a) append the raw JSON string below the HTTP headers, etc using
      > >> which mime type?
      > >>
      > > RFC 4627 specifies application/
      >
      > json (and I highly recommend that you
      > > follow that advise)
      >
      > From a practical perspective, it is better to label your POST entity
      > as Content-Type "text/plain", since this will be handled more
      > efficiently in cross-domain requests from the browser. See:
      >
      > http://www.w3.org/TR/access-control/#simple-method
      > <http://www.w3.org/TR/access-control/#simple-method>
      >
      > Following the RFC will cost you an additional network round-trip for
      > every unique URL in your application.
      >
      Yikes, recommending inaccurate media types? This easily leads down the
      hideous road of content sniffing. Hopefully that wouldn't be suggested
      for same-origin communication where media types can be accurately
      specified. Of course when it comes to cross-domain there tons of hacks
      that we have to resort to, JSONP, window.name, fragment identifiers, so
      standards do indeed have to tempered with practicality. But, CS-XHR is
      supposed to provide a better road, seems a shame we are already seeing
      hacks laid on it :/.

      >
      > AFAICT, very few JSON services use application/json, so your code
      > should be tolerant of responses with other Content-Type header values.
      >
      Yes, the web is awash with abuses, so it is wise to be tolerant of
      responses, but I wouldn't recommend contributing to the mess. Dojo's
      JSON HTTP/REST client (JsonRestStore) does properly set the Content-Type
      to application/json for same-origin PUT and POST requests. Needless to
      say that is the client I would recommend :). (of course I am biased, and
      I am sure web_send is good as well, Tyler's work is excellent).

      Kris
    • Tatu Saloranta
      On Tue, Jul 21, 2009 at 3:01 PM, Kris Zyp wrote: ... I fully agree -- I would prefer using proper content/media types, since those do serve
      Message 2 of 5 , Jul 21, 2009
        On Tue, Jul 21, 2009 at 3:01 PM, Kris Zyp<kriszyp@...> wrote:
        ...
        >> AFAICT, very few JSON services use application/json, so your code
        >> should be tolerant of responses with other Content-Type header values.
        >>
        > Yes, the web is awash with abuses, so it is wise to be tolerant of
        > responses, but I wouldn't recommend contributing to the mess. Dojo's
        > JSON HTTP/REST client (JsonRestStore) does properly set the Content-Type
        > to application/json for same-origin PUT and POST requests. Needless to
        > say that is the client I would recommend :). (of course I am biased, and
        > I am sure web_send is good as well, Tyler's work is excellent).

        I fully agree -- I would prefer using proper content/media types,
        since those do serve purpose esp. regarding intermediaries.

        Another thing to consider is that JSON is hardly only sent by
        browsers: most of my own use cases are for services communicating (or
        in general non-browser clients). So it is not reasonable to assume
        that most decisions be driven by what browsers do -- yes, JSON is
        convenient for that use case, but applicability extends well beyond
        that domain.

        -+ Tatu +-
      Your message has been successfully submitted and would be delivered to recipients shortly.