43
edits
Lightning implementing RFC6638: Difference between revisions
→Testing
(→TODOs) |
Mohitkanwal (talk | contribs) |
||
| Line 144: | Line 144: | ||
http://i60.tinypic.com/2a8ojdc.jpg | http://i60.tinypic.com/2a8ojdc.jpg | ||
==Schedule Tag Implementation== | |||
{| class="wikitable" | |||
|- | |||
! Description !! Status !! Comments | |||
|- | |||
|Servers MUST automatically resolve conflicts with "inconsequential"changes done to scheduling object resources when the "If-Schedule-Tag-Match" request header is specified. The If-Schedule-Tag-Match request header applies only to the Request-URI, and not to the destination of a COPY or MOVE. || Client must send the tag. '''Needs Implementation''' || Already implemented in the patch. It check if the schedule-tag value is available on the mItemInfoCache. If it's available it sends If-Schedule-tag-Match | |||
|- | |||
| A response to any successful GET or PUT request targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the resource. || Client must parse the tag & store it || Already Implemented in the patch. | |||
|- | |||
| A response to any successful COPY or MOVE request that specifies a Destination request header targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the destination resource. || Lightning does not need to implement || Example | |||
|- | |||
| Clients SHOULD use the If-Schedule-Tag-Match header on requests that update scheduling object resources, instead of HTTP ETag-based precondition tests (e.g., If-Match). Normal ETag-based precondition tests are used in all other cases, e.g., for synchronization.|| Example|| Example | |||
|} | |||
==Testing== | ==Testing== | ||
==Releases== | ==Releases== | ||