[whatwg] JSONRequest

[Chris Holland]

Douglas,

your proposal looks interesting. To address similar issues, I had
started defining a "ContextAgnosticXmlHttpRequest" (caxhr) (
http://chrisholland.blogspot.com/2005/03/contextagnosticxmlhttprequest-informal.html
) a while back, but i'm very-much liking JSON to obtain data
structures from the server.

JSON would make the syndicated data readily consumable via scripting.
Not to mention lightweight payloads.

The mimetype you're defining, because it is new, pretty-much ensures
no existing service behind an intranet could be affected.

I could still envision one day developers setting-up JSON syndication
services behind an intranet, not quite grokking the fact that their
data is now accessible from outside of their intranet. Silly, i know
but ...

Perhaps the old "X-Allow-Foreign-Host" idea this list was throwing
around while discussing caxhr, might also be useful in a JSON request?
A developer would have to explicitly set this header for their data to
be readable by a JSONRequester ?

Your Domain HTTP header seems similar in principle to my stressing the
importance of the requester sending an accurate "Refer[r]er" header. I
could see use cases for leveraging document.domain and Refer[r]er in
instances where you want to restrict access to your service to
individual originating URIs, or to hosts or domains.

I could see myself using caxhr in instances where i want to embed
(X)HTML-esque content within my own document, from a 3rd-party source.
For example, eBay allows their affiliates to embed javascript in their
page to retrieve auctions that match certain keywords, directly from
ebay's site. The payload basically document.writes a bunch of HTML. It
works ... but is rather clumsy, because any latency from ebay's server
will cause *my page* to interrupt its rendering. Not to mention i'm
allowing a foreign script to run on my document !@! In those
instances, I wish i could have the end-user's browser retrieve a "blob
of HTML" from eBay, and cloneNode(true)-insert it at a specified
location my DOM. caxhr would work well in this instance.

There are other instances where I just want a lightweight way to get
data structures from the server, and JSONRequest sounds best suited
for this.


Eh Jim,
i don't work at yahoo, but have met developers from there, they're
pretty rabid about bandwidth saving, caching, and effective content
delivery, and whatnot, precisely because they're *that* big with high
traffic. I was told there's a semi-official  title of Chief Caching
Officer held by someone somewhere in some department. You'll find all
images served by their akamaized us.*.yimg.com have their Expires
header set to expire in like ... a while, their last-modified set to
"a long time ago", which more or less indicates to me they at least
care about caching :) :

chris% telnet us.i1.yimg.com 80
Trying 72.246.50.14...
Connected to a943.yimg.com.georedirector.akadns.net.
Escape character is '^]'.
GET /us.yimg.com/i/us/my/b/myma_5l.gif HTTP/1.1
Host: us.i1.yimg.com

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 1340
Last-Modified: Fri, 15 Apr 1994 00:00:00 GMT
X-N: S
Date: Sat, 18 Mar 2006 01:43:29 GMT
Connection: keep-alive
Expires: Thu, 15 Apr 2010 20:00:00 GMT

On 3/17/06, Jim Ley <jim.ley at gmail.com> wrote:
> On 3/17/06, Douglas Crockford <douglas at crockford.com> wrote:
> > > The cache rules are unworkable, please remove these and use standard
> > > HTTP methods for suggesting the cacheability of a resource, forcing
> > > them to be uncacheable is unworkable w.r.t. to proxy caches and
> > > extremely unwelcome within the browser.
> >
> >   Applications must not cache responses to a POST request because the
> >   application has no way of knowing that the server would return an
> >   equivalent response on some future request.
>
> Of course the application can know that, that's what HTTP cache
> control headers are for, the cacheability of a resource is easy to
> advertise, and all browsers should know it.
>
> Please explain your use cases for making no JSONRequest cacheable, it
> really is completely silly to me and an absolute deal breaker, I
> assume it's because working for yahoo you need not worry about such
> things as bandwidth and cost.
>
> Jim.
>


--
Chris Holland
http://chrisholland.blogspot.com/