PROPFIND

Метод PROPFIND повертає властивості, визначені в ресурсі, ідентифікованому за запитом-URI, якщо ресурс не має внутрішніх членів, або в ресурсі, ідентифікованому за запитом-URI, і потенційно його ресурсах-членах, якщо ресурс є колекцією, яка має внутрішні URL-адреси членів. Усі DAV-сумісні ресурси ПОВИННІ підтримувати метод PROPFIND і елемент XML propfind (Розділ 14.20) разом з усіма елементами XML, визначеними для використання з цим елементом.

Клієнт ПОВИНЕН надсилати заголовок Depth зі значенням "0", "1" або "нескінченність" разом із запитом PROPFIND. Сервери ПОВИННІ підтримувати запити глибини "0" і "1" на WebDAV-сумісних ресурсах і ПОВИННІ підтримувати запити "нескінченність". На практиці підтримка запитів нескінченної глибини МОЖЕ бути відключена через проблеми з продуктивністю і безпекою, пов'язані з такою поведінкою. Сервери ПОВИННІ обробляти запит без заголовка Depth так, ніби до нього включено заголовок Depth: infinity.

Клієнт може подати елемент propfind XML у тілі методу запиту, що описує інформацію, яка запитується. Це можливо:

• Запитувати конкретні значення властивостей, називаючи бажані властивості в елементі prop (порядок властивостей тут МОЖЕ бути проігнорований сервером),
• Запитувати значення властивостей для тих властивостей, які визначені в цій специфікації (як мінімум) плюс мертві властивості, за допомогою елемента allprop (елемент include можна використовувати разом з allprop, щоб вказати серверу також включити додаткові живі властивості, які інакше могли б не бути повернуті),
• Запитати список імен усіх властивостей, визначених на ресурсі, за допомогою елемента propname.

Клієнт може не надсилати тіло запиту. Порожнє тіло запиту PROPFIND ПОВИННО розглядатися так, як якщо б це був запит allprop.

Зверніть увагу, що allprop повертає значення не для всіх реальних властивостей. Сервери WebDAV дедалі частіше мають дороговартісні або довгі властивості (див. [RFC3253] і [RFC3744]) і вже не повертають всі властивості. Натомість, клієнти WebDAV можуть використовувати запити propname, щоб дізнатися, які живі властивості існують, і запитувати іменовані властивості при отриманні значень. Для живих властивостей, визначених деінде, у цьому визначенні можна вказати, чи повертатиметься ця жива властивість у запитах allprop.

Усі сервери ПОВИННІ підтримувати повернення відповіді з типом вмісту text/xml або application/xml, яка містить multistatus XML-елемент, що описує результати спроб отримати різні властивості.

Якщо при отриманні властивості сталася помилка, то відповідний результат помилки ПОВИНЕН бути включений у відповідь. Запит на отримання значення властивості, якої не існує, є помилкою і ПОВИНЕН бути позначений елементом відповідь XML, який містить значення статусу 404 (Не знайдено).

Відповідно, елемент мультистатус XML для ресурсу колекції ПОВИНЕН включати елемент відповідь XML для кожної URL-адреси члена колекції, незалежно від того, на яку глибину запиту було зроблено запит. Він НЕ ПОВИНЕН містити жодних елементів відповідь для ресурсів, які не є сумісними з WebDAV. Кожен елемент response ПОВИНЕН містити елемент href, який містить URL-адресу ресурсу, для якого визначено властивості в XML-елементі prop. Результати пошуку PROPFIND на ресурсі колекції повертаються у вигляді плаского списку, порядок елементів якого не має значення. Зауважте, що ресурс може мати лише одне значення для властивості з даним іменем, тому властивість може з'являтися у відповідях PROPFIND лише один раз.

Властивості можуть бути об'єктом управління доступом. У випадку запитів allprop і propname, якщо принципал не має права знати, чи існує певна властивість, то властивість МОЖЕ бути мовчки виключена з відповіді.

Деякі результати PROPFIND МОЖНА кешувати, з обережністю, оскільки для більшості властивостей не існує механізму перевірки кешу. Цей метод є безпечним і недієвим (див. розділ 9.1 [RFC2616]).