May 2008 - calendarserver-dev - lists.macosforge.org

Re: [CalendarServer] #273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED`
by CalendarServer 08 May '08

08 May '08

#273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED` --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: closed Priority: 3: Important | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: worksforme Keywords: | --------------------------------+------------------------------------------- Comment (by cdaboo(a)apple.com) Section 12.1 defines how the 412 code should be used. Note that it says 412 MUST NOT be returned when there are no conditional headers present. Section 16 talks about the precondition/postcondition behavior. Note that strictly speaking any valid 4xx status code could be used with those, its not just restricted to 403. But for all the CalDAV valid-xxx preconditions, 403 seems the most appropriate. In any case the rules for 412 apply - 412 is only returned when evaluation of the condition request headers indicate an error. -- Ticket URL: <https://trac.calendarserver.org/ticket/273#comment:5> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED`
by CalendarServer 08 May '08

08 May '08

#273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED` --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: closed Priority: 3: Important | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: worksforme Keywords: | --------------------------------+------------------------------------------- Comment (by mail(a)david-reid.com) Replying to [comment:3 cdaboo(a)apple.com] > There are two types of "precondition" being used: > > 1) The HTTP If-Match/If-None-Match pre-condition behavior using ETags. An error with one of those should return a 412. I believe it does. > > 2) A WebDAV pre-condition/post-condition DAV:error response. Those should return a 403 - again I believe that is working fine. Check the latest WebDAV spec RFC4918 to see how those are used. > The problem here is that the term "precondition" is being used in two different ways. > > I am going to mark this as "worksforme" - if you disagree with my analysis go ahead and change it back with an explanation... What sections of the RFC's are you looking at? -- Ticket URL: <https://trac.calendarserver.org/ticket/273#comment:4> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED`
by CalendarServer 08 May '08

08 May '08

#273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED` --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: closed Priority: 3: Important | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: worksforme Keywords: | --------------------------------+------------------------------------------- Changes (by cdaboo(a)apple.com) * status: new => closed * resolution: => worksforme Comment: There are two types of "precondition" being used: 1) The HTTP If-Match/If-None-Match pre-condition behavior using ETags. An error with one of those should return a 412. I believe it does. 2) A WebDAV pre-condition/post-condition DAV:error response. Those should return a 403 - again I believe that is working fine. Check the latest WebDAV spec RFC4918 to see how those are used. The problem here is that the term "precondition" is being used in two different ways. I am going to mark this as "worksforme" - if you disagree with my analysis go ahead and change it back with an explanation... -- Ticket URL: <https://trac.calendarserver.org/ticket/273#comment:3> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED`
by CalendarServer 07 May '08

07 May '08

#273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED` --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: new Priority: 3: Important | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: Keywords: | --------------------------------+------------------------------------------- Comment (by mail(a)david-reid.com) Replying to [ticket:273 wsanchez(a)apple.com] > Via David C. R. Reid: > > `valid-calendar-object-resource` precondition failure is sent with a `403 FORBIDDEN` status code, which probably should be `412 PRECONDITION FAILED`. > This seems to be the case for all preconditions relating to a PUT request. The RFC seems to say these errors should generate a 412 as the preconditions have failed to be met. -- Ticket URL: <https://trac.calendarserver.org/ticket/273#comment:2> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #266: More flexible logging.
by CalendarServer 07 May '08

07 May '08

#266: More flexible logging. --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: closed Priority: 2: Expected | Milestone: 1.3 Component: Calendar Server | Version: Severity: Other | Resolution: fixed Keywords: review | --------------------------------+------------------------------------------- Changes (by wsanchez(a)apple.com) * status: assigned => closed * resolution: => fixed Comment: r2389 for 1.3 -- Ticket URL: <http://trac.calendarserver.org/ticket/266#comment:9> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #266: More flexible logging.
by CalendarServer 07 May '08

07 May '08

#266: More flexible logging. --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: assigned Priority: 2: Expected | Milestone: 1.3 Component: Calendar Server | Version: Severity: Other | Resolution: Keywords: review | --------------------------------+------------------------------------------- Comment (by wsanchez(a)apple.com) r2388 on trunk -- Ticket URL: <http://trac.calendarserver.org/ticket/266#comment:8> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #266: More flexible logging.
by CalendarServer 07 May '08

07 May '08

#266: More flexible logging. --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: wsanchez(a)apple.com Type: Defect | Status: assigned Priority: 2: Expected | Milestone: 1.3 Component: Calendar Server | Version: Severity: Other | Resolution: Keywords: review | --------------------------------+------------------------------------------- Comment (by wsanchez(a)apple.com) Got some feedback from Cyrus: * The `Verbose` item in config plist seems redundant and is not used anywhere as far as I can tell. We should remove that to avoid confusion with the new log level stuff. * It would be good if we could find a way to to have `twisted.dav.fileop` `log.msg` linked to this logging so that those messages only get written out at debug level. * There needs to be a way to turn accounting on for every principal, rather than just a few. Either another config item for `AccountingForAllPrincipals`, or treat a single `"*"` in the `AccountingPrincipals` config items as meaning account for all. * `account.py` - `principal.alternativeURIs()` is a tuple so that needs to be iterated over to properly enable accounting for a user. These are all addressed now. Also, Cyrus would prefer that logging options be in a separate config file. We can address that later if we want to; I'm not sure about it. And Cyrus would like SIGUSR1 to toggle all logging on/back-to-normal, but I think editing the config file is easy enough. Let's duke that out later as well. -- Ticket URL: <http://trac.calendarserver.org/ticket/266#comment:7> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 0

Re: [CalendarServer] #273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED`
by CalendarServer 07 May '08

07 May '08

#273: `valid-calendar-object-resource` precondition failure returns with a `403 FORBIDDEN`, should be `412 PRECONDITION FAILED` --------------------------------+------------------------------------------- Reporter: wsanchez(a)apple.com | Owner: cdaboo(a)apple.com Type: Defect | Status: new Priority: 3: Important | Milestone: 1.x Component: Calendar Server | Version: Severity: Other | Resolution: Keywords: | --------------------------------+------------------------------------------- Changes (by wsanchez(a)apple.com) * priority: 2: Expected => 3: Important -- Ticket URL: <http://trac.calendarserver.org/ticket/273#comment:1> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 1

[PATCH] Name Service Switch (NSS) based directory service
by Guido Günther 06 May '08

06 May '08

Hi, I finally got bored of synchronizing accounts.xml with the other user and group databases, so I stitched together a simple NSS based user and group lookup directory service that simply uses the users and groups known to the system. You can set a prefix for groups and ranges for uids/gids to make sure system/admin users/groups don't end up having calendars. There's no location and resource handling yet although we could handle this too, but a proper LDAP interface might be more appropriate in that case. This directory service is not doing any authentication since everybody is doing Kerboeros anyways nowadays, so have fun! Pam would be possible to stich in too - but you'll have to hack up python-pam a bit which isn't worth it - so better get your KDC now! This was tested on Linux but should work on any unix based system. I'd be happy to adjust for other OSes if there are problems. The first patch adds the directory service itself while the second adds the defaults to twistedcaldav.config. Use: twistedcaldav.directory.nss.NssDirectoryService as DirectoryService and have a look at twistedcaldav.directory.nss for the available options. The patche are at Ticket #271 in trac: http://trac.macosforge.org/projects/calendarserver/ticket/271 Cheers, -- Guido

2 1