Bug 69972 - Spurious warnings when receiving HTTP response code 204
: Spurious warnings when receiving HTTP response code 204
Status: RESOLVED INVALID
Product: WebKit
Classification: Unclassified
Component: Web Inspector (Deprecated)
: 528+ (Nightly build)
: Other Linux
: P2 Normal
Assigned To: Vsevolod Vlasov
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-12 15:41 PDT by rodarmor
Modified: 2014-12-13 18:38 PST (History)
8 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description rodarmor 2011-10-12 15:41:41 PDT
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 Alexey Proskuryakov 2011-10-12 22:31:27 PDT
See also: bug 60206.
Comment 2 rodarmor 2011-11-18 15:02:04 PST
Created attachment 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 rodarmor 2011-12-09 14:06:15 PST
Created attachment 118632 [details]
Updated patch, hopefully conforms to submission guidelines.
Comment 4 rodarmor 2011-12-09 14:07:07 PST
Created attachment 118633 [details]
Updated patch, hopefully conforms to submission guidelines.
Comment 5 WebKit Review Bot 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 rodarmor 2011-12-09 14:15:25 PST
Created attachment 118637 [details]
ChangeLog now contains bug number.
Comment 7 Pavel Feldman 2011-12-11 09:34:44 PST
Comment on attachment 118637 [details]
ChangeLog now contains bug number.

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 rodarmor 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 Pavel Feldman 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 Vsevolod Vlasov 2011-12-14 09:45:42 PST
Created attachment 119235 [details]
Patch
Comment 11 Alexey Proskuryakov 2011-12-14 09:51:56 PST
Comment on attachment 119235 [details]
Patch

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 Vsevolod Vlasov 2011-12-14 10:24:47 PST
(In reply to comment #11)
> (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?

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 Vsevolod Vlasov 2011-12-14 10:29:24 PST
Filed: https://bugs.webkit.org/show_bug.cgi?id=74516
Comment 14 Vsevolod Vlasov 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.
Comment 15 Brian Burg 2014-12-13 18:38:41 PST
This warning does not seem to exist any more.