Bug 69972 - Spurious warnings when receiving HTTP response code 204
: Spurious warnings when receiving HTTP response code 204
Status: UNCONFIRMED
: WebKit
Web Inspector (Deprecated)
: 528+ (Nightly build)
: Other Linux
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2011-10-12 15:41 PST by
Modified: 2011-12-14 10:33 PST (History)


Attachments
My proposed patch to NetworkManager (853 bytes, patch)
2011-11-18 15:02 PST, rodarmor@google.com
no flags Review Patch | Details | Formatted Diff | Diff
Updated patch, hopefully conforms to submission guidelines. (2.16 KB, text/plain)
2011-12-09 14:06 PST, rodarmor@google.com
no flags Details
Updated patch, hopefully conforms to submission guidelines. (2.16 KB, patch)
2011-12-09 14:07 PST, rodarmor@google.com
no flags Review Patch | Details | Formatted Diff | Diff
ChangeLog now contains bug number. (2.22 KB, patch)
2011-12-09 14:15 PST, rodarmor@google.com
no flags Review Patch | Details | Formatted Diff | Diff
Patch (6.43 KB, patch)
2011-12-14 09:45 PST, Vsevolod Vlasov
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2011-10-12 15:41:41 PST
1. Open the console

2. Navigate to google.com

3. Observe the warning: "Resource interpreted as Other but transferred with MIME type undefined." 

(you can repeat the warning by entering https://clients1.google.com/generate_204 into the url bar)

I think what's going on here is that the code that generates the warning isn't checking for a 204 status code. As far as I can tell, since a 204 by definition doesn't have any content, this warning is unnecessary.  The relevant code is in:

/Source/WebCore/inspector/front-end/NetworkManager.js:_updateResourceWithResponse
------- Comment #1 From 2011-10-12 22:31:27 PST -------
See also: bug 60206.
------- Comment #2 From 2011-11-18 15:02:04 PST -------
Created an attachment (id=115880) [details]
My proposed patch to NetworkManager

Here's my proposed patch. Simply don't check for mime type consistency on 204 responses, since by definition they contain no data.
------- Comment #3 From 2011-12-09 14:06:15 PST -------
Created an attachment (id=118632) [details]
Updated patch, hopefully conforms to submission guidelines.
------- Comment #4 From 2011-12-09 14:07:07 PST -------
Created an attachment (id=118633) [details]
Updated patch, hopefully conforms to submission guidelines.
------- Comment #5 From 2011-12-09 14:11:59 PST -------
Attachment 118633 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1

Source/WebCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.
------- Comment #6 From 2011-12-09 14:15:25 PST -------
Created an attachment (id=118637) [details]
ChangeLog now contains bug number.
------- Comment #7 From 2011-12-11 09:34:44 PST -------
(From update of attachment 118637 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=118637&action=review

> Source/WebCore/inspector/front-end/NetworkManager.js:155
> +            || resource.statusCode === 204

I don't think this is specific to the 204. This check is basically testing whether the mime type returned with the HTTP response is consistent with the type WebKit assigned to the loaded resource. The actual bug is in line 142 above that prints this.type and this.mimeType instead of resource.type and resource.mimeType. Fixing it will uncover whether 204 needs special handling.
------- Comment #8 From 2011-12-13 14:31:38 PST -------
I'm reading over the code, and I can't see how this.type and this.mimeType are set at all. I know I've seen various different types come up in the warning message, however. Do you know where those values are being set?
------- Comment #9 From 2011-12-14 09:04:43 PST -------
(In reply to comment #8)
> I'm reading over the code, and I can't see how this.type and this.mimeType are set at all. I know I've seen various different types come up in the warning message, however. Do you know where those values are being set?

As I mentioned above, you should replace "this.mimeType" and "this.type" with "resource.mimeType" and "resource.type" to fix the actual problem.
------- Comment #10 From 2011-12-14 09:45:42 PST -------
Created an attachment (id=119235) [details]
Patch
------- Comment #11 From 2011-12-14 09:51:56 PST -------
(From update of attachment 119235 [details])
View in context: https://bugs.webkit.org/attachment.cgi?id=119235&action=review

> LayoutTests/ChangeLog:4
> +        Spurious warnings when receiving HTTP response code 204
> +        https://bugs.webkit.org/show_bug.cgi?id=69972

The test doesn't use 204 response code. How does it check that the bug is fixed?
------- Comment #12 From 2011-12-14 10:24:47 PST -------
(In reply to comment #11)
> (From update of attachment 119235 [details] [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=119235&action=review
> 
> > LayoutTests/ChangeLog:4
> > +        Spurious warnings when receiving HTTP response code 204
> > +        https://bugs.webkit.org/show_bug.cgi?id=69972
> 
> The test doesn't use 204 response code. How does it check that the bug is fixed?

Hm... Looks like there is a misunderstanding what is the actual bug here.
My patch is actually fixing the words "Other" and "undefined" in console message mentioned in the first post. This will make an original error message clear. 
I'll file another bug for that and upload my patch there.

Meanwhile I am not sure we should fix the original issue at all - I don't think images should be loaded with mime type text/html. rodarmor, why is that needed?
------- Comment #13 From 2011-12-14 10:29:24 PST -------
Filed: https://bugs.webkit.org/show_bug.cgi?id=74516
------- Comment #14 From 2011-12-14 10:33:13 PST -------
FWIW, I see a lot of these error messages on mail.google.com (can not reproduce on google.com). They are all about loading images without content and they have both 200 and 204 status codes.