1. Introduzione
1. Introduzione
Alcune applicazioni sul Web richiedono la scoperta di informazioni su un’origine (origin) [RFC6454] (a volte chiamate « metadati a livello di sito (site-wide metadata) ») prima di effettuare una richiesta. Ad esempio, il Robots Exclusion Protocol (http://www.robotstxt.org) specifica come i processi automatizzati ottengono il permesso di accedere alle risorse; analogamente, la Platform for Privacy Preferences (P3P) [P3P] indica agli user agent come scoprire l’informativa sulla privacy prima di interagire con un server di origine.
Pur esistendo diversi modi per accedere ai metadati per risorsa (ad es. campi di intestazione HTTP, PROPFIND in Web Distributed Authoring and Versioning (WebDAV) [RFC4918]), l’overhead percepito (in termini di latenza percepita dal client e/o difficoltà di distribuzione) associato a tali meccanismi ne impedisce spesso l’uso in questi scenari.
Nel contempo è diventato più comune usare HTTP come substrato per protocolli non Web. A volte tali protocolli necessitano di un modo per individuare una o più risorse su un dato host.
In questi casi una soluzione consiste nel designare una « posizione ben nota (well-known location) » per dati o servizi relativi all’intera origine, in modo che sia facilmente individuabile. Tuttavia questo approccio comporta il rischio di collisioni, sia con altre posizioni così designate sia con risorse che l’origine ha creato (o intende creare). Inoltre definire posizioni ben note sottrae all’origine il controllo sul proprio spazio URI [RFC7320].
Per affrontare questi usi, il presente memo riserva nei URI HTTP, HTTPS, WebSocket (WS) e WebSocket sicuro (WSS) il prefisso di percorso /.well-known/ per queste « posizioni ben note ». Le specifiche future che dovranno definire una risorsa per tali metadati potranno registrarne l’uso per evitare collisioni e ridurre l’impatto sullo spazio URI delle origini.
Gli URI ben noti possono essere usati anche con altri schemi URI, ma solo quando le rispettive definizioni lo consentono esplicitamente.