Intent to Ship: Private Network Access preflight requests for subresources

894 views
Skip to first unread message

Titouan Rigoudy

unread,
Nov 29, 2021, 10:37:24 AM11/29/21
to blink-dev

Contact emails

tit...@chromium.orgva...@chromium.orgcl...@chromium.org

Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access/

Design docs


https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for subresources, asking for explicit permission from the target server. A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Pending

Risks



Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do not implement this. Compat risk is straightforward: web servers that do not handle the new preflight requests will eventually break, once the feature ships. The plan to address this is as follows: 1. Send preflight request, ignore result, always send actual request. Failed preflight requests will result in a warning being shown in devtools. 2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time. 4. End deprecation trial 4 milestones later. UseCounters: https://chromestatus.com/metrics/feature/timeline/popularity/3753 https://chromestatus.com/metrics/feature/timeline/popularity/3755 https://chromestatus.com/metrics/feature/timeline/popularity/3757 The above measure pages that make at least one private network request for which we would now send a preflight request.



Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/143)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html) Pending response.

Web developers: No signals Anecdotal evidence so far suggests that most web developers are OK with this new requirement, though some do not control the target endpoints and would be negatively impacted.

Other signals:

Ergonomics

None.



Activation

Gating access to the private network overnight on preflight requests would likely result in widespread breakage. This is why the plan is to first send requests but not act on their result, giving server developers time to implement code handling these requests. Deprecation warnings will be surfaced in DevTools to alert web/client developers when the potential for breakage later on is detected. Enforcement will be turned on later (aiming for 3 milestones), along with a deprecation trial for impacted web developers to buy themselves some more time. Experience suggests a large fraction of developers will not notice the advance deprecation warnings until things break.



Security

This change aims to be security-positive, preventing CSRF attacks against soft and juicy targets such as router admin interfaces. DNS rebinding threats were of particular concern during the design of this feature: https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9



Debuggability

Relevant information (client and resource IP address space) is already piped into the DevTools network panel. Deprecation warnings and errors will be surfaced in the DevTools issues panel explaining the problem when it arises.



Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://github.com/WICG/private-network-access/blob/main/HOWTO.md

Flag name

PrivateNetworkAccessRespectPreflightResults

Requires code in //chrome?

False

Tracking bug

https://crbug.com/591068

Launch bug

https://crbug.com/1274149

Estimated milestones

DevTrial on desktop98
DevTrial on android98


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5737414355058688

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ


This intent message was generated by Chrome Platform Status.

Joe Medley

unread,
Nov 30, 2021, 3:27:58 PM11/30/21
to Titouan Rigoudy, blink-dev
Titouan,

Will the default for the runtime flag be 'Enabled' in 98?

The DevTrial number should reflect when the flag was first available. 'Shipping' refers to when it can be used in production without web developers or users doing anything. This can mean the flag was removed or it can mean the flag's default was changed to 'Enabled'.

Joe
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


--
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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com.

Erik Anderson

unread,
Nov 30, 2021, 5:42:39 PM11/30/21
to Titouan Rigoudy, blink-dev

Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?

 

I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.

 

I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.

 

The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?

--

Titouan Rigoudy

unread,
Dec 1, 2021, 6:09:28 AM12/1/21
to Erik Anderson, blink-dev
Thanks for the responses!

Joe: the `PrivateNetworkAccessSendPreflights` feature flag will be enabled by default in M98 (if this intent gets 3 LGTMs). The `PrivateNetworkAccessRespectPreflightResults` will be enabled by default later, I am aiming for M101.

On Tue, Nov 30, 2021 at 11:42 PM Erik Anderson <Erik.A...@microsoft.com> wrote:

Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?


That is correct.
 

I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.

 

I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.


If they indeed use either top-level or iframe navigations, then they will be unaffected by this change.
 

The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?


I don't have a very clear timeline yet, but I wish to tackle nested navigations in particular in M100.

Cheers,
Titouan

Yoav Weiss

unread,
Dec 1, 2021, 7:22:41 AM12/1/21
to blink-dev, Titouan Rigoudy


On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote:


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access/

Design docs


https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for subresources, asking for explicit permission from the target server. A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Pending

Risks



Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do not implement this. Compat risk is straightforward: web servers that do not handle the new preflight requests will eventually break, once the feature ships. The plan to address this is as follows: 1. Send preflight request, ignore result, always send actual request. Failed preflight requests will result in a warning being shown in devtools.


Would that include deprecation reports?
 

2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.


We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.
That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?

Titouan Rigoudy

unread,
Dec 1, 2021, 8:43:25 AM12/1/21
to Yoav Weiss, blink-dev
Thanks for the response Yoav, answers inline.

On Wed, Dec 1, 2021 at 1:22 PM Yoav Weiss <yoav...@chromium.org> wrote:
On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote:


Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access/

Design docs


https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for subresources, asking for explicit permission from the target server. A private network request is any request from a public website to a private IP address or localhost, or from a private website (e.g. intranet) to localhost. Sending a preflight request mitigates the risk of cross-site request forgery attacks against private network devices such as routers, which are often not prepared to defend against this threat.



Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Pending

Risks



Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do not implement this. Compat risk is straightforward: web servers that do not handle the new preflight requests will eventually break, once the feature ships. The plan to address this is as follows: 1. Send preflight request, ignore result, always send actual request. Failed preflight requests will result in a warning being shown in devtools.


Would that include deprecation reports?

Not so far. Blink is not made aware of the warnings yet, they go from the network service to the browser process and then straight to devtools. More wiring would be needed for Blink to notice the warning and send a deprecation report.
 
 

2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.


We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.

That is true. I am planning to write a blog post on web.dev or the chrome blog to help raise awareness.


That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?

I did not look at these metrics during my previous UKM analysis - I was focusing on non-secure contexts initiating private network requests. I can look into them again however, and try to reach out to the biggest users before enforcement is turned on.

Cheers,
Titouan

Daniel Bratell

unread,
Dec 1, 2021, 9:02:46 AM12/1/21
to Titouan Rigoudy, Yoav Weiss, blink-dev

This sounds like a change that would disproportionately affect "enterprise" so it's probably best to involve the Chrome enterprise team sooner rather than later. The numbers are higher than I would have expected. Makes me wonder if there is some specific source of those. I would have expected it to be rarer than that to embed a resource from a private network.

/Daniel

--
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.

Titouan Rigoudy

unread,
Dec 1, 2021, 9:14:29 AM12/1/21
to Daniel Bratell, Yoav Weiss, blink-dev
Good idea, I will alert the enterprise team of the upcoming change.

There are also existing enterprise policies [1] [2] introduced for the previous change (secure context restriction) that also work in this context to disable the new behavior entirely. Their descriptions need a little updating for it to be clear that they apply to this change as well. Filed crbug.com/1275567 to fix that.

As for specific sources: UKM data might not tell us unfortunately, since AFAIU that data is not reported by enterprise deployments?

Cheers,

Yoav Weiss

unread,
Dec 1, 2021, 9:21:59 AM12/1/21
to Titouan Rigoudy, blink-dev
https://groups.google.com/a/chromium.org/g/blink-dev/c/xWVtdGDLz_Q/m/kyofZuRfBAAJ may be a relevant conversation on that front. It may be worthwhile to talk to Andrew to see what they did on that front.

Titouan Rigoudy

unread,
Dec 1, 2021, 9:56:41 AM12/1/21
to Yoav Weiss, blink-dev
Thanks for the pointer! I've reached out and will see what I can do.

Cheers,
Titouan

Mike Taylor

unread,
Dec 2, 2021, 10:45:52 AM12/2/21
to Titouan Rigoudy, blink-dev
Hi Titouan,

I'm curious what the plan is for structured headers. https://github.com/WICG/private-network-access/issues/45 is marked as blocked - has there been other progress or thinking behind the scenes?

thanks,
Mike
--
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.

Titouan Rigoudy

unread,
Dec 2, 2021, 10:55:18 AM12/2/21
to Mike Taylor, blink-dev
Hi Mike,

There is no support for structured headers so far, for consistency reasons, and there has been no movement to deprecate the "true" value for Access-Control-Allow-Credentials. The value of such a deprecation seems minimal.

I could pretty easily add support for the structured "?1" value on top of the "true" token for the new Access-Control-Allow-Private-Network header, and specify that, but I'm not sure it would be terribly useful. Do you think otherwise?

Cheers,
Titouan

Mike West

unread,
Dec 2, 2021, 11:12:00 AM12/2/21
to Titouan Rigoudy, Mike Taylor, blink-dev
I'm not sure it makes sense to introduce a structured header here, given that it's layering on top of CORS headers that I don't think there's substantial interest in changing.

-mike


Mike Taylor

unread,
Dec 2, 2021, 11:14:25 AM12/2/21
to Mike West, Titouan Rigoudy, blink-dev
Thanks - I also don't think there's a lot of value in this particular header being the odd-one-out, just wanted to confirm we're not going to ship "true" first and try to change that to ?1 later (which is always challenging).

Mike West

unread,
Dec 2, 2021, 11:17:51 AM12/2/21
to Mike Taylor, Titouan Rigoudy, blink-dev
_I_ don't think we should do that, but I'd defer to Titouan's preference. :)

-mike

Titouan Rigoudy

unread,
Dec 2, 2021, 11:20:40 AM12/2/21
to Mike West, Mike Taylor, blink-dev
I agree!

Cheers,
Titouan

Titouan Rigoudy

unread,
Dec 3, 2021, 12:44:28 PM12/3/21
to Mike West, Mike Taylor, blink-dev
Yoav, do you think UKM analysis should block sending preflights without enforcing their success? I believe sending these will allow us to get more precise information on the affected websites through the usecounter recorded in crrev.com/c/3310846. I can then analyze UKM data and use the results to inform the decision whether and when to switch enforcement on?

Cheers,
Titouan

Yoav Weiss

unread,
Dec 6, 2021, 4:59:05 AM12/6/21
to Titouan Rigoudy, Mike West, Mike Taylor, blink-dev
I agree UKM analysis should not block step 1, as it holds little risk. (There's still some risks that servers will choke in the face of preflights, but that seems minor compared to the enforcement risk)

Therefore, LGTM1 for step 1 (preflights with no enforcement), but not further (yet). Please come back to this thread with any data you may have as a result of adding UKMs.

Titouan Rigoudy

unread,
Dec 6, 2021, 5:31:49 AM12/6/21
to Yoav Weiss, Mike West, Mike Taylor, blink-dev
Thanks! I'll come back for further discussion with UKM data in hand.

Cheers,
Titouan

Titouan Rigoudy

unread,
Dec 6, 2021, 5:32:26 AM12/6/21
to Yoav Weiss, Mike West, Mike Taylor, blink-dev
*assuming I get 2 more LGTMs, that is.

Mike Taylor

unread,
Dec 6, 2021, 9:11:14 AM12/6/21
to Titouan Rigoudy, Yoav Weiss, Mike West, blink-dev
LGTM2 for step 1.

Chris Harrelson

unread,
Dec 6, 2021, 11:26:42 AM12/6/21
to Mike Taylor, Titouan Rigoudy, Yoav Weiss, Mike West, blink-dev

Titouan Rigoudy

unread,
Feb 17, 2022, 9:26:22 AMFeb 17
to Chris Harrelson, Mike Taylor, Yoav Weiss, Mike West, blink-dev
Hi all,

Just to let you know that due to a couple issues, chief among which a renderer crash (crbug.com/1279376), we are rolling this feature back from Chrome 98.

A few issues have been identified and will block our next attempt at shipping this. In the meantime, we gathered some useful information about impact and notified developers of the upcoming change. I'll write a doc summarizing the timeline and lessons learned, then share as appropriate here.

Cheers,
Titouan

Mike Taylor

unread,
Feb 17, 2022, 9:30:03 AMFeb 17
to Titouan Rigoudy, Yoav Weiss, Mike West, blink-dev, Chris Harrelson
Thanks for the update Titouan. Looking forward to reading your doc.

Titouan Rigoudy

unread,
Mar 2, 2022, 5:36:21 AMMar 2
to Mike Taylor, Yoav Weiss, Mike West, blink-dev, Chris Harrelson
Hi all,

Here's the promised doc: https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit (public, comment access for committers only)

Cheers,
Titouan

Logan Wei

unread,
Apr 6, 2022, 11:20:51 AMApr 6
to blink-dev, Titouan Rigoudy
Hello,  is there now an updated timeline to roll out this change?  Will the trial restart in Chrome 102 or a later version?  

Titouan Rigoudy

unread,
Apr 6, 2022, 1:23:58 PMApr 6
to Logan Wei, blink-dev
Hi all,

Thanks for the timely question, I was about to send an update here.

We have fixed nearly all of the blockers identified in the above doc. The only outstanding issue is the aforementioned crash, which required a bit more design work than the rest. That work has been completed and CLs to fix the problem are now in review; they should land shortly and make it in Chrome 102.

We would like to ship again in Chrome 102 in warning-only mode, just as we last tried in Chrome 98. Preflights will be sent but their results will not be enforced. Failed preflights will show warnings in DevTools, but requests will otherwise continue unimpeded.

Things will stay that way for at least 3 milestones. We will gather compatibility data by monitoring failed preflights, then circle back here to garner approvals to turn on enforcement. That launch will be accompanied by a deprecation trial for web developers to sign up for a time extension if they failed to notice the warnings in time.

Cheers,
Titouan

John Doe

unread,
Apr 18, 2022, 11:47:55 AMApr 18
to blink-dev, Titouan Rigoudy, blink-dev, Logan Wei
1. In Chrome 98, there were no preflight requests when accessing from public HTTPS to private HTTP, will the same be true in the final version?
2. In the case when I have a private HTTPS server that I want everyone to have access to (also via public HTTP), what options do I have ?

Titouan Rigoudy

unread,
Apr 19, 2022, 12:27:42 PMApr 19
to John Doe, blink-dev, Logan Wei
Hi there,

1. Such requests are blocked by mixed content. This launch does not change that.
2. You will want to respond 200 OK to PNA preflight requests to your private HTTPS server with the right headers. See the blog post [1] for details.

Cheers,
Titouan

John Doe

unread,
Apr 19, 2022, 1:28:37 PMApr 19
to blink-dev, Titouan Rigoudy, blink-dev, Logan Wei, John Doe
Sorry seems I accidently switched the S sides in the first question, I meant from public HTTP to private HTTPS so it shouldn't be mixed content, and in such case there's no preflight request.
As I mentioned I installed chrome 98 to test it, when accessing a resource from public HTTPS to private HTTPS there's a preflight request but no such request on an access from public HTTP to private HTTPS.

Martin H

unread,
Apr 19, 2022, 9:51:34 PMApr 19
to blink-dev, Titouan Rigoudy, blink-dev
Hi Titouan, Blink Devs,

Thank you for this news above. 
I work for a software vendor affected by this change, our software installs a small (https://localhost:60500) web server on a users local machine and our https:// SAAS web application connects  to this to hand off various features
We were under the impression this change was to occur in Chrome 101 and have been moving to that timeline rapidly but reading the above I understand this has changed (confusingly though much of the documentation online still carries older dates and talks about the change as early as 101 or 102. )

Should I now understand that *if* this makes Chrome 102 as hoped, you will have 3 mile stone releases (aka 102, 103, 104 ) with an intent to ship "private network access" changes in 105?  
I would understand it's just an estimate based on feedback around this change but as it stands our business is anticipating change as early as next week as this is when 101 was due to ship production. 
it would therefore be extremely beneficial if we understand we have more time to work with customers around this, we have produced updated compliant local components on our end and released this in the past few weeks but as you might expect we need time to address this with every single one of our customers, as Chromium based browsers form the overwhelming majority of users. 

Ultimately my requirement is to advise customers on the change as best as possible, including how to ensure the change is not deployed as some will need time to update their entire fleets. 
When I install Chrome dev 102 build, it seems like our software still works as is today. I assume as it's not on yet. Would someone be able to state which flags I should enable to replicate what will happen when this change goes live?

Is it just the #block-insecure-private-network-requests 
Do I need to configure #private-network-access-send-preflights or #private-network-access-respect-preflight-results
Today all these settings are just "Default

Thanks in advance, please let me know if there is a better forum for this request.
Martin

Titouan Rigoudy

unread,
Apr 20, 2022, 4:47:36 AMApr 20
to Martin H, blink-dev
Hi there,

John: that's due to another facet of Private Network Access (not this intent) that started a deprecation trial in Chrome 94. See https://chromestatus.com/feature/5436853517811712. Unless signed up for the deprecation trial, HTTP websites are no longer allowed to make any requests to private servers.

Martin: there will be no breaking change in Chrome 101. I need to update the blog post to make the new timeline clearer.

Chrome 102 should also not break anything, since we are sending preflights in warning-only mode. If the preflight fails, a warning is displayed in DevTools but the request proceeds as before. As explained above, this will remain the case until at least Chrome 105, at which point we may turn on enforcement: when a preflight fails, the request should not be sent and fail. That remains subject to compatibility risk evaluation.

Cheers,
Titouan

Andrew Boeger

unread,
May 27, 2022, 5:47:02 PMMay 27
to blink-dev, Titouan Rigoudy, blink-dev, Martin H
Hi all -

Just want to call out that this assumption...
Chrome 102 should also not break anything, since we are sending preflights in warning-only mode. If the preflight fails, a warning is displayed in DevTools but the request proceeds as before
... turned out to be false.

The change recently deployed DOES break things. It has broken our internal admin tool our CS teams use to manage customer accounts. 


In meantime, I have my users moving to other browsers because this has broken a critical function for them. 

Titouan Rigoudy

unread,
May 30, 2022, 5:12:42 AMMay 30
to Who Cares, blink-dev, Andrew Boeger, Martin H
Hi there,

Thanks for reaching out.

Andrew: Indeed, this was crbug.com/1329248, apologies for the oversight. The change has been rolled back on Friday. Chrome 102 should pick up the configuration change upon restart.

cpmtatest: by default, script fetches are made in no-cors mode with credentials. I believe [1] and [2] are the relevant specification bits here. If you think this should not be how PNA works, please file an issue in the GitHub repo [3].

Cheers,
Titouan


On Mon, May 30, 2022 at 10:46 AM Who Cares <cpmt...@gmail.com> wrote:
Hi,
Now when chrome 102 is out I wanted to test it so I ran it with --enable-features=PrivateNetworkAccessRespectPreflightResults
There's one thing I'm trying to understand,
I have an HTML page with a script tag, the src of this tag points to a more private network, the default behavior of script tags is not to trigger CORS and since v102 they do trigger it which is expected.
My question is:
I'm getting this error: "Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'."
I never asked to send credentials in my script tag, I guess I can force not send it by adding crossorigin="" to the tag but shouldn't the default behavior be not to send it with credentials?

Who Cares

unread,
May 31, 2022, 12:41:14 PMMay 31
to blink-dev, Andrew Boeger, Titouan Rigoudy, blink-dev, Martin H
Hi,
Now when chrome 102 is out I wanted to test it so I ran it with --enable-features=PrivateNetworkAccessRespectPreflightResults
There's one thing I'm trying to understand,
I have an HTML page with a script tag, the src of this tag points to a more private network, the default behavior of script tags is not to trigger CORS and since v102 they do trigger it which is expected.
My question is:
I'm getting this error: "Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'."
I never asked to send credentials in my script tag, I guess I can force not send it by adding crossorigin="" to the tag but shouldn't the default behavior be not to send it with credentials?
On Saturday, May 28, 2022 at 12:47:02 AM UTC+3 Andrew Boeger wrote:
Reply all
Reply to author
Forward
0 new messages