Preview in network tab parsing response as JSON when HTML is returned

102 views
Skip to first unread message

Sondre Kjøniksen

unread,
Mar 3, 2015, 7:00:53 AM3/3/15
to google-chrome-...@googlegroups.com
When debugging AJAX calls in our web-applications we often dump variables server-side and abort/exit the request, this outputs the values as HTML and sets the response as text/html. However the preview in the network tab tries to parse the response as JSON, making it unreadable.

If we set the Status Code to be an error such as 503 (or any other errorcode), the response is properly parsed as HTML.

I would like to add that this has been working for a long time, and stopped working a while ago - maybe a month.

An example request:

Remote Address: *snip*
Request URL: *snip*
Request Method:POST
Status Code:200 OK

Request Headers
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8,nb;q=0.6,da;q=0.4
Connection:keep-alive
Content-Length:407
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie: *snip*
Host: *snip*
Origin: *snip*
Referer: *snip*
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-Requested-With:XMLHttpRequest

Form Data
argumentCollection:{"model":{"name":"","email":"","title":"","mobile":"","oldpassword":"","password":"","passwordrepeat":"","id":0,"accessRules":[2,8,11,13,14,10]},"options":{}}
method:update
returnformat:json
vfAjax:1

Response Headers
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Wed, 25 Feb 2015 09:12:38 GMT
Server:Microsoft-IIS/7.5
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:ASP.NET

Will show this in preview:



Is this intended behavior? I know the request headers states that application/json, text/javascript should be returned, but I would argue that the response headers should override how it should be previewed in the preview tab.

As you can see when the response has a 503 status code, the preview is shown correctly:

Remote Address: *snip*
Request URL: *snip*
Request Method:POST
Status Code:200 OK

Request Headers
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8,nb;q=0.6,da;q=0.4
Connection:keep-alive
Content-Length:407
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie: *snip*
Host: *snip*
Origin: *snip*
Referer: *snip*
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-Requested-With:XMLHttpRequest

Form Data
argumentCollection:{"model":{"name":"","email":"","title":"","mobile":"","oldpassword":"","password":"","passwordrepeat":"","id":0,"accessRules":[2,8,11,13,14,10]},"options":{}}
method:update
returnformat:json
vfAjax:1

Response Headers
Content-Encoding:gzip
Content-Type:text/html; charset=UTF-8
Date:Wed, 25 Feb 2015 09:12:38 GMT
Server:Microsoft-IIS/7.5
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Powered-By:ASP.NET



While it is not a huge overhead to have to set the response headers when debugging, it would be much easier if it was not required.

Thanks

Sondre Kjøniksen

unread,
Mar 3, 2015, 11:29:21 AM3/3/15
to google-chrome-...@googlegroups.com
I wrongfully wrote the same request twice in my original post, the second request with a 503 response was supposed to be like this:

Remote Address: *snip*
Request URL: *snip*
Request Method:POST
Status Code:503 Service Unavailable

Request Headers
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip, deflate
Accept-Language:en-US,en;q=0.8,nb;q=0.6,da;q=0.4
Connection:keep-alive
Content-Length:396
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
Cookie: *snip*
Host: *snip*
Origin: *snip*
Referer: *snip*
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36
X-Requested-With:XMLHttpRequest

Form Data
argumentCollection:{"model":{"id":0,"name":"","email":"","title":"","mobile":,"oldpassword":"","password":"","passwordrepeat":"","accessRules":[2,8,11,13,14,10]},"options":{}}
method:update
returnformat:json
vfAjax:1

Response Headers
Content-Type:text/html
Date:Tue, 03 Mar 2015 16:23:27 GMT
Server:Microsoft-IIS/7.5
Transfer-Encoding:chunked
X-Powered-By:ASP.NET

Adonaioc

unread,
Mar 3, 2015, 6:13:54 PM3/3/15
to google-chrome-...@googlegroups.com
I  am having the same issue, although it seems to be resolved in the canary build, I would love to know more about what is causing it.

Eugene Klyuchnikov

unread,
Mar 4, 2015, 3:12:27 AM3/4/15
to google-chrome-...@googlegroups.com
Some time ago we added new JSON(P) parser that understands JSON better than build-in JSON parser.
So we relaxed requirements and some non-JSON htmls were shown as object tree.

Recently we've added more restrictions and got less "false-positives".

Now I'm going to add one more guard to make behavior more expectable:


Best regards,
  Eugene.

Sondre Kjøniksen

unread,
Mar 4, 2015, 4:03:34 AM3/4/15
to google-chrome-...@googlegroups.com
Thank you very much for the insight.

Although I didn't think about Canary as Adonaioc mentioned, and I can see that it seems to be working there.

Regards
Sondre
Reply all
Reply to author
Forward
0 new messages