W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2006

[whatwg] JSONRequest

From: S. Mike Dierken <mike@dierken.com>
Date: Wed, 29 Mar 2006 22:10:08 -0800
Message-ID: <200603300616.k2U6GVpD013378@searchalert.net>
Wow. Pretty, uh, interesting.
Why not just have XmlHttpRequest configurable to not share cookies, not
share auth, not accept anything but xml, etc.?

> Does this allow improperly secured applications to be accessed?
> Application that are looking GET cannot be accessed because JSONRequest
only uses POST.
So you would use POST rather than GET just in case an unsecured web
application were contacted?
In the situation that an unsecured web application were contacted, how often
would a POST potentially modify data compared to a GET? (like
http://www.sillyexample.org/folder?id=27&operation=delete - often no content
body is required, and likely the content-type is unchecked anyway).
A poorly written server-side application is doomed no matter what, so you
might as well use a safe HTTP request method.

> If the HTTP status code is not 200 OK, then the request fails. 
That doesn't sound good. What particular situations are bad? Re-direction
makes servers easier to support and maintain.

> Any cookies in the response header are discarded. 
That makes sense, no information leakage.

> JSON messages are never cached.
And you wouldn't use caching but you'd like to avoid a denial-of-service
style attacks?

> By switching to a policy of responding only to well-formatted JSONRequest,
applications can be made more secure.
Do you mean client-side applications (the browser) or the server side?

> JSONRequest is designed to support duplex connections. 
Pretty standard stuff - I've done the same with XmlHttpRequest, and I think
lots of folks have.


> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org 
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Douglas 
> Crockford
> Sent: Wednesday, March 29, 2006 7:41 PM
> To: whatwg at whatwg.org
> Subject: [whatwg] JSONRequest
> 
>  > If application/json isn't acceptable (though I don't know 
> why it wouldn't be), > then try a hyphen instead: 
> application/json-request
> 
> I like application/json-request. That is a good suggestion.
> 
> The issue is to provide a way of identifying JSONRequest 
> transactions that cannot be confused with legacy applications.
> 
Received on Wednesday, 29 March 2006 22:10:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:45 UTC