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.ioa...@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+...@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>.
