Passa al contenuto principale

RFC 4918 Punti tecnici delle appendici

Questo documento riassume il contenuto chiave delle appendici A-F di RFC 4918.

Appendice A. Processing XML Elements (Considerazioni sul trattamento degli elementi XML)​

Punti chiave​

1. Requisiti di analisi XML:

  • Deve utilizzare un parser XML conforme agli standard W3C
  • Deve supportare gli spazi dei nomi XML
  • Deve elaborare XML ben formato

2. Trattamento di elementi sconosciuti:

  • Client e server devono ignorare gli elementi XML non riconosciuti
  • Questo garantisce la compatibilità in avanti
  • Le estensioni non rompono le implementazioni esistenti

3. Trattamento degli spazi bianchi:

  • Gli spazi bianchi nei valori degli attributi sono significativi
  • Gli spazi bianchi nei valori degli attributi devono essere preservati
  • Ignorare l'attributo xml:space

4. Considerazioni sulla sicurezza:

  • Disabilitare le entità esterne per prevenire attacchi XXE
  • Limitare la dimensione del documento XML
  • Limitare la profondità di analisi

Appendice B. HTTP Client Compatibility (Considerazioni sulla compatibilità dei client HTTP)​

Linee guida di compatibilità​

1. Client HTTP/1.1:

  • I client HTTP/1.1 di base possono accedere alle risorse WebDAV
  • Ma non possono utilizzare funzionalità specifiche di WebDAV (blocco, proprietà, ecc.)
  • Utilizzare metodi HTTP standard (GET, PUT, DELETE)

2. Supporto parziale di WebDAV:

  • I client possono implementare un sottoinsieme di WebDAV
  • Dovrebbero scoprire le capacità del server tramite OPTIONS
  • Degradazione graziosa alle funzionalità HTTP/1.1

3. Interoperabilità:

  • Seguire le specifiche HTTP
  • Gestire correttamente i reindirizzamenti
  • Supportare connessioni persistenti

Appendice C. The 'opaquelocktoken' Scheme (Schema e URI opaquelocktoken)​

Schema URI opaquelocktoken​

Definizione: Schema URI progettato specificamente per i token di blocco WebDAV

Sintassi:

opaquelocktoken:<UUID>

Esempio:

opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Caratteristiche:

  • Globalmente univoco: Utilizza UUID per garantire l'unicità
  • Opaco: I client non dovrebbero analizzare la sua struttura interna
  • Sicuro per URL: Può essere utilizzato nelle intestazioni HTTP e XML

Scenari di utilizzo:

  • Token di blocco restituito dal metodo LOCK
  • Token di blocco inviato nell'intestazione If
  • Token di blocco specificato nell'intestazione Lock-Token

Differenza con altri URI:

  • Non dereferenziabile (nessuna risorsa corrispondente)
  • Utilizzato solo per identificare i blocchi
  • Ciclo di vita identico al blocco

Appendice D. Lock-null Resources (Risorse bloccate nulle)​

Concetto di risorsa bloccata nulla (LNR)​

Definizione: Tipo di risorsa speciale definito in RFC 2518, creato eseguendo LOCK su un URL non mappato.

Modifiche in RFC 4918:

  • RFC 4918 raccomanda l'uso di "risorse vuote bloccate" invece di LNR
  • Ma per compatibilità all'indietro, i server possono continuare a supportare LNR

Risorse vuote bloccate vs LNR​

CaratteristicaRisorsa vuota bloccata (raccomandato)Lock-Null Resource (compatibilità)
Metodo di creazioneLOCK su URL non mappatoLOCK su URL non mappato
Comportamento GETRestituisce 200 e contenuto vuotoRestituisce 404
ProprietàProprietà di risorsa normaliProprietà LNR speciali
VisibilitàVisibile come membro della collezionePotrebbe essere invisibile
MKCOLFallisce (405)Convertito in collezione

Raccomandazioni di compatibilità client:

  • Dopo aver eseguito LOCK su un URL non mappato, utilizzare PUT per aggiungere contenuto
  • Non dipendere dal comportamento specifico di GET o MKCOL
  • Non dipendere dalle proprietà specifiche di LNR

Appendice E. Guidance for Clients Desiring to Authenticate (Guida per i client che desiderano autenticarsi)​

Scoperta dell'autenticazione​

Problema: Come fa un client a scoprire che una risorsa richiede l'autenticazione?

Metodo 1 - Richiesta OPTIONS proattiva:

OPTIONS /resource HTTP/1.1
Host: example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WebDAV"

Metodo 2 - Tentare l'operazione e gestire 401:

PROPFIND /resource HTTP/1.1
Host: example.com

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="WebDAV"

Migliori pratiche per l'autenticazione​

1. Supportare più schemi di autenticazione:

  • Autenticazione Basic (richiede HTTPS)
  • Autenticazione Digest
  • Token Bearer OAuth 2.0
  • Certificati client

2. Memorizzare nella cache le credenziali di autenticazione:

  • Memorizzare nella cache le credenziali per lo stesso realm
  • Implementare timeout appropriati
  • Archiviare in modo sicuro le informazioni sensibili

3. Gestire i fallimenti di autenticazione:

  • Fornire messaggi di errore chiari
  • Consentire la riautenticazione
  • Evitare il blocco degli account utente

4. Considerazioni sulla sicurezza:

  • Utilizzare sempre HTTPS per trasmettere le credenziali
  • Non includere password nell'URL
  • Implementare la limitazione della frequenza per prevenire attacchi brute force

Appendice F. Summary of Changes from RFC 2518 (Riepilogo delle modifiche rispetto a RFC 2518)​

RFC 4918 rende obsoleto RFC 2518, le principali modifiche includono:

F.1 Modifiche alle implementazioni client e server​

1. Rimozione delle risorse bloccate nulle (LNR):

  • Raccomanda l'uso di "risorse vuote bloccate"
  • Semplifica l'implementazione
  • Migliora l'interoperabilità

2. Chiarimento della sintassi dell'intestazione If:

  • Regole di corrispondenza più chiare
  • Esempi migliorati
  • Elimina le ambiguità

3. Comportamento delle collezioni:

  • Chiarisce il comportamento di DELETE sulle collezioni
  • Chiarisce l'uso dell'intestazione Depth
  • Migliora la gestione degli errori

4. Trattamento delle proprietà:

  • Chiarisce le proprietà live vs morte
  • Migliora i requisiti di atomicità di PROPPATCH
  • Chiarisce il trattamento XML dei valori delle proprietà

F.2 Modifiche alle implementazioni server​

1. Risposta 207 Multi-Status:

  • Requisiti di formato più rigorosi
  • Segnalazione degli errori migliorata
  • Elemento href obbligatorio

2. Comportamento di blocco:

  • Chiarisce il meccanismo di aggiornamento del blocco
  • Migliora la gestione dei timeout
  • Chiarisce i requisiti di invio del token di blocco

3. Semantica COPY/MOVE:

  • Chiarisce il comportamento dell'intestazione Overwrite
  • Migliora il trattamento delle risorse di destinazione
  • Chiarisce l'impatto dei blocchi

F.3 Altre modifiche​

1. Miglioramenti della sicurezza:

  • Aggiunge linee guida di sicurezza XML
  • Migliora le raccomandazioni di protezione DoS
  • Chiarisce i requisiti di autenticazione

2. Miglioramenti dell'interoperabilità:

  • Specifiche più chiare
  • Più esempi
  • Elimina le ambiguità di implementazione

3. Funzionalità deprecate:

  • Alcune funzionalità opzionali di RFC 2518
  • Semplifica i requisiti di conformità
  • Riduce il carico di implementazione

Riepilogo delle appendici​

Le appendici forniscono le seguenti informazioni chiave:

  1. Linee guida di implementazione (A, B): Trattamento XML e compatibilità HTTP
  2. Dettagli tecnici (C, D): Schema URI del token di blocco e risorse bloccate nulle
  3. Raccomandazioni pratiche (E): Linee guida per l'implementazione dell'autenticazione
  4. Storia dell'evoluzione (F): Modifiche da RFC 2518 a RFC 4918

Queste appendici sono molto preziose per implementare client e server WebDAV di alta qualità.

Ultimo aggiornamento il