fix: return 204 instead of 404

[SebastianKrupinski]

• Resolves: Lot of 404 errors / CrowdSec ban me contacts#3021
• Related: fix: check if photo property is set before downloading contacts#4249

Summary

Changed status return to 204 "no content" instead of 404 when a photo does not exist

204 make more sense as it signals that there was no image, instead that a error occurred.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[SebastianKrupinski]

/backport to stable30

[SebastianKrupinski]

/backport to stable29

[arnowelzel]

Eventhough this fix solves the issue of having a lot of 404-responses - the root cause is still in place: instead of checking, if there is an image at all and not requesting it, the contacts app still tries to load an image for each contact. There will still be a lot of exceptions which trigger the 204-response. It would be better, if a contact had a flag, that there is no image, so the frontend won't even try to load it.

[kesselb]

We rejected similar "don't use 404 for fail2ban" requests in the past.
For example: #26793.

---

I think using 204 is a good choice.
The request was successful, there's just no content to return.

---

As written by Arno, changing the response code is a workaround for those fail2ban users. The underlying problem is that those requests are happening. The response for the address book contains a has-photo attribute (empty/1).

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:card="urn:ietf:params:xml:ns:carddav">
	<d:response>
		<d:href>
			/remote.php/dav/addressbooks/users/admin/contacts/F1D36433-6CC3-48B9-942F-8E7E12A69D4E.vcf
		</d:href>
		<d:propstat>
			<d:prop>
				<d:getetag>&quot;4e748fcff71af1c2a024fb19b9a3812e&quot;</d:getetag>
				<d:getcontenttype>text/vcard; charset=utf-8</d:getcontenttype>
				<d:resourcetype/>
				<card:address-data>BEGIN:VCARD&#13;
					VERSION:3.0&#13;
					PRODID:-//Sabre//Sabre VObject 4.5.6//EN&#13;
					UID:58236d02-66e5-4374-bdaa-5d4f04ce29f4&#13;
					FN:Test 1000&#13;
					EMAIL;TYPE=HOME:&#13;
					END:VCARD&#13;
				</card:address-data>
				<x1:has-photo xmlns:x1="http://nextcloud.com/ns"></x1:has-photo>
			</d:prop>
			<d:status>HTTP/1.1 200 OK</d:status>
		</d:propstat>
	</d:response>
</d:multistatus>

The following change for contacts should take the hasPhotos property into account:

Index: src/models/contact.js
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/models/contact.js b/src/models/contact.js
--- a/src/models/contact.js	(revision b91012f60c1b011a3ce173c8613b05a221646ae4)
+++ b/src/models/contact.js	(date 1734087428669)
@@ -119,6 +119,16 @@
 		return ''
 	}
 
+	/**
+	 * Return whether a photo is available
+	 *
+	 * @readonly
+	 * @memberof Contact
+	 */
+	get hasPhoto() {
+		return this.dav && this.dav.hasphoto
+	}
+
 	/**
 	 * Return the version
 	 *
Index: src/components/ContactsList/ContactsListItem.vue
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/src/components/ContactsList/ContactsListItem.vue b/src/components/ContactsList/ContactsListItem.vue
--- a/src/components/ContactsList/ContactsListItem.vue	(revision b91012f60c1b011a3ce173c8613b05a221646ae4)
+++ b/src/components/ContactsList/ContactsListItem.vue	(date 1734087333973)
@@ -141,7 +141,7 @@
 					return
 				}
 				this.avatarUrl = photoUrl
-			} else if (this.source.url) {
+			} else if (this.source.hasPhoto && this.source.url) {
 				this.avatarUrl = `${this.source.url}?photo`
 			}
 		},

[SebastianKrupinski]

The following change for contacts should take the hasPhotos property into account:

Sure, we can add this also, makes sense.

[oleksandr-nc]

really good changes

[SebastianKrupinski]

/backport to stable28

See Wiki: Maintenance and Release Schedule. 28 has reached EOL.

No worries, ill cancel the 28 backport.

FYI, a EOL date not just the month would be a good idea.

This can be interpreted as Dec 31st instead of Dec 1st