Do czego służy folder „.well-known”?

Jeśli znalazłem nowy komunikat o błędzie w naszych plikach dziennika i chciałbym wiedzieć, o co chodzi w tym .well_knownfolderze.

Który klient aplikacji musiałby uzyskać dostęp do takiego folderu, a która aplikacja utworzyłaby w nim pliki ?

Oto niektóre wpisy dziennika błędów PHP jednej z moich domen. (Usunąłem datę, adres ip i domeny docelowe).

0000/00/00 00:00:00 [error] 851#0: *88611 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "exampleA.com"
0000/00/00 00:00:00 [error] 850#0: *89749 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/assetlinks.json HTTP/1.1", host: "exampleA.com"
0000/00/00 00:00:00 [error] 850#0: *89767 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/assetlinks.json HTTP/1.1", host: "exampleB.com"
0000/00/00 00:00:00 [error] 853#0: *90120 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "exampleB.com"
0000/00/00 00:00:00 [error] 853#0: *90622 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "www.exampleB.com"
0000/00/00 00:00:00 [error] 853#0: *90926 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/assetlinks.json HTTP/1.1", host: "www.exampleA.com"
0000/00/00 00:00:00 [error] 854#0: *91780 access forbidden by rule, client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /.well-known/apple-app-site-association HTTP/1.1", host: "exampleA.com"

Najpierw pomyślałem, że to ja mogłem to wygenerować, ale w tamtych czasach nie miałem dostępu do tych domen ani ich nie obsługiwałem. Te żądania dostępu pochodzą z 3 naszych domen. (z różnymi aplikacjami internetowymi)

INFO1 : Wygląda na to, że adres IP pochodzi z Google-Bot (przeszukiwacza). Ale co jest tak ważnego, aby uzyskać dostęp do tych plików? (nie mamy tych plików w folderach, sprawdzonych pod kątem ukrytego we wszystkich katalogach głównych domen).

Ten /.well-known/podkatalog jest zdefiniowany przezRFC 5785 RFC 8615

Protokoły sieciowe coraz częściej wymagają wykrycia zasad lub innych informacji o hoście („metadane dla całej witryny”) przed wysłaniem żądania. Na przykład protokół wykluczania robotów http://www.robotstxt.org/ określa sposób, w jaki zautomatyzowane procesy mogą uzyskać pozwolenie na dostęp do zasobów; podobnie platforma preferencji dotyczących prywatności [W3C.REC-P3P-20020416] informuje agentów użytkowników, jak wcześniej odkryć politykę prywatności.

Chociaż istnieje kilka sposobów dostępu do metadanych dla poszczególnych zasobów (np. Nagłówki HTTP, PROPFIND WebDAV [RFC4918]), postrzegany narzut (związany z postrzeganymi przez klienta opóźnieniami i / lub trudnościami z wdrożeniem) często wyklucza ich użycie w te scenariusze.

Kiedy tak się dzieje, często wyznacza się „dobrze znaną lokalizację” dla takich danych, aby można ją było łatwo zlokalizować. Jednak to podejście ma tę wadę, że ryzykuje kolizje, zarówno z innymi tak wyznaczonymi „dobrze znanymi lokalizacjami”, jak iz istniejącymi zasobami.

Aby rozwiązać ten problem, to notatka określa prefiks ścieżki HTTP, (S) URI dla tych „znanych miejsc” , /.well-known/. Przyszłe specyfikacje, które muszą zdefiniować zasób dla takich metadanych obejmujących całą witrynę, mogą rejestrować ich użycie, aby uniknąć kolizji i zminimalizować wpływ na przestrzeń URI witryn.

Powodem, dla którego widzisz błędy zabronione, może być wynik blokowania zapytań o ukryte pliki / foldery (ścieżki zaczynające się od kropki .).
Jeśli masz przydatne treści w /.well-known, te pytania i odpowiedzi mogą być interesujące.

Lokalizacje w tym katalogu są następnie wykorzystywane do określonych celów,

• /.well-known/apple-app-site-associationjest dla uniwersalnych linków IOS
• /.well-known/assetlinks.jsonto łącze do zasobów cyfrowych (Android)

Oba obsługują podobny cel, pozwalają operatorowi strony na polecenie odwiedzającemu otwarcia witryny w powiązanej aplikacji, a nie w przeglądarce (mobilnej).

• /.well-known/acme-challenge/jest lokalizacją proponowanego standardu środowiska automatycznego zarządzania certyfikatami jako lokalizacją walidacji identyfikatora HTTP stosowaną przez Let's Encrypt.

IANA prowadzi obszerną listę przypisanych, dobrze znanych lokalizacji na www.iana.org/assignments/well-known-uris/well-known-uris.xhtml, a podobna lista na Wikipedii zawiera również kilka różnych URI, które nie zostały oficjalnie przypisane i zarejestrowany przez IANA.