While looking thru the brand new documentation i found myself stumbling upon the X-JSON header "again" as being suggested for automatic json evaluation within prototype.
I must say that this approach is bad. We should evaluate on content type. It is simple to add and i wonder why no one else did it already.
The content-type "text/x-json" is the closest acceptable description according to the RFCs and should be used by prototype to determine if evaluation is in order. Just like text/javascript, which is implemented already.
The whole reason behind this is, that a header line is limited to a specific size. So if youre JSON data is to huge, the server will return nothing (or refuse delivery.. i dont know exactly what happens in the background - browser or server). I expirienced this in a PHP/Apache enviroment.
We should stick to content types instead of "inventing" new headers which are limited in size anyways..
> While looking thru the brand new documentation i found myself > stumbling upon the X-JSON header "again" as being suggested for > automatic json evaluation within prototype.
> I must say that this approach is bad. We should evaluate on content > type. It is simple to add and i wonder why no one else did it already.
> The content-type "text/x-json" is the closest acceptable description > according to the RFCs and should be used by prototype to determine if > evaluation is in order. Just like text/javascript, which is > implemented already.
> The whole reason behind this is, that a header line is limited to a > specific size. So if youre JSON data is to huge, the server will > return nothing (or refuse delivery.. i dont know exactly what happens > in the background - browser or server). I expirienced this in a > PHP/Apache enviroment.
> We should stick to content types instead of "inventing" new headers > which are limited in size anyways..
On 1/19/07, Kjell Bublitz <m3nt0r...@gmail.com> wrote:
> While looking thru the brand new documentation i found myself > stumbling upon the X-JSON header "again" as being suggested for > automatic json evaluation within prototype.
> I must say that this approach is bad. We should evaluate on content > type. It is simple to add and i wonder why no one else did it already.
> The content-type "text/x-json" is the closest acceptable description > according to the RFCs and should be used by prototype to determine if > evaluation is in order. Just like text/javascript, which is > implemented already.
Why "text/x-json" and not "application/json" which is the approved JSON mime-type?
None of theme are approved, but according to the RFC, the text-tree is closest one when it comes down to properly describing the content. You put everything into "application" that is too specific or "does not fit into any of the other categories"
Kjell
On 1/20/07, Peter Michaux <petermich...@gmail.com> wrote:
> On 1/19/07, Kjell Bublitz <m3nt0r...@gmail.com> wrote:
> > While looking thru the brand new documentation i found myself > > stumbling upon the X-JSON header "again" as being suggested for > > automatic json evaluation within prototype.
> > I must say that this approach is bad. We should evaluate on content > > type. It is simple to add and i wonder why no one else did it already.
> > The content-type "text/x-json" is the closest acceptable description > > according to the RFCs and should be used by prototype to determine if > > evaluation is in order. Just like text/javascript, which is > > implemented already.
> Why "text/x-json" and not "application/json" which is the approved > JSON mime-type?
Just for reference towards discussion, here a quote from the RFC:
".4. The Application Content-Type
The "application" Content-Type is to be used for data which do not fit in any of the other categories, and particularly for data to be processed by mail-based uses of application programs. This is information which must be processed by an application before it is viewable or usable to a user. "
> None of theme are approved, but according to the RFC, the text-tree is > closest one when it comes down to properly describing the content. You > put everything into "application" that is too specific or "does not > fit into any of the other categories"
> Kjell
> On 1/20/07, Peter Michaux <petermich...@gmail.com> wrote:
> > On 1/19/07, Kjell Bublitz <m3nt0r...@gmail.com> wrote:
> > > While looking thru the brand new documentation i found myself > > > stumbling upon the X-JSON header "again" as being suggested for > > > automatic json evaluation within prototype.
> > > I must say that this approach is bad. We should evaluate on content > > > type. It is simple to add and i wonder why no one else did it already.
> > > The content-type "text/x-json" is the closest acceptable description > > > according to the RFCs and should be used by prototype to determine if > > > evaluation is in order. Just like text/javascript, which is > > > implemented already.
> > Why "text/x-json" and not "application/json" which is the approved > > JSON mime-type?
This is a *great* idea in my opinion. I myself have experienced the
size limitations of the X-JSON header before. However, I don't see why
there can't be support for both so that backwards compatibility isn't
broken. Programmers would just have to know that you can't use them
both simultaneously. That said, I wouldn't mind seeing X-JSON replaced
with Content-type but it would mean hours of going back and changing
code.
Colin
Kjell Bublitz wrote:
Just for reference towards discussion, here a quote from the RFC:
".4. The Application Content-Type
The "application" Content-Type is to be used for data which do not fit
in any of the other categories, and particularly for data to be
processed by mail-based uses of application programs. This is
information which must be processed by an application before it is
viewable or usable to a user. "
http://www.faqs.org/rfcs/rfc1521.html
Thats why i chose "text/x-json" over "application/x-json". It is
readable text, after all
Kjell
On 1/20/07, Kjell Bublitz <m3nt0r.de@gmail.com> wrote:
Hi Peter
None of theme are approved, but according to the RFC, the text-tree is
closest one when it comes down to properly describing the content. You
put everything into "application" that is too specific or "does not
fit into any of the other categories"
Kjell
On 1/20/07, Peter Michaux <petermichaux@gmail.com> wrote:
While looking thru the brand new documentation i found myself
stumbling upon the X-JSON header "again" as being suggested for
automatic json evaluation within prototype.
I must say that this approach is bad. We should evaluate on content
type. It is simple to add and i wonder why no one else did it already.
The content-type "text/x-json" is the closest acceptable description
according to the RFCs and should be used by prototype to determine if
evaluation is in order. Just like text/javascript, which is
implemented already.
Why "text/x-json" and not "application/json" which is the approved
JSON mime-type?
Peter
--
JavaScript for Rails: http://forkjavascript.org
Oooh .. application/json then... also i can't aggree on this decision, as stated in my previous post. It is not binary, it is text.
But i dont work for IANA, so be it..
(back to topic)
Since this is a official mime, there is more need to leave the "X-JSON" path and move towards application/json.. content-type should be enough to negotiate eval.
On 1/20/07, Peter Michaux <petermich...@gmail.com> wrote:
You're missing the point of the X-JSON header (which doesn't have anything to do with the content type). The idea is that the response body returns data like an HTML fragment, and the X-JSON header carries status information like "operation successful" or "operation failed", or other simple code that contains rudimentary logic to go with the actual content delivered in the response body. If you want to pass back JSON only to the client, do so in the response body, and eval by hand.
> While looking thru the brand new documentation i found myself > stumbling upon the X-JSON header "again" as being suggested for > automatic json evaluation within prototype.
> I must say that this approach is bad. We should evaluate on content > type. It is simple to add and i wonder why no one else did it already.
> The content-type "text/x-json" is the closest acceptable description > according to the RFCs and should be used by prototype to determine if > evaluation is in order. Just like text/javascript, which is > implemented already.
> The whole reason behind this is, that a header line is limited to a > specific size. So if youre JSON data is to huge, the server will > return nothing (or refuse delivery.. i dont know exactly what happens > in the background - browser or server). I expirienced this in a > PHP/Apache enviroment.
> We should stick to content types instead of "inventing" new headers > which are limited in size anyways..
I am about automatic evaluation support based on the mime-type. I know that i can do everything i want by hand...of course.. but that ain't automatic.
Secondly, there is no point for X-JSON to be a status message carrier or "just for simple stuff". Drop it entirely. It's is unnecessary.
Most people will have an own error format / object notation which they transport in the responseText as a replacement for the expected content and act on it. (eg include a "status" key)
This two-way devlivery is just complicating things.
And lastly, the thing i am pointing at is, that prototype does not automaticly evaluates responseText if X-JSON header was found, forcing me to evaluate by hand..
A server should always deliver, regardless if error or data. With that in mind, i don't need a X-JSON header to tell me that everything is alright and that i could now go ahead and eval responseText.
Thats why i suggest automatic evaluation of responseText if the content-type is application/json. Simple.. just like text/xml, just like text/javascript ..
Regards
On 1/20/07, David Zülke <d...@bitxtender.com> wrote:
> You're missing the point of the X-JSON header (which doesn't have > anything to do with the content type). The idea is that the response > body returns data like an HTML fragment, and the X-JSON header > carries status information like "operation successful" or "operation > failed", or other simple code that contains rudimentary logic to go > with the actual content delivered in the response body. > If you want to pass back JSON only to the client, do so in the > response body, and eval by hand.
> > While looking thru the brand new documentation i found myself > > stumbling upon the X-JSON header "again" as being suggested for > > automatic json evaluation within prototype.
> > I must say that this approach is bad. We should evaluate on content > > type. It is simple to add and i wonder why no one else did it already.
> > The content-type "text/x-json" is the closest acceptable description > > according to the RFCs and should be used by prototype to determine if > > evaluation is in order. Just like text/javascript, which is > > implemented already.
> > The whole reason behind this is, that a header line is limited to a > > specific size. So if youre JSON data is to huge, the server will > > return nothing (or refuse delivery.. i dont know exactly what happens > > in the background - browser or server). I expirienced this in a > > PHP/Apache enviroment.
> > We should stick to content types instead of "inventing" new headers > > which are limited in size anyways..
On Saturday 20 January 2007 15:22, Kjell Bublitz wrote:
> Secondly, there is no point for X-JSON to be a status message carrier > or "just for simple stuff". Drop it entirely. It's is unnecessary.
> Most people will have an own error format / object notation which they > transport in the responseText as a replacement for the expected > content and act on it. (eg include a "status" key)
My reading of the X-JSON header was that it's useful in cases where you want to pass some secondary data back with a response. The practice of 'piggy-backing' data in this way isn't to everybody's taste, but it can be a useful way of avoiding extra traffic.
Rails & Prototype both have a strong bent towards delivering fragments of HTML rather than data in the response. In this case, If you're sending back content, I don't see how to easily embed secondary data inside the main response body, other than stuffing it into a hidden DIV, which loses several hundred points for elegance. Sure, if you're delivering data anyway, X-JSON isn't particularly useful.
> On Saturday 20 January 2007 15:22, Kjell Bublitz wrote: >> Secondly, there is no point for X-JSON to be a status message carrier >> or "just for simple stuff". Drop it entirely. It's is unnecessary.
>> Most people will have an own error format / object notation which >> they >> transport in the responseText as a replacement for the expected >> content and act on it. (eg include a "status" key)
> My reading of the X-JSON header was that it's useful in cases where > you want > to pass some secondary data back with a response. The practice of > 'piggy-backing' data in this way isn't to everybody's taste, but it > can be a > useful way of avoiding extra traffic.
> Rails & Prototype both have a strong bent towards delivering > fragments of HTML > rather than data in the response. In this case, If you're sending back > content, I don't see how to easily embed secondary data inside the > main > response body, other than stuffing it into a hidden DIV, which > loses several > hundred points for elegance. Sure, if you're delivering data > anyway, X-JSON > isn't particularly useful.
Just want to support that opinion. We are using the X-JSON header exactly for that.
> On Monday 22 January 2007 12:42, Mislav wrote: >> Will be done: >> http://dev.rubyonrails.org/ticket/7295 > Just saw this come in on the list - sounds like a good suggestion > to me.
This seems like almost a duplication of effort -- we already have access to the HTTP status codes, which could (should?) be used to determine success (example, 200 = OK, 500 = Error). The content body includes the results or error message(s).
On 1/22/07, Alexander Presber <aljos...@weisshuhn.de> wrote:
Let us get something clear - the X-JSON header is a hack. Nothing serious, just a small hack which simplifies returning two types of data (HTML and application/json) at the same time. Of course we're using HTTP headers in a way we shouldn't, but has anyone seen how multipart-encoded message look like? Our header hack is way nicer and technically simpler than that kind of encoding.
The X-something headers are reserved for custom (proprietary) usage. We have the freedom to use them in any way we want to, and we have taken that liberty to do some highly conventional JSON magic.
For big loads of JSON data you'll want to use response body. The ticket I submitted (and for which I'll provide a patch for) will enable that.
Ed C.: yeah, HTTP status messages could be extracted and shown in this case, but X-JSON chunks are used for much more than that. I use them regularly to return small hashes representing certain records or other objects.
This change, while I think is a good idea in general, will be somewhat
difficult to make use of if the new JSON object replaces the old JSON
object.
I, and apparently others, use X-JSON often for error checking, debug
messages, status flags, etc.. When your application requires the
occasional use of raw HTML and you don't want to encode it all in a
JSON message, it is very useful. However, I still use JSON encoded data
in the response body because of the size limitations of the X-JSON
header.
Having X-JSON *replaced* by the evaluated responseText, will make it
difficult for when I want to still use the X-JSON header for
error/debug/status info, but send the main response body as either
plain X-HTML or JSON due to the size limit.
To make it more clear, I would have to account for the following
possible scenarios on the server side in order to make use of the new
feature:
1) If response is HTML then error/debug is X-JSON
2) If response is JSON then error/debug is in response JSON
It would be nice if the body JSON didn't replace the X-JSON because
then I could always use X-JSON for error/debug regardless of what is in
the responseText.
This just seems like better separation of data and error/status
handling to me.
My suggestion is perhaps rather than replacing X-JSON it should be
placed inside the response object? e.g. "xhr.json" similar to
"xhr.responseText"
On Saturday 20 January 2007 15:22, Kjell Bublitz wrote:
Secondly, there is no point for X-JSON to be a status message carrier
or "just for simple stuff". Drop it entirely. It's is unnecessary.
Most people will have an own error format / object notation which
they
transport in the responseText as a replacement for the expected
content and act on it. (eg include a "status" key)
My reading of the X-JSON header was that it's useful in cases where
you want
to pass some secondary data back with a response. The practice of
'piggy-backing' data in this way isn't to everybody's taste, but it
can be a
useful way of avoiding extra traffic.
Rails & Prototype both have a strong bent towards delivering
fragments of HTML
rather than data in the response. In this case, If you're sending back
content, I don't see how to easily embed secondary data inside the
main
response body, other than stuffing it into a hidden DIV, which
loses several
hundred points for elegance. Sure, if you're delivering data
anyway, X-JSON
isn't particularly useful.
Just want to support that opinion. We are using the X-JSON header
exactly for that.
Alex
On 1/22/07, Colin Mollenhour <eliteii...@mollenhour.com> wrote:
> This change, while I think is a good idea in general, will be somewhat > difficult to make use of if the new JSON object replaces the old JSON > object.
You have a point there. I didn't think people would care, but you have convinced me they could.
Your idea of writing to the "json" property of the xhr object is not bad. Alternatively, there could be a "getJson()" method that lazily evaluates "responseText".
> This seems like almost a duplication of effort -- we already have access to > the HTTP status codes, which could (should?) be used to determine success > (example, 200 = OK, 500 = Error). The content body includes the results or > error message(s).
HTTP 500 is generally used to signal an application error somewhere in the system (the database is down, you tried to divide by zero, and so on). Similarly, other status codes relate to the status of the attempted HTTP request and response (e.g. 401 = your request requires authentication).
This is a different thing from an application error or status code e.g. 'the object you are trying to update is a stale copy'. X-JSON can also be used for status/update data such as 'you have three outstanding cases, here are their names and ids', to automatically refresh a list in the background, every time you request or update anything in your app (in which case the request body is busy reporting something else).
Mislav - yes, X-JSON is a hack, and an acceptable one IMO, with a good pedigree. As you point out, multipart MIME type responses are a hack on top of HTTP - so are CGI parameters, and sessions, if you look at what HTTP was originally designed to do.
On 1/19/07, Kjell Bublitz <m3nt0r...@gmail.com> wrote:
> Thats why i chose "text/x-json" over "application/x-json". It is > readable text, after all
I puzzled over the choice of "application" first but can think of a couple reasons "application" could be more natural.
JSON is expressed in JavaScript. JavaScript is distributed as text not is some unreadable compiled binary. If it could be distributed in a small compiled form it surely would and so "application" would be more clearly appropriate.
JSON is expressed in JavaScript. JavaScript is a programming language that describes behavior aspect of a web page. Behavior is in the application realm.
If i query a XML service, i get a XML response (text/xml) - with error or data If i query a JSON service, i get a JSON response (application/json) - with error or data
Is there something to disagree?
Only because there is a hack which allows transport of HTML (or whatever) along with a pure dataformat, i don't see why that should be a keeper. I personally create such fragments from JSON data, or modify the application behaviour. There is no text/html involved in that action and i belief that this is the whole purpose of JSON. If my application uses pre-generated HTML aside from JSON -in a row-, i should ask myself why i use JSON at all. Just for a 'yay or nay'?? I don't think so..
But.. it's a matter of application design after all. Generally: mixing mime is bad.
- Kjell
On 1/22/07, Dave Crane <d...@cranefamily.force9.co.uk> wrote:
> On Monday 22 January 2007 15:56, Ed C. wrote: > > This seems like almost a duplication of effort -- we already have access to > > the HTTP status codes, which could (should?) be used to determine success > > (example, 200 = OK, 500 = Error). The content body includes the results or > > error message(s).
> HTTP 500 is generally used to signal an application error somewhere in the > system (the database is down, you tried to divide by zero, and so on). > Similarly, other status codes relate to the status of the attempted HTTP > request and response (e.g. 401 = your request requires authentication).
> This is a different thing from an application error or status code e.g. 'the > object you are trying to update is a stale copy'. X-JSON can also be used for > status/update data such as 'you have three outstanding cases, here are their > names and ids', to automatically refresh a list in the background, every time > you request or update anything in your app (in which case the request body is > busy reporting something else).
> Mislav - yes, X-JSON is a hack, and an acceptable one IMO, with a good > pedigree. As you point out, multipart MIME type responses are a hack on top > of HTTP - so are CGI parameters, and sessions, if you look at what HTTP was > originally designed to do.
While I read through these comments, I decided for the first time in awhile to throw in my own two cents.
JSON stands for: JavaScript Object Notation. If we take the first word in that title: JavaScript, we get our answer. JSON is, through it's basis, JavaScript -- so set the MIME type as so; application.
Just because you can read text and understand what it means and what it does is not a valid method to describe the data as simple text. I can read binary code (albeit slowly), but that does not mean it is text.
----- Original Message ----- From: "Peter Michaux" <petermich...@gmail.com> To: rubyonrails-spinoffs@googlegroups.com Sent: Monday, January 22, 2007 10:56:30 AM (GMT-0700) US/Mountain Subject: [Rails-spinoffs] Re: About X-JSON header and evil things... ;)
On 1/19/07, Kjell Bublitz <m3nt0r...@gmail.com> wrote:
> Thats why i chose "text/x-json" over "application/x-json". It is > readable text, after all
I puzzled over the choice of "application" first but can think of a couple reasons "application" could be more natural.
JSON is expressed in JavaScript. JavaScript is distributed as text not is some unreadable compiled binary. If it could be distributed in a small compiled form it surely would and so "application" would be more clearly appropriate.
JSON is expressed in JavaScript. JavaScript is a programming language that describes behavior aspect of a web page. Behavior is in the application realm.
Are they necessarily mutually exclusive? Can X-JSON not stay for those who like it, and support for a _configurable_OR_standard_ content type be added? This seems like something that could be configurable at the application, page, or request level under various conditions or developer preference.
On 1/22/07, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
> Pardon my ignorance, but huh? I thought this *was* the group for > Prototype/Script.aculo.us requests. Is there someplace else I should > be looking?
> Or did I misunderstand--do you see this as a RoR change request, and > were suggesting it go there?
|
