-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider enabling Sec-Fetch-Dest
.
#136
Comments
I'm generally in favor of improving our telemetry. @pmeenan is this something you can implement in the WPT agents? and is this a change that can take effect for most of the April tests or would it have to wait until May? |
🛎 @pmeenan ? |
Sorry, took me a bit to see how to turn on the features through the command-line (was easier than I thought). Testing it now. |
Just enabled it by default for WebPageTest. It will be available on the public instance over the next hour and will be enabled for the May crawl. Here is an example from my dev environment: https://www.webpagetest.org/result/190425_TxYG_470cd369d8110c606538d6962d73248b/1/details/#step1_request2 |
Great thanks for looking into it! |
Thank you both! This is enabling some interesting analysis in whatwg/html#3255 (comment) and elsewhere. :) |
Awesome. Fwiw, the header will also help with cloudflare's http/2
server-side prioritization work. As it gets more broadly adopted.
…On Tue, May 28, 2019 at 2:28 AM Mike West ***@***.***> wrote:
Thank you both! This is enabling some interesting analysis in whatwg/html#3255
(comment)
<whatwg/html#3255 (comment)> and
elsewhere. :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#136?email_source=notifications&email_token=AADMOBIGLLB4DYFBBE55YRTPXT3KXA5CNFSM4HCZAIG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWLQ5UY#issuecomment-496438995>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADMOBKIVW2IWGRETA6RLE3PXT3KXANCNFSM4HCZAIGQ>
.
|
The
Sec-Fetch-Dest
header exposes the "destination" of a request, which can be quite useful in tracking down things associated with particular kinds of requests that aren't otherwise distinguishable by theAccept
header (script loads, for instance). While we're debating whether it actually produces a reasonable security boundary in w3c/webappsec-fetch-metadata#16, it seems like it would produce some interesting data in the archive that would enable us to make finer-grained decisions about things related to particular request types.For instance, I'd love to figure out which
<script>
requests have unreasonable MIME types. So I can block them by default. :)The feature can be enabled via Chromium's
SecMetadata
feature flag.WDYT?
The text was updated successfully, but these errors were encountered: