Status Update
No update yet.
Comments
fu...@gmail.com
sorry, mistake with versions.
issue only with latest version 74, all other/older version works.
issue only with latest version 74, all other/older version works.
dt...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: -Blink Internals>Network]
[Monorail components: -Blink Internals>Network]
mm...@chromium.org
The only change I'm aware of that can result in ERR_INVALID_HTTP_RESPONSE is that we no longer allow nulls in headers. While sending unescaped internationalized characters certainly violates spec, we should still allow it.
va...@chromium.org
[Empty comment from Monorail migration]
va...@chromium.org
Thanks for filing the issue!
Able to reproduce the issue on reported chrome version 72.0.3626.81 and on the latest canary 74.0.3689.0 using Windows 10, Ubuntu 14.04 and Mac 10.14.1
Bisect Information:
--------------------
Good Build: 72.0.3588.0
Bad Build: 72.0.3589.0
You are probably looking for a change made after 601775 (known good), but no later than 601776 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/4213dae85d26ae46cbf108f884113749ee832bb5..900336ff53907fb0263941689ee734103f0ad352
Suspecting:https://chromium.googlesource.com/chromium/src/+/900336ff53907fb0263941689ee734103f0ad352
Review URL:https://chromium-review.googlesource.com/c/1291812
@ Matt Menke: Please help in assigning it to the right owner, if this isn't related to your change. Adding RB-Stable as this seems to be a recent regression, please remove if not required.
Able to reproduce the issue on reported chrome version 72.0.3626.81 and on the latest canary 74.0.3689.0 using Windows 10, Ubuntu 14.04 and Mac 10.14.1
Bisect Information:
--------------------
Good Build: 72.0.3588.0
Bad Build: 72.0.3589.0
You are probably looking for a change made after 601775 (known good), but no later than 601776 (first known bad).
CHANGELOG URL:
Suspecting:
Review URL:
@ Matt Menke: Please help in assigning it to the right owner, if this isn't related to your change. Adding RB-Stable as this seems to be a recent regression, please remove if not required.
fu...@gmail.com
i retested it with different chromium versions:
until chromium v71 it works (tested with build 591486 / version 71.0.3553.0)
starting with v72 problem occurs (tested with builds: 607560 / 616900 / and latest)
until chromium v71 it works (tested with build 591486 / version 71.0.3553.0)
starting with v72 problem occurs (tested with builds: 607560 / 616900 / and latest)
mm...@chromium.org
I'll double check later today, to make sure there isn't anything unexpected going on, but if it's indeed a null character in the header, I don't think we want to revert the change unless the change in Chrome unless is much more widespread. Unfortunately, while there's not any specific known issue around it, nulls in plain text protocols are pretty problematic, and something that can quite easily go horribly wrong. Even with H2, which fixes the plain text protocol part of transferring header themselves, data within individual headers are still treated as plain text strings.
This change was made in consultation with FireFox engineers, though I can't guarantee that they will be making the same change to FireFox.
This change was made in consultation with FireFox engineers, though I can't guarantee that they will be making the same change to FireFox.
mm...@chromium.org
"don't want to revert the change in Chrome unless this causes much more widespread issues", rather.
fu...@gmail.com
thanks for the debugging, we talked to the WAF manufacturer, they will fix the null chars in the headers.
mm...@chromium.org
I've confirmed the ERR_INVALID_HTTP_RESPONSE is because of a null in a Set-Cookie line (I don't think we actually allow nulls in cookies in the first place, actually).
I'm not sure what's going on with the ERR_SPDY_PROTOCOL_ERROR - the check I added currently only covers the HTTP/1.x path. It looks like we're getting a RESET from with a PROTOCOL_ERROR from the server, so I think it's probably unrelated. If you think it's a Chrome issue, feel free to file a new bug about that, and if you email me the ID, or post the bug ID here, I'll see it's routed appropriately. Let's keep the bug restricted to the ERR_INVALID_HTTP_RESPONSE issue.
I'm going to leave this bug open, so others who run into this issue can discover it, and related reports can be merged into it, but I expect to WontFix this in a month or so, unless we get a lot more reports.
I'm not sure what's going on with the ERR_SPDY_PROTOCOL_ERROR - the check I added currently only covers the HTTP/1.x path. It looks like we're getting a RESET from with a PROTOCOL_ERROR from the server, so I think it's probably unrelated. If you think it's a Chrome issue, feel free to file a new bug about that, and if you email me the ID, or post the bug ID here, I'll see it's routed appropriately. Let's keep the bug restricted to the ERR_INVALID_HTTP_RESPONSE issue.
I'm going to leave this bug open, so others who run into this issue can discover it, and related reports can be merged into it, but I expect to WontFix this in a month or so, unless we get a lot more reports.
mm...@chromium.org
A RESET frame with a PROTOCOL_ERROR, rather.
ch...@chromium.org
[Empty comment from Monorail migration]
mm...@chromium.org
[Empty comment from Monorail migration]
me...@google.com
In my opinion the fix of https://crbug.com/chromium/832086 is correct behavior that we should keep as allowing nulls in headers is terrible and non spec compliant.
mm...@chromium.org
The other two linked issues look like more serious breakages: The official government site for Albania, and firmware on some subset of Netgear devices have badly malformed HTTP headers.
go...@chromium.org
+ abdulsyed@ & djmm@ (M72 TPM for Chrome Desktop and Chrome OS). Adding "RBS" for tracking based on https://crbug.com/chromium/927364#c16 .
mmenke@, pls apply all applicable OSs.
mmenke@, pls apply all applicable OSs.
mm...@chromium.org
[Empty comment from Monorail migration]
mm...@chromium.org
The iOS impact here is *probably* pretty minimal, since most requests use Safari's network stack.
dj...@google.com
[Empty comment from Monorail migration]
bh...@google.com
Is Chrome going to halt the current stable on this? Or is this something to be picked up in a later stable respin?
mm...@chromium.org
Currently there are no plans to revert this change. Nulls in the middle of HTTP headers aren't really a great thing for servers to be sending to us.
go...@chromium.org
Based #22, this is not M72 stable blocker for further roll out, correct?
mm...@chromium.org
I don't think that it is - I think it avoids potential security issues, and we can't delay because of the Netgear issue, since they have no update story - their devices will continue to run the problematic firmware indefinitely.
go...@chromium.org
+ Enterprise (TL, TPM and PM)
mm...@chromium.org
For any server operators running into this issue, the way to fix for this is just to not send any null characters ('\0') in HTTP response headers. You're most likely sending nulls in error. Make sure you're appending your strings correctly, and providing the correct string lengths to socket and string concatenation APIs.
mm...@chromium.org
[Comment Deleted]
mm...@chromium.org
Sorry, wrong issue.
mm...@chromium.org
[Empty comment from Monorail migration]
ge...@chromium.org
[Empty comment from Monorail migration]
be...@chromium.org
[Empty comment from Monorail migration]
mm...@chromium.org
[Empty comment from Monorail migration]
mm...@chromium.org
Sorry for the double name change - think we definitely want the error code in the title, though.
rb...@google.com
Friendly ping! Could you please provide any update on this issue as it has been marked as a stable blocker.
Thank You!
Thank You!
mm...@chromium.org
There is no update or plan to revert (Talked to abdulsyed about this, around the time the label was applied). Per https://crbug.com/chromium/927364#c17 , govind marked this RBS for tracking purposes.
na...@greenvilleschools.us
Similar issue here - case 18376214
mm...@chromium.org
[nadams]: That doesn't look to be either an internal Google bug number, nor a Chromium bug number. Mind giving just a little more detail?
Looks likehttps://e-albania.al/ has been fixed.
Looks like
ke...@gmail.com
Version: 72.0.3626.81
Google Chrome open
Mobile Application (Web View) (ERR_INVALID_HTTP_RESPONSE)
After the update version: 72.0.3626.105 the application work correctly.
Google Chrome open
Mobile Application (Web View) (OK)
Thanks
mm...@chromium.org
kejvidoko: It wasn't a Chrome change that made e-albania.al work again. They must have fixed the issue on their end - there was a bug in the HTTP response they were sending it. Chrome stopped accepting HTTP responses with a certain invalid character in them, since it never handled them properly, and the HTTP specification never allowed them.
bh...@google.com
If we are not going to block stable on this, can we drop the RBS label?
na...@greenvilleschools.us
[Comment Deleted]
mm...@chromium.org
As with the other cases, this is a server-side bug. It's sending us an HTTP header:
HNIS_AuthzInfo=\x01\x00; Path=/
It's not really clear what it expects us to do with the \x00 (The \x01 also violates spec, but we allow). Chrome's behavior when nulls are in response headers was previously undefined and untested, and the spec has never allowed them, so with Chrome 72 we started hard failing requests when we see them.
HNIS_AuthzInfo=\x01\x00; Path=/
It's not really clear what it expects us to do with the \x00 (The \x01 also violates spec, but we allow). Chrome's behavior when nulls are in response headers was previously undefined and untested, and the spec has never allowed them, so with Chrome 72 we started hard failing requests when we see them.
ma...@google.com
[Empty comment from Monorail migration]
ab...@google.com
[Empty comment from Monorail migration]
ab...@google.com
Marking this bug as WontFix. As mentioned in the comments above by mmenke@, this a server side bug and not Chrome. Please look at #42.
ha...@google.com
[Empty comment from Monorail migration]
ha...@google.com
[Empty comment from Monorail migration]
ha...@google.com
[Empty comment from Monorail migration]
Description
Example URL:
Steps to reproduce the problem:
1. newest version 72 needed, older ones work.
2. open
3. ERR_INVALID_HTTP_RESPONSE appears.
What is the expected behavior?
redirect should work.
on all other browsers the service with redirect works an it exists a long time. old chromium works, but new v72 gets the error.
the login service is managed by a WAF, this WAF appliance creates the redirects.
What went wrong?
redirect fails: ERR_INVALID_HTTP_RESPONSE
Does it occur on multiple sites: Yes
Is it a problem with a plugin? No
Did this work before? Yes until v71 it works
Does this work in other browsers? Yes
Chrome version: 72.0.3626.81 Channel: stable
OS Version: 10.0
Flash Version:
we already talked to WAF support. but they are also investigating the issue.