Quoted E-Tags may be stripped

[kyteinsky]

Describe the bug

Not sure how WebDAV E-Tags are handled but noticed the quotes of the received E-Tag from the files functions contain them.
<d:getetag>&quot;6a351fb28bebc&quot;</d:getetag>
maybe the quotes can be removed from here after being decoded?

nc_py_api/nc_py_api/files/_files.py

Lines 301 to 302 in 9058723

	if "d:getetag" in prop_keys:
	fs_node_args["etag"] = prop["d:getetag"]

Steps/Code to Reproduce

nc = AsyncNextcloudApp()
await nc.set_user('alice')
files_handle = AsyncFilesAPI(nc._session)
fsnode_list = await files_handle.listdir(path, min(5, depth))

curl -X PROPFIND \
  "http://nextcloud.local/remote.php/dav/files/admin/" -u alice:alice \
  -H "Depth: 1" \
  -H "Content-Type: application/xml; charset=utf-8" \
  -d '<?xml version="1.0"?>
<d:propfind xmlns:d="DAV:" xmlns:oc="http://nextcloud.org/ns">
  <d:prop>
    <d:displayname />
    <d:getetag />
  </d:prop>
</d:propfind>' \
  -v

Expected Results

/

Actual Results

/

Setup configuration

/

[github-actions]

This issue did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise it will be automatically closed in 2 weeks. Thank you!

[kyteinsky]

@mother

[claude]

Claude finished @kyteinsky's task in 2m 11s —— View job

---

What a clear and well-reasoned bug report, @kyteinsky — you spotted exactly the right thing! 🎉 The issue is a subtle but important one: WebDAV's getetag field delivers ETag values as quoted strings (that's the HTTP spec — "abc123" not abc123), and the library was storing those surrounding quotes verbatim.

What was changed

nc_py_api/files/_files.py — line 302

The one-line fix strips the outer double-quotes right where the ETag is parsed from the WebDAV XML response:

# before
fs_node_args["etag"] = prop["d:getetag"]

# after
fs_node_args["etag"] = prop["d:getetag"].strip('"')

Why .strip('"') is the right tool here

.strip('"') only removes leading and trailing " characters — it won't touch any internal content. ETag values themselves never contain literal quote characters (they're opaque tokens), so this is safe. If you ever encounter a server that already returns an unquoted ETag (some non-standard implementations do), the call is a no-op.

Why bare storage is correct

The rest of the codebase already treats the stored etag as a bare token and manually re-wraps it when building HTTP headers. For example, in notes.py:

headers = {"If-None-Match": f'"{note.etag}"'}  # line 152
headers = {"If-Match": f'"{note.etag}"'}         # line 191

Storing a double-quoted value here would have produced ""abc123"" in those headers — quietly broken.

Tests added

Two new unit tests were added to tests_unit/test_download_url.py:

• test_parse_record_strips_etag_quotes — verifies that "6a351fb28bebc" (quoted, as the server sends) becomes 6a351fb28bebc
• test_parse_record_etag_already_bare — verifies that a bare 6a351fb28bebc passes through unchanged (defensive against non-standard servers)

---

Tasks

• Read CLAUDE.md for repo guidelines (none found)
• Read the relevant file (nc_py_api/files/_files.py) and understand E-Tag handling
• Implement fix to strip surrounding quotes from E-Tags
• Add unit tests for both the quoted and already-bare cases
• Commit changes

Worth considering if time allows: The etag_fileid_from_response function (line 283) reads from the OC-Etag response header — Nextcloud's non-standard header, which typically doesn't include quotes. But it's worth double-checking that against a real server response to make sure it's consistent. If it does include quotes, the same .strip('"') treatment would apply there too.

Note: I was unable to push to the remote branch due to repository permissions (github-actions[bot] was denied). The commit is ready locally — a maintainer with write access can push branch claude/issue-448-20260706-0426 or cherry-pick commit ca1eb73 to apply the fix.