LGTM2
On 9/3/23 8:12 PM, Yoav Weiss wrote:
LGTM1
On Mon, Sep 4, 2023 at 2:24 AM Kenichi Ishibashi <ba...@chromium.org>
wrote:
Hi, sorry for the long delay.
The feature page
<https://chromestatus.com/metrics/feature/timeline/popularity/4470>
now shows sites that use Authorization header for cross-origin
redirects. I randomly picked some of them and examined to see if
they could work when Chrome removes Authorization header up on
cross-origin redirects. As far as I can tell, none of them are
broken. We would like to ship this behind a feature flag.
Thanks for the analysis!
As you pointed out elsewhere, since our previous discussions on this
thread, this was shipped
<https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=stable&label=master&aligned>
by Firefox and Safari.
I think that changes the risk calculus (from compat to interop) and
makes shipping this (with a base feature just in case) the right choice.
Thanks,
On Fri, Sep 1, 2023 at 1:39 AM Ioan-Cristian Linte
<linte.ioan.crist...@gmail.com> wrote:
Any updates on this?
Other browser have already made the change for some time so
it's surprising that Chrome is so worried about breaking change.
The Authorization propagating in cross origin redirects is
causing a performance issue for us. Our server redirects to
AWS S3 with pre-signed url and this will return 400 error as
AWS S3 disallows specifying multiple authorizations (e.g.
signature in url and Authorization header) in a request. Also
the 400 error response includes a close connection header. To
make this work, the web client checks for the 400 error and
uses the response.url to make a new fetch request without the
Authorization header. Because the previous connection was
closed this incurs the cost of initiating a new connection.
On Wednesday, June 28, 2023 at 6:34:42 PM UTC+3 Yoav Weiss wrote:
Friendly ping! :) Any news on UKM data here?
On Wednesday, April 5, 2023 at 10:53:41 AM UTC+2 Yoav
Weiss wrote:
Sounds great, thanks!! :)
On Wed, Apr 5, 2023 at 10:44 AM Kenichi Ishibashi
<ba...@chromium.org> wrote:
Hi Yoav,
Sorry I haven't sent an update in this thread. (1)
sounds reasonable. I added the usercounters to UKM
a few weeks ago and I'm waiting for data. I will
report back after manual inspections are done.
Thanks,
On Wed, Apr 5, 2023 at 5:14 PM Yoav Weiss
<yoav...@chromium.org> wrote:
Friendly ping on the above :) Does (1)
sound reasonable from your perspective?
On Wed, Mar 15, 2023 at 7:16 PM Yoav Weiss
<yoav...@chromium.org> wrote:
The way I see this, given that the
usecounter is an order of magnitude higher
than what we can consider trivial, we have
3 options:
1) Add the usecounters to UKM
<https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=32?q=usecounters%20ukm&ss=chromium>,
run an analysis on early data to extract
URLs that use this, and randomly sample
those for manual inspection.
2) Wait for the HTTPArchive crawl to run
with this usecounter, assuming that
unauthed landing pages will trigger it.
3) Run an HA query that tries to find
cross-origin redirects with Auth headers.
I'm not sure how easy (or feasible) that
would be, but Rick and Pat would know
To me, (1) seems to be the easiest, and
with the least amount of potential bias
(all pages vs. unauthed landing pages).
On Tue, Mar 14, 2023 at 9:45 PM Patrick
Meenan <pme...@chromium.org> wrote:
Do we expect the Authorization header
to be something that the HTTP Archive
triggers in a way that the feature
will trigger? Since they are all
unauthenticated single page loads, it
feels like it's unlikely to be
something that we hit.
On Tue, Mar 14, 2023 at 4:37 PM
Patrick Meenan <pme...@chromium.org>
wrote:
Looks like the feature flag was
added Feb 16
<https://chromium-review.googlesource.com/c/chromium/src/+/4235597> which
looks like it should have made the
112 branch point
<https://chromiumdash.appspot.com/schedule>.
If we hold the April crawl back a
couple of days and start it on the
4th after stable is released then
we can pick it up in April,
otherwise it would show up mid-crawl.
On Tue, Mar 14, 2023 at 4:24 PM
Rick Viscomi <rvis...@google.com>
wrote:
Am I reading the feature page
<https://chromestatus.com/feature/5195900413018112> correctly
that it'll land in stable
version 113? If so, HTTP
Archive wouldn't pick that up
until the May crawl.
cc @Patrick Meenan to keep me
honest
On Mon, Mar 13, 2023 at
12:19 AM Yoav Weiss
<yoav...@chromium.org> wrote:
It's possible that we need
to wait for the next HA
run to get actual examples.
+Rick Viscomi would know..
On Mon, Mar 13, 2023 at
12:28 AM Kenichi Ishibashi
<ba...@chromium.org> wrote:
Thank you Yoav for the
suggestion. I couldn't
find sample URLs from
the HTTPArchive data
(feature usage
<https://chromestatus.com/metrics/feature/timeline/popularity/4470>).
I'll add a feature
flag to prepare for
reverting this change
if breakage is
problematic.
On Fri, Mar 10, 2023
at 7:06 PM Yoav Weiss
<yoav...@chromium.org>
wrote:
One option to
tighten the
potential for
breakage would be
to e.g. sample 10
URLs that are
hitting that
usecounter (e.g.
from the
HTTPArchive data),
and test them
manually to see
how many of them
would break once
this change is
applied. Based on
the number you'd
get, we can
estimate the
magnitude of
breakage we can
expect to see in
the wild.
Another option
would be to roll
this out with a
base feature flag
(that we'd want
anyway) and be
ready to revert if
breakage is more
than we'd like.
Combining those
two options is
probably safest.
On Fri, Mar 10,
2023 at 8:51 AM
Kenichi Ishibashi
<ba...@chromium.org>
wrote:
Use counter
reports
0.022%. My
guess is that
most usage
happens
accidentally
but we are not
sure.
API owners,
should we do a
reverse OT?
On Fri, Feb
17, 2023 at
9:38 AM
Kenichi
Ishibashi
<ba...@chromium.org>
wrote:
Quick
update, we
added a
use
counter to
see how
often this
could happen.
I'll get
back once
we have data.
On Wed,
Feb 8,
2023 at
11:51 PM
Yoav Weiss
<yoav...@chromium.org>
wrote:
Any
use
counters
on how
often
this
happens?
On
Thursday,
February
2,
2023
at
8:58:35
AM
UTC+1
Kenichi
Ishibashi
wrote:
Contact
emailsba...@chromium.org
Specificationhttps://fetch.spec.whatwg.org/#http-redirect-fetch
<https://fetch.spec.whatwg.org/#http-redirect-fetch>
Summary
Remove
Authorization
header
on
cross
origin
redirects
to
scope
a
developer-controlled
Authorization
header
to the
origin
of the
initial
request.
Blink
componentBlink>Loader
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELoader>
TAG
review
Not
applicable,
the
spec
has
been
already
updated.
https://github.com/whatwg/fetch/pull/1544
<https://github.com/whatwg/fetch/pull/1544>
TAG
review
statusNot
applicable
Risks
Interoperability
and
Compatibility
Low.
All
browser
vendors
agreed
with
this
change.
/Gecko/:
Shipping
(https://bugzilla.mozilla.org/show_bug.cgi?id=1802086
<https://bugzilla.mozilla.org/show_bug.cgi?id=1802086>)
Do we
know
if
they
ran
into
any
compat
issues
when
shipping
this?
None I'm
aware of.
I checked
the bug
and
related
issues in
GitHub but
I didn't
find anything.
/WebKit/:
Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=230935
<https://bugs.webkit.org/show_bug.cgi?id=230935>)
Historically
Safari
always
removed
Authorization
headers
even
for
the
same
origin
redirects.
Recently
the
behavior
has
changed
to
preserve
them
on
same
origin
redirects.
That's
encouraging
in
terms
of
lack
of
potential
reliance
on
these
headers.
/Web
developers/:
No signals
/Other
signals/:
WebView
application
risks
N/A
Debuggability
Web
Developers
can
use
DevTools
network
panel
to see
the
actual
request
headers.
Will
this
feature
be
supported
on all
six
Blink
platforms
(Windows,
Mac,
Linux,
Chrome
OS,
Android,
and
Android
WebView)?Yes
Is
this
feature
fully
tested
by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?Yes
https://wpt.fyi/results/xhr/xhr-authorization-redirect.any.html?label=master&label=experimental
<https://wpt.fyi/results/xhr/xhr-authorization-redirect.any.html?label=master&label=experimental>
https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=experimental
<https://wpt.fyi/results/fetch/api/credentials/authentication-redirection.any.html?label=experimental>
Flag
nameNot
applicable
Requires
code
in
//chrome?False
Tracking
bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1393520
<https://bugs.chromium.org/p/chromium/issues/detail?id=1393520>
Estimated
milestones
M112
Anticipated
spec
changes
The
spec
has
been
already
updated.
https://github.com/whatwg/fetch/issues/944
<https://github.com/whatwg/fetch/issues/944>
Link
to
entry
on the
Chrome
Platform
Statushttps://chromestatus.com/feature/5195900413018112
<https://chromestatus.com/feature/5195900413018112>
This
intent
message
was
generated
by
Chrome
Platform
Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWf-jyg-N2Y%2BuGXp6aWAHZA%2BifqOw_Cki7M3UaV1QV9Cg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01f78357-99e8-4233-8125-1233bd8bc786%40chromium.org.
