PROPFIND

Metode HTTP

Spesifikasi metode HTTP PROPFIND

Metode PROPFIND mengambil properti yang didefinisikan pada sumber daya yang diidentifikasi oleh Request-URI, jika sumber daya tersebut tidak memiliki anggota internal, atau pada sumber daya yang diidentifikasi oleh Request-URI dan berpotensi menjadi sumber daya anggotanya, jika sumber daya tersebut merupakan koleksi yang memiliki URL anggota internal. Semua sumber daya yang sesuai dengan DAV HARUS mendukung metode PROPFIND dan elemen XML propfind (Bagian 14.20) bersama dengan semua elemen XML yang didefinisikan untuk digunakan dengan elemen tersebut.

Klien HARUS mengirimkan tajuk Kedalaman dengan nilai "0", "1", atau "tak terhingga" dengan permintaan PROPFIND. Server HARUS mendukung permintaan kedalaman "0" dan "1" pada sumber daya yang sesuai dengan WebDAV dan HARUS mendukung permintaan "tak terhingga". Pada praktiknya, dukungan untuk permintaan kedalaman tak terbatas MUNGKIN dinonaktifkan, karena masalah kinerja dan keamanan yang terkait dengan perilaku ini. Server HARUS memperlakukan permintaan tanpa header Kedalaman seolah-olah header Kedalaman: tak terhingga disertakan.

Klien dapat mengirimkan elemen XML propfind di dalam badan metode permintaan yang menjelaskan informasi apa yang diminta. Hal ini dimungkinkan:

  • Meminta nilai properti tertentu, dengan menamai properti yang diinginkan di dalam elemen prop (urutan properti di sini MUNGKIN diabaikan oleh server),
  • Meminta nilai properti untuk properti-properti yang didefinisikan di dalam spesifikasi ini (minimal) ditambah dengan properti yang sudah tidak ada, dengan menggunakan elemen allprop (elemen include dapat digunakan dengan allprop untuk menginstruksikan server agar menyertakan properti hidup tambahan yang mungkin tidak dikembalikan dengan cara lain),
  • Meminta daftar nama semua properti yang didefinisikan di sumber daya, dengan menggunakan elemen propname.

Klien dapat memilih untuk tidak mengirimkan badan permintaan. Badan permintaan PROPFIND yang kosong HARUS diperlakukan seolah-olah itu adalah permintaan allprop.

Perhatikan bahwa allprop tidak mengembalikan nilai untuk semua properti langsung. Server WebDAV semakin banyak memiliki properti yang dihitung secara mahal atau panjang (lihat [RFC3253] dan [RFC3744]) dan tidak mengembalikan semua properti. Sebagai gantinya, klien WebDAV dapat menggunakan permintaan propname untuk menemukan properti langsung yang ada, dan meminta properti bernama saat mengambil nilai. Untuk properti langsung yang didefinisikan di tempat lain, definisi tersebut dapat menentukan apakah properti langsung tersebut akan dikembalikan dalam permintaan allprop atau tidak.

Semua server HARUS mendukung pengembalian respons jenis konten teks/xml atau aplikasi/xml yang berisi multistatus elemen XML yang menjelaskan hasil upaya untuk mengambil berbagai properti.

Jika terjadi kesalahan dalam mengambil properti, maka hasil kesalahan yang tepat HARUS disertakan dalam respons. Permintaan untuk mengambil nilai properti yang tidak ada merupakan kesalahan dan HARUS dicatat dengan elemen XML respon yang berisi nilai status 404 (Tidak Ditemukan).

Karena itu, elemen XML multistatus untuk sumber daya koleksi HARUS menyertakan elemen XML respon untuk setiap URL anggota koleksi, hingga kedalaman apa pun yang diminta. Elemen tersebut TIDAK BOLEH menyertakan elemen respon apa pun untuk sumber daya yang tidak sesuai dengan WebDAV. Setiap elemen respon HARUS berisi elemen href yang berisi URL sumber daya tempat properti dalam elemen XML prop didefinisikan. Hasil untuk PROPFIND pada sumber daya koleksi dikembalikan sebagai daftar datar yang urutan entri-entrinya tidak signifikan. Perhatikan bahwa sebuah sumber daya mungkin hanya memiliki satu nilai untuk sebuah properti dengan nama tertentu, sehingga properti itu mungkin hanya muncul sekali dalam respons PROPFIND.

Properti mungkin tunduk pada kontrol akses. Dalam kasus permintaan allprop dan propname, jika prinsipal tidak memiliki hak untuk mengetahui apakah properti tertentu ada, maka properti tersebut MUNGKIN secara diam-diam dikecualikan dari respons.

Beberapa hasil PROPFIND MUNGKIN disimpan dalam cache, dengan hati-hati, karena tidak ada mekanisme validasi cache untuk sebagian besar properti. Metode ini aman dan tidak berdaya (lihat Bagian 9.1 dari [RFC2616]).

Metode HTTP PROPFIND telah ditentukan dalam bagian 9.1 dari dokumen RFC 4918 oleh Internet Engineering Task Force (IETF) dan World Wide Web Consortium (W3C).

Deskripsi metode PROPFIND

pekerjaan yang sedang berlangsung

Contoh untuk metode HTTP PROPFIND

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