PROPFIND

HTTP módszer

A PROPFIND-es HTTP-módszer specifikációja

A PROPFIND módszer a Request-URI által azonosított erőforráson meghatározott tulajdonságokat kér le, ha az erőforrásnak nincsenek belső tagjai, vagy a Request-URI által azonosított erőforráson és potenciálisan annak tag erőforrásain, ha az erőforrás egy gyűjtemény, amely belső tag URL-ekkel rendelkezik. Minden DAV-kompatibilis erőforrásnak támogatnia KELL a PROPFIND módszert és a propfind XML elemet (14.20. szakasz), valamint az ezzel az elemmel való használatra meghatározott összes XML elemet.

A kliensnek a PROPFIND kéréssel együtt egy "0", "1" vagy "végtelen" értékű Depth fejlécet KELL küldenie. A szervereknek támogatniuk KELL a "0" és "1" mélységi kéréseket a WebDAV-kompatibilis erőforrásokon, és KELL támogatniuk a "végtelen" kéréseket. A gyakorlatban a végtelen mélységű kérések támogatása letiltható az ezzel a viselkedéssel kapcsolatos teljesítmény- és biztonsági aggályok miatt. A kiszolgálóknak a Depth fejléc nélküli kéréseket úgy KELL kezelniük, mintha Depth: infinity fejlécet tartalmaznának.

A kliens a kérési módszer testében egy propfind XML elemet küldhet, amely leírja, hogy milyen információt kér. Lehetőség van a következőkre:

  • Kérni bizonyos tulajdonságértékeket a kívánt tulajdonságok megnevezésével a prop elemben (a tulajdonságok sorrendjét a kiszolgáló figyelmen kívül hagyhatja),
  • Kérni a tulajdonságértékeket az ebben a specifikációban (legalább) meghatározott tulajdonságokra, valamint a holt tulajdonságokra, a allprop elem használatával (a include elem a allprop elemmel együtt használható a kiszolgáló utasítására, hogy további élő tulajdonságokat is tartalmazzon, amelyeket egyébként esetleg nem kapna vissza),
  • A forráson meghatározott összes tulajdonság nevének listáját kéri a propname elem használatával.

A kliens dönthet úgy is, hogy nem küld kéréstestet. Az üres PROPFIND kéréstestet úgy KELL kezelni, mintha az egy allprop kérés lenne.

Megjegyzendő, hogy a allprop nem adja vissza az összes élő tulajdonság értékét. A WebDAV-kiszolgálók egyre gyakrabban rendelkeznek költségesen kiszámított vagy hosszú tulajdonságokkal (lásd [RFC3253] és [RFC3744]), és már nem adnak vissza minden tulajdonságot. Ehelyett a WebDAV-ügyfelek propname kérésekkel felfedezhetik, hogy milyen élő tulajdonságok léteznek, és az értékek lekérdezésekor megnevezett tulajdonságokat kérhetnek. Egy máshol definiált élő tulajdonság esetében az adott definíció megadhatja, hogy az adott élő tulajdonságot a allprop kérésekben visszaadják-e vagy sem.

Minden kiszolgálónak támogatnia KELL a text/xml vagy application/xml típusú válasz visszaküldését, amely tartalmaz egy multistatus XML elemet, amely leírja a különböző tulajdonságok lekérdezésére tett kísérletek eredményeit.

Ha egy tulajdonság lekérdezése hibás, akkor a válasznak tartalmaznia KELL a megfelelő hiba eredményét. Egy nem létező tulajdonság értékének lekérdezése hibának minősül, és ezt egy 404 (Not Found) státuszértéket tartalmazó response XML elemmel KELL jelezni.

Ezek következtében a gyűjtemény erőforrás multistatus XML elemének tartalmaznia KELL egy response XML elemet a gyűjtemény minden egyes tagjának URL címére, bármilyen mélységben is kérte. NEM KELL tartalmaznia semmilyen response elemet a nem WebDAV-kompatibilis erőforrásokhoz. Minden response elemnek tartalmaznia KELL egy href elemet, amely tartalmazza annak az erőforrásnak az URL-címét, amelyen a prop XML elemben szereplő tulajdonságok definiálva vannak. A gyűjteményes erőforráson végzett PROPFIND eredményei sima listaként kerülnek visszaküldésre, amelynek a bejegyzések sorrendje nem lényeges. Megjegyzendő, hogy egy erőforrás egy adott nevű tulajdonságnak csak egy értéke lehet, így a tulajdonság csak egyszer jelenhet meg a PROPFIND-válaszokban.

A tulajdonságok hozzáférési ellenőrzés alá eshetnek. A allprop és propname kérések esetében, ha egy megbízónak nincs joga tudni, hogy egy adott tulajdonság létezik-e, akkor a tulajdonságot a válaszból némán ki lehet zárni.

Egyes PROPFIND eredmények óvatosan gyorsítótárba helyezhetők, mivel a legtöbb tulajdonságra nincs gyorsítótár-érvényesítési mechanizmus. Ez a módszer biztonságos és idempotens (lásd az [RFC2616] 9.1. szakaszát).

A PROPFIND-as HTTP-módszert az Internet Engineering Task Force (IETF) és a World Wide Web Consortium (W3C) a RFC 4918-as dokumentum 9.1. szakaszában határozta meg.

A PROPFIND módszer leírása

folyamatban lévő munka

Példa a PROPFIND-es HTTP-módszerre

Request header:
PROPFIND /data HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/58.0.3029.110 Safari/537
Depth: 1
Content-Type: text/xml; charset="utf-8"
Accept-Language: de-DE,de;q=0.5
Connection: keep-alive
Response header:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: 453
Date: Mon, 31 July 2023 14:58:12 GMT
Server: Apache/2.4.7 (Ubuntu)
Cache-Control: no-cache