1293257 - ETag in response is not interpreted

Status: RESOLVED INVALID

(Calendar :: Provider: CalDAV, defect)

Description

[René Thiemann]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160728204513

Steps to reproduce:

- Create a new event in Lightning
- Lightning generates a UID:a2cbbd4e-6752-47de-a5b7-5ddef022c502 (example)
- Hit "save and close"



Actual results:

- Server stores the data
- Generates a new UID that has an internal pattern
- Sends a header Etag: "anotherUID.ics"
- Sends "201 - Created" status code
- Lightning tries to fetch the new entry with the sent UID in the XML:
<?xml version="1.0" encoding="UTF-8"?>
<C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/DAV/a2cbbd4e-6752-47de-a5b7-5ddef022c502.ics</D:href></C:calendar-multiget>
- The UID is not found -> 404 error 


Expected results:

- Lightning reacts on the Etag-Header part and try to fetch the new entry with the provided Etag

Comment 1

[Philipp Kewisch [:Fallen][📱📆]]

The ETag does not specify the UID. What kind of server is this? Does it support webdav-sync? I see that we don't support changing the location path on the returned item. The question though is how we would get to know the new UID. 

Also, using uid.ics is just a convention, so even if we support Prefer: return=representation, we can't just assume it will be uid.ics. If you can find an rfc that tells me how to handle this I am happy to look into it, but for now I'd rather close the bug.

Comment 2

[René Thiemann]

Hi there, 

if I understand it right, the client sends a PUT request to the server with an unmatched UID. Afterwards the server creates the new event and sends back the new and correct UID.

"Servers SHOULD return a strong entity tag (ETag header) in a PUT
   response when the stored calendar object resource is equivalent by
   octet equality to the calendar object resource submitted in the body
   of the PUT request.  This allows clients to reliably use the returned
   strong entity tag for data synchronization purposes.  For instance,
   the client can do a PROPFIND request on the stored calendar object
   resource and have the DAV:getetag property returned, and compare that
   value with the strong entity tag it received on the PUT response, and
   know that if they are equal, then the calendar object resource on the
   server has not been changed."

@see https://tools.ietf.org/html/rfc4791#section-5.3.4
@see https://icalendar.org/CalDAV-Access-RFC-4791/5-3-2-creating-calendar-object-resources.html

I am using the awesome package from SabreDAV in version 3.2.0 in a PHP application. 

Thanks!

Comment 3

[Philipp Kewisch [:Fallen][📱📆]]

The ETag is about version control, the UID is about identifying the calendar resource. The returned ETag does not contain the new UID, the two are separate from each other.

What you are looking for, having the server determine the UID and path has been solved with rfc 5995, but this is not implemented in Lightning.