410898 - DTSTART/DTEND ignored in FREEBUSY response to scheduling request

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, defect)

Description

[Andrew Daviel]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Sunbird 0.8pre

If the response to a FREEBUSY POST request has a narrower time range
than that in the request, it is ignored and times outside the DTSTART/DETEND
range are shown as free. They should be shown as "no information"

Reproducible: Always

Steps to Reproduce:
1. Edit an event in a CalDAV calendar
2. Invite attendees
3. Enter an attendee who has free/busy stored on the server
4. Sunbird sends a VFREEBUSY request with e.g.
DTSTART:20080106T080000Z

DTEND:20080122T080000Z
5. Server responds with e.g.
DTSTART:20080106T080000Z
DTEND:20080110T080000Z
Actual Results:  
Sunbird shows entire time from 20080106 to 20080122 as free (apart from
any listed events)

Expected Results:  
Sunbird shows time from 20080106 to 20080110 as free and from
20080110 to 20080122 as unknown

This is perhaps an unlikely scenario found while testing. A server would normally return FREEBUSY data for the entire range requested.

Comment 1

[Daniel Boelzle [:dbo]]

Hmm, reading this bug I think it's a server bug. If the whole range is requested, but the server just responds with a subset of that requested range, it's ok to leave the missing range as "unknown".
Andrew, could you please elaborate a bit more and state what server you are using? Thanks.

Comment 2

[Bruno Browning]

I think the issue is that we *don't* leave the missing range as unknown. Say we ask for the next two weeks and the server responds with information about just the next week. getFreeBusyIntervals fetches an array of calIFreeBusyInterval objects that show free/busy over that week - but we essentially ignore the DTSTART/DTEND from the server response, so we don't know that the response timerange is different from the requested timerange - and we show the entire second week as free rather than as unknown. Or so I assume - I haven't actually broken a server to make it fail in this particular way. 

I don't know of any servers that would regularly trigger this bug during normal operation, so I haven't prioritized it. I don't know of any RFC provision that says a server MUST NOT return a different timerange than the one requested - but I don't know why one would want do do so, either.

Comment 3

[Daniel Boelzle [:dbo]]

Yes, I misread that part, thanks for your explanations, Bruno. So this seems to be a caldav flaw from a code perspective, even though we cannot confirm this using a server, right?

Comment 4

[Bruno Browning]

From an operational standpoint, yes, this is a CalDAV bug. But from a code standpoint it seems to me to be more of an iTIP one, to be fixed in the calIFreeBusyProvider interface. One approach might be a new freeBusyType of "reportedRange" or somesuch, which providers could return in the getFreeBusyIntervals array when the reported range does not match the requested one. 

Comment 5

[Daniel Boelzle [:dbo]]

Hmm, right. I'd like to keep calIFreeBusyProvider simple, i.e. callers of the API should just care about the returned dates, assuming they've received information about the whole range (when operation has completed). W.r.t. this special case, I think caldav could easily signal an "unknown" free-busy interval for the outstanding range. This would just require an additional constant calIFreeBusyInterval::UNKNOWN (+ small adoption to the free-busy pane). What do you think, Bruno?

Comment 6

[Bruno Browning]

Yes, that's a better approach. 

Comment 7

[Daniel Boelzle [:dbo]]

Attachment: [checkd in] calIFreeBusyInterval, UI and WCAP parts

Comment 8

[Bruno Browning]

Comment on attachment 315731 [details] [diff] [review]
[checkd in] calIFreeBusyInterval, UI and WCAP parts

looks good; sorry for the delay. r=browning

Comment 9

[Daniel Boelzle [:dbo]]

Comment on attachment 315731 [details] [diff] [review]
[checkd in] calIFreeBusyInterval, UI and WCAP parts

no problem, I think your review times are five times better than mine :/

Comment 10

[Bruno Browning]

Attachment: CalDAV part

This is the CalDAV part. Includes another UI tweak that looks right to me and without which we don't get the trailing Unknown period when the DTEND of the freebusy response is earlier than requested.

Comment 11

[Daniel Boelzle [:dbo]]

Comment on attachment 316940 [details] [diff] [review]
CalDAV part

looks good, r=dbo

Comment 12

[Bruno Browning]

patch checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED