Bug 106303 - HTTP etag not properly updated after vCard updates, updates impossible
Summary: HTTP etag not properly updated after vCard updates, updates impossible
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kresources
Classification: Unmaintained
Component: groupdav (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Reinhold Kainhofer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-25 22:53 UTC by Helge Hess
Modified: 2024-08-11 18:08 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Hess 2005-05-25 22:53:12 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Since Svn r1053 OGo ZideStore supports creating and changing vCards in the OGo person and company contact folders.

While creating and changing _once_ works fine with KAddressbook/GroupDAV, editing breaks because the etag is not properly updated after a PUT. ZideStore properly checks the if-match header on the next update and detects that the etag is outdated and therefore rejects the request with a HTTP 412 (Precondition Failed) status.

The most important thing to fix is that after a PUT the etag is updated from the PUT HTTP response (or better: issue a complete refetch of the record).

In addition the kresource should detect the 412 conflict and as a minimum implementation should allow the user to choose between:
a) throw away changes and refetch from server
b) overwrite changes on the server (technically by removing the
   if-match)
Comment 1 Helge Hess 2005-05-25 23:01:31 UTC
HTTP Log information:

Once a write succeeds after the initial fetch of the vCards:
---snip---
PUT /zidestore/so/helge/public/Contacts/24710.vcf?sn=Duck HTTP/1.1
...
If-Match: 24710:1

BEGIN:VCARD
ADR;TYPE=work:;;;Entenhausen;;123;
...
X-KABCResourceGroupDAV-storagelocation:webdav://helge@move.in.skyrix.com:80
 /zidestore/so/helge/public/Contacts/24710.vcf?sn=Duck
END:VCARD


May 25 20:04:06 ogo-zidestore-1.3 [16134]: <<0x087D565C[SxPerson]>>D etag '24710:1' matches: 24710:1

HTTP/1.0 200 Ok
etag: 24710:3
content-length: 0
location: http://move.in.skyrix.com:80/zidestore/so/helge/public/Contacts/24710.vcf

---snap---

Notice that the version in the etag is bumped to "23710:3". ZideStore also deliviers the location though it didn't change => ZideStore bug.

Another change:
---snip---
PUT /zidestore/so/helge/public/Contacts/24710.vcf?sn=Duck HTTP/1.1
...
Content-Type: text/x-vcard
Host: move.in.skyrix.com
If-Match: 24710:1
...
BEGIN:VCARD
ADR;TYPE=work:;;sss\ndef;Entenhausen;;123;
...

END:VCARD


May 25 21:00:50 ogo-zidestore-1.3 [16285]: <<0x087D55FC[SxPerson]>>D etag '24710:3' does not match: (
    "24710:1"
)

HTTP/1.0 412 Precondition Failed
content-type: text/html; charset="iso-8859-1"
content-length: 187

<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml">
<body><h3>An error occurred during object publishing</h3><p>Precondition Failed</p></body>
</html>
---snap---

The client still has the old etag.

The user doesn't get any kind of error notice, to him it looks like the change was successful (and indeed, the data is changed locally).
Comment 2 Helge Hess 2005-05-25 23:32:24 UTC
(added a hack in OGo r1055 to disable etag-consistency for KDE 3.4)
Comment 3 Reinhold Kainhofer 2005-08-16 12:41:57 UTC
Absolutely, Currently there's hardly any error detection in place. Or rather, the user isn't told about the errors that are detected.
Comment 4 Helge Hess 2005-08-16 12:50:49 UTC
NOTE: this bug is only partitially about error handling. The bigger problem is that the ETag is not updated after a change ("editing breaks because the etag is not properly updated after a PUT").


BTW:
"ZideStore also deliviers the location though it didn't change => ZideStore bug"
This has been fixed.
Comment 5 Christoph Cullmann 2024-08-11 18:08:29 UTC
Dear reporter, the resources handling got redone for KF5 and KF6 based PIM applications.

If you still encounter the issues you had in the past, please report them to the current maintained and updated PIM applications you use

Thanks a lot!