It's be awesome if the Inspector's Resources panel supported structured views for viewing responses. There's already some views per response supported (eg: an img request is viewable as an image). It'd be awesome to view the response in an expandable tree-view if the response was in a structured format (like JSON or XML). Then when I got a response like: {"RESPONSE":{"VALUE":false,"CODE":0},"REQUEST":{"USER":"mtakacs_work","INTL":"us","SERVICE":"CAL","SERVICE_VERSION":"1.2","OPERATION":"STAT","DTSTAMP_UTC":"20080903T093531","BUILD":"5.0 hitaine 20080808-1128"}} I could twistie it open to see + RESPONSE ++ VALUE : false ++ CODE: 0 + REQUEST ++ USER: mtakacs_work ++ SERVICE: CAL ++ INTL: us ++ .... Both Fiddler (IE network tool) and Charles (mac sniffer) support this style of response viewing. Fiddler Images - right hand image shows the response inspector. They have tabs for HEX , RAW, XML, etc. http://www.fiddler2.com/fiddler2/ http://www.fiddler2.com/fiddler/images/props.png Here's a 3rd party plugin that views JSON responses: http://www.codeplex.com/JsonViewer/Wiki/View.aspx?title=More%20screen%20shots&referringTitle=Home Charles - mac network response inspector http://www.charlesproxy.com/index.php
*** Bug 37488 has been marked as a duplicate of this bug. ***
*** Bug 49173 has been marked as a duplicate of this bug. ***
*** Bug 39711 has been marked as a duplicate of this bug. ***
The feature seems to be present in Google Chrome 12.0.742.60, fantastic! Unfortunately the JSON tree is collapsed by default and I think it would be better if it was expanded. Also, the tree display the entire node on the line when it's collapsed or expanded, I think this information should be hidden when the node is expanded otherwise it creates duplicate data and is confusing.
(In reply to comment #4) > The feature seems to be present in Google Chrome 12.0.742.60, fantastic! Using 15.0.865.0 in the dev channel, I do not see this feature present. Is there anything you must do other than go to the Response tab of a response with application/json content-type?
(In reply to comment #5) > (In reply to comment #4) > > The feature seems to be present in Google Chrome 12.0.742.60, fantastic! > > Using 15.0.865.0 in the dev channel, I do not see this feature present. Is there anything you must do other than go to the Response tab of a response with application/json content-type? We currently support it for application/json XHRs and JSONP requests. What kind of request do you have?
Please note, that JSONP requests should have application/jsonp mime-type.(In reply to comment #5) > (In reply to comment #4) > > The feature seems to be present in Google Chrome 12.0.742.60, fantastic! > > Using 15.0.865.0 in the dev channel, I do not see this feature present. Is there anything you must do other than go to the Response tab of a response with application/json content-type? It should be in Preview tab actually.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > The feature seems to be present in Google Chrome 12.0.742.60, fantastic! > > > > Using 15.0.865.0 in the dev channel, I do not see this feature present. Is there anything you must do other than go to the Response tab of a response with application/json content-type? > > We currently support it for application/json XHRs and JSONP requests. What kind of request do you have? The request content-type is Ajax/xml generated from XHR using Ext.js 3.3. The server application must always consume xml, but it then does return a response with content-type application/json. I assume that this mismatch between request and response types causes Chrome to not preview the response as JSON. (In reply to comment #7) > It should be in Preview tab actually. Thanks for the info. Unfortunately it is not working there either, surely caused by my reply to comment #6
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > The feature seems to be present in Google Chrome 12.0.742.60, fantastic! > > > > > > Using 15.0.865.0 in the dev channel, I do not see this feature present. Is there anything you must do other than go to the Response tab of a response with application/json content-type? > > > > We currently support it for application/json XHRs and JSONP requests. What kind of request do you have? > > The request content-type is Ajax/xml generated from XHR using Ext.js 3.3. The server application must always consume xml, but it then does return a response with content-type application/json. I assume that this mismatch between request and response types causes Chrome to not preview the response as JSON. The request content type does not matter in that case. Could you please show response contents or provide a url where this behavior could be seen? Is it JSON or JSONP? Please note that for JSONP response content type should be application/jsonp.
Created attachment 106421 [details] sample of an application/json response for which Chrome does not show a hierarchical preview
(In reply to comment #9) > The request content type does not matter in that case. > Could you please show response contents or provide a url where this behavior could be seen? Is it JSON or JSONP? Please note that for JSONP response content type should be application/jsonp. This is JSON, not JSONP. Response Headers: Cache-Control:private Content-Length:4972 Content-Type:application/json; charset=utf-8 Date:Tue, 06 Sep 2011 15:09:17 GMT Server:Microsoft-IIS/7.5 X-AspNet-Version:4.0.30319 X-Powered-By:ASP.NET The json response is attached. It should be a valid json string with some escaped xml snippets in some of the values. In turn, some of the xml snippets have some escaped json properties in a data-config attribute that end up being used by Ext.js. I chose one of our more complicated (but not long) responses since it will probably give the best chance of demonstrating any json parsing bugs if that is indeed the reason for failure.
Looks like your JSON is correct, when I run xhr = new XMLHttpRequest(); xhr.open("GET", "https://bug-20628-attachments.webkit.org/attachment.cgi?id=106421"); xhr.send(); in the console on this bug's page, I can see the content as a tree in preview tab. Moreover, for JSON content we do not check content-type at all. We only check that the resource is an XMLHttpRequest result and oculd be parsed as JSON. One case when this feature does not work is when main document url is the same as the one for XMLHttpRequest. E.g. if you run the same line on the https://bug-20628-attachments.webkit.org/attachment.cgi?id=106421 page, then the content is parsed. I am going to fix this, but I'd like to know if this is exactly your problem or another one.
(In reply to comment #12) > One case when this feature does not work is when main document url is the same as the one for XMLHttpRequest. E.g. if you run the same line on the https://bug-20628-attachments.webkit.org/attachment.cgi?id=106421 page, then the content is parsed. > I am going to fix this, but I'd like to know if this is exactly your problem or another one. Aha, that does seem to be my issue. In this web application, all requests are funneled through the same url (an .aspx page) and it sends back the right content (html or json) depending on the contents of the request.
I filed https://bugs.webkit.org/show_bug.cgi?id=68646 for that.
Old bug. Is this now complete w/ Bug 68646 ?
(In reply to comment #15) > Old bug. Is this now complete w/ Bug 68646 ? Yes, the JSON hierarchical view now works in all circumstances I have run across after completion of Bug 68646