Does anyone know what the max length for a header in IE is? When my X-JSON value is 138 bytes, it works fine but when it''s 1659 it fails. Is this documented anywhere? Thanks, John _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
On 6/1/06, John Wang <johncwang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Does anyone know what the max length for a header in IE is? When my X-JSON > value is 138 bytes, it works fine but when it''s 1659 it fails. Is this > documented anywhere? >I put up a blog entry on this. For now I''m just going to put the JSON string in the response body and eval it myself. Since the IE6 length problem doesn''t exist when the JSON string is in the response body and other AJAX libraries expect the JSON object there, does it make sense for prototype to move that way as well? http://dev411.blogspot.com/2006/06/prototype-x-json-fails-on-long-value.html John _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Am Freitag, 2. Juni 2006 19:17 schrieb John Wang:> On 6/1/06, John Wang <johncwang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > Does anyone know what the max length for a header in IE is? When my > > X-JSON value is 138 bytes, it works fine but when it''s 1659 it fails. Is > > this documented anywhere? > > I put up a blog entry on this. For now I''m just going to put the JSON > string in the response body and eval it myself. Since the IE6 length > problem doesn''t exist when the JSON string is in the response body and > other AJAX libraries expect the JSON object there, does it make sense for > prototype to move that way as well? > > http://dev411.blogspot.com/2006/06/prototype-x-json-fails-on-long-value.htm >lHi John, i agree with you, that''s indeed a problem. For me there''s another (pragmatic) point that speaks for the content-type. I use the Firefox Firebug extension to debug my JSON stuff. And i find it much easier to read the response directly in response tab than between the lines in the headers tab. -- Dirk Eschler <mailto:dirk.eschler-hi6Y0CQ0nG0@public.gmane.org> http://www.krusader.org
John Wang wrote:> On 6/1/06, *John Wang* <johncwang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > <mailto:johncwang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote: > > Does anyone know what the max length for a header in IE is? When > my X-JSON value is 138 bytes, it works fine but when it''s 1659 it > fails. Is this documented anywhere? > > > I put up a blog entry on this. For now I''m just going to put the JSON > string in the response body and eval it myself. Since the IE6 length > problem doesn''t exist when the JSON string is in the response body and > other AJAX libraries expect the JSON object there, does it make sense > for prototype to move that way as well? > > http://dev411.blogspot.com/2006/06/prototype-x-json-fails-on-long-value.html > >Hi all, I find I take a different view on this. I just recently took the time to understand Prototypes Ajax system by using it to implement a small project I had. I fond the X-JSON header when I was looking to solve a problem that was coming up for me. I was looking for a way to determine if an Ajax call was successful. I was facing having to parse the response body, when I found the header. My take, and the way I will be using it, is that the header is for the Meta Data *about* the Ajax transaction, and the response body is for the actual data that is the point of the transaction. Thus I use the header for success/failure info and error messages, and the body may or may not contain any data. Here is a sample from that app, which allows the user to add anew event to a calendar. The server code, in response.php, is written in PHP. The function addEvent() simply formats the html fragment for a new event. case ''addEvent'': $row = addEvent(); if($row < 0) { header(''X-JSON: {"Result":"Failed", "Message":"Could not successfully run query."}''); } else { header(''X-JSON: {"Result":"Ok"}''); echo formatEvent($row); } exit; break; The Javascript code makes the Ajax call when the user clicks the Add button. function addevent(targ) { // alert("Adding..."); new Ajax.Request( responder, { parameters: "function=addEvent&data=" + targ, onComplete: completeAdd }); } function completeAdd(reply) { json = reply.getResponseHeader(''X-JSON'').parseJSON(); if(json) { if(json.Result == "Ok") { new Insertion.Bottom(''schedulelist'', reply.responseText); } else { alert("Error: " + json.Message); } } else { alert("Error: Contact with the server failed. Please Refresh the page."); } } I hope this adds a different perspective on this X-JSON header issue. --Will Merrell
On 6/3/06, Will Merrell <will-jkbzaOXREqcCMe7iY93BLQC/G2K4zDHf@public.gmane.org> wrote:> > My take, and the way I will be using it, is that the header is for the > Meta Data *about* the Ajax transaction, and the response body is for the > actual data that is the point of the transaction. Thus I use the header > for success/failure info and error messages, and the body may or may not > contain any data.Hi Will, I appreciate your response, however, your example fits what I noted as the limited scenarios when the current implementation works well, i.e. when there''s only one large item to be returned and populated in the response body. Let''s take a look at a different example where the response needs to include a set of things? Let''s say you wanted to return some meta data about the transaction and a set of two posts, say refreshing a page like the Digg homepage. For kicks let''s assume that the fields, say the description field below would exceed the IE max header length. With JSON you could return something like the following: { "Result":"ok", "Posts":[ { "time":1149349580, "id":100001, "title":"Article 1 title", "desc":"Article 1 desc (longer than IE header length)", "votes":120, "comments":5, "submitter":"garfield" },{ "time":1149349583, "id":100002, "title":"Article 2 title", "desc":"Article 2 desc (longer than IE header length)", "votes":125, "comments":15, "submitter":"garfield" } ] } In this example you would get your ''Result'' meta data and a set of messages in a structured format. Since each of the posts may be bigger than allowed in X-JSON header there are several options: (1) put the Result metadata in X-JSON and create a separate JSON object for the messages to be put in response body and manually evaled, (2) make multiple AJAX requests where each response has one Post, (3) put Result and the Messages in the same JSON object and put the object in the response body as shown above. Sending back two JSON objects seems like unnecessary work and making multiple AJAX requests will create unnecessary server load. In the example above, I feel putting one JSON object in the response body is the best way to go. By putting HTML fragments in the JSON object, you can have not only multiple fragments of the same kind (e.g. a list of posts) but you can also combine multiple things. Right now your example AJAX request only updates one thing with an HTML fragment, but if we wanted to update two different things, those two different HTML fragments could be included in JSON avoiding the need for another AJAX request. For example, a single AJAX request could return a list of Posts and a list of Hot Stories that appear in a different location. HTTP requests are expensive and rolling up multiple items in one AJAX request/response cycle seems a lot more efficient than making several individual requests. As I mentioned earlier and is with the case of your example, the current use of differentiating X-JSON and response body is only useful when you have one or zero large items to return. I understand your use, however I view your use as a subset of a more generic, and powerful, use. With more complex return values, putting the JSON object in the response body is ultimately a more flexible and extensible design. I feel Prototype''s use of putting the JSON object in X-JSON will encourage inefficient AJAX implementations that end up using more HTTP request/response cycles than necessary. John _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs