Quic doesn't accept cross-origin Http2 server push |
|||||||||
Issue descriptionChrome Version: Version 62.0.3202.62 (Official Build) (64-bit) OS: gLinux What steps will reproduce the problem? (1) Start Chrome with below commandline to ask it to use Flywheel proxy: google-chrome --ignore-certificate-errors --disable-fre --clear-cookies --clear-cache --disable-default-apps --no-experimes --no-first-run --user-data-dir=/tmp/chrometmp --enable-spdy-proxy-auth --data-reduction-proxy-experiment=test_nano_redirect_push (2) Go to http://googleweblight.com/i?u=http://mahresult.nic.in, Chrome should receive pushed http://mahresult.nic.in (3) Go to chrome://net-internals, check QUIC session of proxy.googlezip.net, you can see QUIC_SESSION_RST_STREAM_FRAME_SENT with error message QUIC_UNAUTHORIZED_PROMISE_URL, after receiving the PUSH_PROMISE from Flywheel, and thus the pushed resource is then rejected. What is the expected result? - Quic should accept the pushed resource. What happens instead? - Quic closes the serverpush stream. Please use labels and text to provide additional information. For graphics-related bugs, please copy/paste the contents of the about:gpu page at the end of this report.
,
Oct 24 2017
,
Oct 24 2017
,
Oct 24 2017
,
Nov 2 2017
can you clarify why Chrome should do that? Is that what the spec says?
,
Nov 2 2017
,
Nov 2 2017
,
Nov 2 2017
+bnc, zhongyi Discussed with rch@ and realized the issue is that QUIC's cross-origin logic isn't aware of trusted proxies. The analogous code in HTTP/2 does support them: https://codesearch.chromium.org/chromium/src/net/spdy/chromium/spdy_session.cc?rcl=9dbb222fa1919414fb9b799fa80fee5db77407a1&l=1587 It probably makes sense to lift that code into a helper that can be re-used by QUIC.
,
Jan 23 2018
Refreshed during triage.
,
Mar 21 2018
Refreshed during triage.
,
Sep 21
Not needed right now. Lets reopen if there is a need. |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by tbansal@chromium.org
, Oct 24 2017