WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
69972
Spurious warnings when receiving HTTP response code 204
https://bugs.webkit.org/show_bug.cgi?id=69972
Summary
Spurious warnings when receiving HTTP response code 204
rodarmor
Reported
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
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
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2011-10-12 22:31:27 PDT
See also:
bug 60206
.
rodarmor
Comment 2
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.
rodarmor
Comment 3
2011-12-09 14:06:15 PST
Created
attachment 118632
[details]
Updated patch, hopefully conforms to submission guidelines.
rodarmor
Comment 4
2011-12-09 14:07:07 PST
Created
attachment 118633
[details]
Updated patch, hopefully conforms to submission guidelines.
WebKit Review Bot
Comment 5
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.
rodarmor
Comment 6
2011-12-09 14:15:25 PST
Created
attachment 118637
[details]
ChangeLog now contains bug number.
Pavel Feldman
Comment 7
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.
rodarmor
Comment 8
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?
Pavel Feldman
Comment 9
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.
Vsevolod Vlasov
Comment 10
2011-12-14 09:45:42 PST
Created
attachment 119235
[details]
Patch
Alexey Proskuryakov
Comment 11
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?
Vsevolod Vlasov
Comment 12
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?
Vsevolod Vlasov
Comment 13
2011-12-14 10:29:24 PST
Filed:
https://bugs.webkit.org/show_bug.cgi?id=74516
Vsevolod Vlasov
Comment 14
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.
Brian Burg
Comment 15
2014-12-13 18:38:41 PST
This warning does not seem to exist any more.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug