Duplicated response headers are not parsed correctly
Reported by
kdzwinel@gmail.com,
Feb 15 2018
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3347.0 Safari/537.36 Steps to reproduce the problem: 1. Go to https://httpbin.org/response-headers?Link=%3Chttp://www.example.com/downloads/white-paper.pdf%3E;%20rel=%22canonical%22&Link=%3Chttp://example.com%3E;rel=%22alternate%22;hreflang=%22xx%22 2. Open DevTools > Network 3. Reload page 4. Look at the response headers of the main request What is the expected behavior? Two 'Link' headers should be listed What went wrong? Only later of the two 'Link' headers is listed Did this work before? Yes It works in stable, but I'm pretty sure it also worked couple of days ago in canary Chrome version: 66.0.3347.0 Channel: n/a OS Version: OS X 10.13.3 Flash Version: Clicking 'view header' next to 'response headers' shows a correct value with two 'Link's This is not a DevTools front-end issue, but rather something in the protocol (we observed this issue while working on Lighthouse - https://github.com/GoogleChrome/lighthouse/pull/4475#issuecomment-365911075 ).
,
Feb 15 2018
,
Feb 16 2018
Able to reproduce this issue on reported version 66.0.3347.0 using Mac 10.13.3, windows 10 and Ubuntu 14.04 with link given in comment#0. i.e;Seeing only one "Link" in Response Headers section. Good Build: 66.0.3346.0 Bad Build: 66.0.3347.0 You are probably looking for a change made after 536401 (known good), but no later than 536402 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/da651de72deefafe29d81c522234a2557475cc2b..30f8822a37972aabd4b76d4559d1062d6799c9cb Reviewed-on: https://chromium-review.googlesource.com/912400 Suspecting same from changelog. @caseq: Please check the issue and help in re-assigning if this is not related to your change. Adding RB-Stable as this is recent regression. Please change if not the case.
,
Feb 16 2018
,
Feb 16 2018
,
Feb 21 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f17f98581af869486600cf6cd53b6b07e5bddd2a commit f17f98581af869486600cf6cd53b6b07e5bddd2a Author: Andrey Kosyakov <caseq@chromium.org> Date: Wed Feb 21 04:00:09 2018 DevTools: fix concatenation of HTTP headers with same name when reporting from browser This used to be done in renderer and we missed it while migrating instrumentation to the browser. Bug: 812592 Change-Id: Idd661541bbcd9b4ce6ab40b00c56094de7b6a8eb Reviewed-on: https://chromium-review.googlesource.com/924502 Commit-Queue: Andrey Kosyakov <caseq@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#538017} [modify] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/content/browser/devtools/protocol/network_handler.cc [add] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/third_party/WebKit/LayoutTests/flag-specific/site-per-process/http/tests/inspector-protocol/network/multiple-headers-expected.txt [modify] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/data-url-status-expected.txt [modify] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/data-url-status.js [add] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/multiple-headers-expected.txt [add] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/multiple-headers.js [add] https://crrev.com/f17f98581af869486600cf6cd53b6b07e5bddd2a/third_party/WebKit/LayoutTests/http/tests/inspector-protocol/network/resources/multiple-headers.php
,
Mar 19 2018
Tested this issue on Windows 7 & Mac 10.13.3 using chrome latest Canary-67.0.3374.0, dev-67.0.3371.0 & beta-66.0.3359.33 as per C#0. Observed 2 header links in response header in Dev tools.Hence addinh TE Verified labels. Please find the attached screencast & screenshot for reference. Thanks..!
,
Mar 26 2018
As it is WAI on M67, could you please merge the fix to M66 if it is safe merge. Thanks..~
,
Apr 2 2018
Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks!
,
Apr 9 2018
Friendly ping to get an update on this issue as it is marked stable blocker & M66 Stable cut is on April 12th. Thanks..!
,
Apr 9 2018
Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug.
,
Apr 16 2018
Gentle ping to get an update on this issue ASAP as M66 stable release is tomorrow and this bug is marked as stable blocker. Thanks..!
,
Apr 16 2018
,
Apr 16 2018
This bug requires manual review: We are only 0 days from stable. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 16 2018
Approving this merge for 66. Branch:3359
,
Apr 16 2018
We discussed this with abdulsyed@ and decided not to merge to m66 given short time before the release, the relatively low severity of the bug and the fact that this would require a manual rebase (i.e. the fix does not merge automatically due to merge conflicts). Also removing RB-S from this isssue.
,
Apr 16 2018
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by kdzwinel@gmail.com
, Feb 15 2018213 KB
213 KB View Download
187 KB
187 KB View Download