mdn/content

Be more accurate about cross-origin protections

Open

#23 740 ouverte le 18 janv. 2023

Voir sur GitHub
 (0 commentaires) (0 réactions) (0 assignés)Markdown (22 427 forks)batch import
Content:WebAPIarea: Performance APIeffort: mediumhelp wanted

Métriques du dépôt

Stars
 (8 900 stars)
Métriques de merge PR
 (Merge moyen 7j 3h) (147 PRs mergées en 30 j)

Description

MDN URL

https://developer.mozilla.org/en-US/docs/Web/API/Resource_Timing_API

What specific section or headline is this issue about?

No response

What information was incorrect, unhelpful, or incomplete?

  • Timing-Allow-Origin is needed for CORS and no-cors, it's for cross-origin protection
  • In the case of cross-origin iframes, responseEnd might measure when the iframe finished loading completely with all its subresources, not just the main resource.
  • encoded/decoded body size are (soon to be) CORS-protected rather than TAO protected

What did you expect to see?

See above

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

MDN metadata

Guide contributeur

Direction de recherche
Le problème concerne la documentation de l'API Resource Timing dans `en us/web/api/resource timing api/index.md`. Le contributeur doit examiner le contenu actuel concernant les protections cross origin et mettre à jour les sections discutant de Timing Allow Origin et des protections CORS. Les modifications doivent refléter que Timing Allow Origin est nécessaire à la fois pour les requêtes CORS et no cors, que responseEnd dans les iframes cross origin peut mesurer le chargement complet de l'iframe, et que les tailles de corps encodées/décodées sont protégées par CORS. Il n'y a pas de PR ou de commentaires liés ; le contributeur peut modifier directement le fichier.
Stack technique
Aucun
Domaine
documentation
Type d'issue
Documentation
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Récente
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Plutôt claire
Prérequis
GitMarkdown
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
70