I have added support for the GET method, and removed the restrictions on
caching.
JSONRequest is intended to provide a safer alternative to the use of dynamic
script tags for the exchange of data. It is exempt from the Same Site Policy.
http://JSON.org/JSONRequest.html
The central idea with the JSONRequest is that it is exempted from the Same
Origin Policy. It allows for exchanging data with a server in any domain that
specifically accepts JSONRequests.
In order to be exempted from the Same Origin Policy, there are several
restrictions on JSONRequest in
Quoting Douglas Crockford [EMAIL PROTECTED]:
The central idea with the JSONRequest is that it is exempted from the
Same Origin Policy. It allows for exchanging data with a server in
any domain that specifically accepts JSONRequests.
In order to be exempted from the Same Origin Policy, there
Gervase Markham wrote:
Douglas Crockford wrote:
I have modified the JSONRequest proposal so that the Content-Type in
both directions must be application/json/request.
Er, why? Having two slashes in a content type is either extremely weird
or completely illegal (glancing at the RFC, I'm not
I have modified the JSONRequest proposal so that the Content-Type in both
directions must be application/json/request.
http://JSON.org/JSONRequest.html
Douglas Crockford wrote:
If application/json isn't acceptable (though I don't know why it
wouldn't be), then try a hyphen instead: application/json-request
The issue is to provide a way of identifying JSONRequest transactions
that cannot be confused with legacy applications.
To me, this
with XmlHttpRequest, and I think
lots of folks have.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Douglas
Crockford
Sent: Wednesday, March 29, 2006 7:41 PM
To: [EMAIL PROTECTED]
Subject: [whatwg] JSONRequest
If application/json isn't acceptable
Douglas Crockford wrote:
The JSONRequest does only one thing:
snip
Are you planning to take the excellent advice from I forget who to
change the name? The name XmlHttpRequest sucks because it doesn't
necessarily return XML, and it doesn't have to be over HTTP. Let's not
tie the name of a new
Gervase Markham wrote:
Douglas Crockford wrote:
The JSONRequest does only one thing:
snip
Are you planning to take the excellent advice from I forget who
to change the name?
That was me. Nice to see I'm quite memorable :-)
The name XmlHttpRequest sucks because it doesn't
necessarily
On 3/20/06, Douglas Crockford [EMAIL PROTECTED] wrote:
Or indeed wrote your script before this JSONRequest was invented.
I think I see where you are confused. A pre-JSONRequest JSON application
will be using GET, or POST with a conventional POST body.
What exactly is a conventional POST
On 3/21/06, Gervase Markham [EMAIL PROTECTED] wrote:
Chris Holland wrote:
That's where the extra HTTP header would come-in:
X-Allow-Foreign-Hosts: Forcing developers who expose such a service,
to make the conscious choice to expose data to the world, what Jim
refers to as OPT-IN.
I
On 3/19/06, Douglas Crockford [EMAIL PROTECTED] wrote:
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
My intention with JSONRequest is to make it minimal because being minimal will
make it easier to understand and easier to implement correctly.
Making caching behave completely differently for
http://example.org/json.rjs in two different situations is not easy to
understand.
Making caching
Or indeed wrote your script before this JSONRequest was invented.
I think I see where you are confused. A pre-JSONRequest JSON application will be
using GET, or POST with a conventional POST body. JSONRequest cannot generate a
GET, so those interfaces are safe, and it cannot generate a
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
On 3/16/06, Gervase Markham [EMAIL PROTECTED] wrote:
Hallvord R M Steen wrote:
You are right, if no variables are created one can't see the data by
loading it in a SCRIPT tag. Are you aware of intranets/CMSes that use
this as a security mechanism?
That's not actually right. I'm pretty
On 3/17/06, Gervase Markham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
Please can you provide more information on how raw JSON is available
from script elements?
Apologies; it was the Array constructor, and I was slightly wrong in the
details. Here is the exploit:
The JSONRequest does only one thing: It exchanges data between scripts on pages
with JSON servers in the web. It provides this highly valuable service while
introducing no new security vulnerabilities.
A browser within a filewall may have the capability to interact with a server
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
On 3/17/06, Douglas Crockford [EMAIL PROTECTED] 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
On 3/16/06, Hallvord R M Steen [EMAIL PROTECTED] wrote:
On 3/11/06, Jim Ley [EMAIL PROTECTED] wrote:
Accessing JSON resources on a local intranet which are
secured by nothing more than the requesting IP address.
While this is a valid concern I think the conclusion no *new*
security
Hallvord R M Steen wrote:
You are right, if no variables are created one can't see the data by
loading it in a SCRIPT tag. Are you aware of intranets/CMSes that use
this as a security mechanism?
That's not actually right. I'm pretty sure this came across a public
security list, so...
You can
On Sun, 12 Mar 2006 04:11:28 +0600, Douglas Crockford
[EMAIL PROTECTED] wrote:
I am proposing a new mechanism for doing data transport in Ajax/Comet
applications. It is called JSONRequest. It is a minimal communications
facility that can be exempted from the Same Origin Policy.
You can read
Gervase Markham wrote:
Darin Fisher wrote:
Backing up a second, I think what we need is a way to grant websites the
ability to control who may access their resources. It'd be ideal if the
browser had a way to ask the server for the list of hosts (or domains)
that are permitted to access it.
I am proposing a new mechanism for doing data transport in Ajax/Comet
applications. It is called JSONRequest. It is a minimal communications
facility that can be exempted from the Same Origin Policy.
You can read about it here: http://json.org/JSONRequest.html
Unfortunately your security
Darin Fisher wrote:
Keep in mind that there is also the problem that the POST request may
have undesirable side-effects. The web app probably needs a request
header from the browser to tell it what domain is sending it data. The
Referer header is not sufficient since the browser will not
On 3/13/06, Douglas Crockford [EMAIL PROTECTED] wrote:
It provides this highly valuable service while introducing no new
security vulnerabilities.
is false, please remove it to avoid any confusion.
It would be very helpful if you could list the situations that
you have determined are
27 matches
Mail list logo
