Bug 28812 – provide request / response payload sizes in Resources panel

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Web Inspector

[Patrick Mueller]

Spawned from bug 22920, comment 25 .

Since the size of the payloads for requests and responses is not always available via the Content-Length header, perhaps we can provide a mechanism for users to see the actual values.  In addition, for cases where the resource data is slow to load, or large, showing the amount of data received/sent so far would be appropriate.

No real thoughts on how this might be shown to the user though.

[Jeroen Bensch]

Seems like the Request Payload for POST requests has made it in already.
But the Response Payload is not there yet. The way it's visualised I think could be done better (like expanding the little triangles by default) as well as making it clear on the left in the Resources column (maybe with arrows going in/out) whether this request is a GET or a POST.

[Patrick Mueller]

re: comment 1

I'm not quite sure what you're saying.  Are you talking about size indications for request/response payloads?  Typically these would be available in the normal HTTP header Content-Length, but of course that's not required.  This bug concerns figuring out how to get that size value and display it somewhere for the request and response payloads.  Where it would be displayed is yet another question.

I'm not seeing in anything in the comment concerning sizes.  I don't believe there is an explicit size calculation for request payloads, as could be inferred from the comment.

If you're talking about just the payload itself, the response payload has ALWAYS be available in the resources.  It's the big area underneath the new "HTTP Information(?)" etc headers.  So I'm not sure what you're asking for.

I read the last sentence as a request to make the HTTP method (GET or POST) also available in the Resources column on the left.  This seems liek it would the column too busy.  As an alternative, we could add these as additional selectors next to the current "All Documents Stylesheets ..." selectors.  Maybe with a divider between them or something.  Selectors for GET, POST and "other" or something.

If that's what you're talking about, create another bug.

[Jeroen Bensch]

(In reply to comment #2)

> If you're talking about just the payload itself, the response payload has
> ALWAYS be available in the resources.  It's the big area underneath the new
> "HTTP Information(?)" etc headers.  So I'm not sure what you're asking for.

Load this URL: http://www.lumacentral.com/CocaCola/index.html

And check the results for the execBatch resource. That's what I was testing with. I see a Request Payload, but the Response Payload turns out empty there. That's why I commented about the response payload and not the size.

[Patrick Mueller]

(In reply to comment #3)
> (In reply to comment #2)
> 
> > If you're talking about just the payload itself, the response payload has
> > ALWAYS be available in the resources.  It's the big area underneath the new
> > "HTTP Information(?)" etc headers.  So I'm not sure what you're asking for.
> 
> Load this URL: http://www.lumacentral.com/CocaCola/index.html
> 
> And check the results for the execBatch resource. That's what I was testing
> with. I see a Request Payload, but the Response Payload turns out empty there.
> That's why I commented about the response payload and not the size.

Is there supposed to be any content there?  curl says no - see below.  Of course, if we implemented an actual request/response paload length, this would be another indicator for the user.  curl is cheating a sending a Content-Length: 0 back that Web Inspector doesn't see.

$ curl -v http://www.lumacentral.com/CocaCola/w2p/execBatch
- About to connect() to www.lumacentral.com port 80 (#0)
-   Trying 194.78.34.228... connected
- Connected to www.lumacentral.com (194.78.34.228) port 80 (#0)
> GET /CocaCola/w2p/execBatch HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Host: www.lumacentral.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 05 Oct 2009 10:58:30 GMT
< Set-Cookie: JSESSIONID=C93C4621DE156F3BCFB23D188E71ABC1; Path=/CocaCola
< Content-Length: 0
< Content-Type: text/plain
< 
- Connection #0 to host www.lumacentral.com left intact
- Closing connection #0

[Jeroen Bensch]

(In reply to comment #4)

If you check execBatch (there are actually 2, I think that's another bug, you can only select the last one in WI) you'll see that the request payload is:

<lw2p-requests><lw2p-request action="findAllPortals" windowSize="0" startRow="0" countRows="0"/></lw2p-requests>

The response payload as HTTPFox detects it is (first part of it):

<?xml version="1.0" encoding="UTF-8"?>
<lw2p-replies><lw2p-reply action="findAllPortals" countRows="0"><portal description="" id="52" name="CocaCola" version="10"><profile id="83230" isDefault="true" name="Coca Cola"/>
...

The response is huge.

The first execBatch (unselectable in WI) has as request: 

<lw2p-requests>
<lw2p-request action="getCurrentPortal"/>
</lw2p-requests>

Response (HTTPFox):

<?xml version="1.0" encoding="UTF-8"?>
<lw2p-replies><lw2p-reply action="getCurrentPortal"><portal description="" id="52" name="CocaCola" version="10"/></lw2p-reply></lw2p-replies>

You are obviously the better bugzilla-er so maybe this should be spawning a new bug because it obviously hasn't got anything to do with the sizes.

[Patrick Mueller]

(In reply to comment #5)

OK, I see there are several problems.  

1) In general, at least for this site, XML responses aren't shown where you expect them.  Note that the execBatch response I can see has a Content-Type: text/plain and Mime-Type: application/xml.  As far as I know, the Mime-Type header should be ignored - it doesn't appear to be a standard HTTP 1.1 header - so you won't get nice looking output for it anyway.

2) some resources are unselectable - the execBatch ones in this case.  Per your notes, they seem to be using the same URL and method, and only differ by the request payload

Does that sound right?

BTW, my curl request from comment 4 wasn't valid - it was a GET, and the one at the site is a POST.  Here's a better one, that actually returns some content:

$ curl -H "Content-Type: application/xml" -d "<lw2p-requests><lw2p-request action='getCurrentPortal'/></lw2p-requests>" -v http://www.lumacentral.com/CocaCola/w2p/execBatch
- About to connect() to www.lumacentral.com port 80 (#0)
-   Trying 194.78.34.228... connected
- Connected to www.lumacentral.com (194.78.34.228) port 80 (#0)
> POST /CocaCola/w2p/execBatch HTTP/1.1
> User-Agent: curl/7.16.3 (powerpc-apple-darwin9.0) libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
> Host: www.lumacentral.com
> Accept: */*
> Content-Type: application/xml
> Content-Length: 72
> 
< HTTP/1.1 200 OK
< Date: Mon, 05 Oct 2009 15:36:37 GMT
< Cache-Control: no-cache
< Set-Cookie: JSESSIONID=49ACA557EE891188BDB2B334CF2B4B7E; Path=/CocaCola
< mime-type: application/xml
< Transfer-Encoding: chunked
< Content-Type: text/plain
< 
<?xml version="1.0" encoding="UTF-8"?>
- Connection #0 to host www.lumacentral.com left intact
- Closing connection #0
<lw2p-replies><lw2p-reply action="getCurrentPortal"><portal description="" id="52" name="CocaCola" version="10"/></lw2p-reply></lw2p-replies>

[Radar WebKit Bug Importer]

<rdar://problem/15801498>

[Joseph Pecoraro]

With Bug 155112 Web Inspector will have all of the data we need to show the sizes in Web Inspector. I'll keep this open to track showing the sizes in Web Inspector somewhere.

[Blaze Burg]

This has been in Network tab for some releases now, closing.