Mailing List Archive

On Sat, 2010-09-11 at 12:22 +0200, Michael Rasmussen wrote:
> Hi all,
>
> I need a complete list of return codes one can expect from a request to
> a caldav server.
>
> http://www.ietf.org/rfc/rfc2616.txt specifies some generel status codes
> and http://www.ietf.org/rfc/rfc4791.txt adds to this list a status code
> of 207 in relation to the MKCALENDAR and REPORT methods.
>
> But are there not a complete list of status code for every CalDAV
> method defined in rfc4791?

Hi Michael,

The number seems to increase all the time, but only from the standard
list in inc/always.php for the ones that DAViCal might theoretically
return at some point, but not a huge number are used.

The ones that I definitely know DAViCal uses are:

200, 201, 204, 207, 301, 302, 304, 400, 403, 404, 405, 406, 409, 412,
500, 501

In general the people who are developing the standards are attempting to
re-use codes, and it seems rare when they come across a situation which
is not defined within the standard set.

207 was not introduced with CalDAV, and will by definition include
multiple status codes from this set.

Ones that I wouldn't be at all surprised to see from other CalDAV
servers would include:

100, 203, 205, 206, 413, 414, 415, 416, 422, 503

Beyond that is less likely, but people can be creative :-)


Cheers,
Andrew McMillan.

[1] Mostly from:

egrep '(XML|Do)Response' inc/* | cut -f2 -d '(' | cut -f1 -d ',' | cut -f1 -d')' | tr -d ' ' | sort | uniq

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
QOTD:
"My shampoo lasts longer than my relationships."
------------------------------------------------------------------------

Hi Andrew,

On Sat, 11 Sep 2010 23:53:37 +1200
Andrew McMillan <andrew at morphoss.com> wrote:

>
> The number seems to increase all the time, but only from the standard
> list in inc/always.php for the ones that DAViCal might theoretically
> return at some point, but not a huge number are used.
>
I know it is a moving target at the moment:-) What I would really like
to have is something like this:

static int CALDAV_DELETE_OK[] = {200, 202, 204};
static int CALDAV_DELETE_OK_SIZE = sizeof(CALDAV_DELETE_OK)/sizeof(int);

static int CALDAV_GET_OK[] = {200};
static int CALDAV_GET_OK_SIZE = sizeof(CALDAV_GET_OK)/sizeof(int);

static int CALDAV_LOCK_OK[] = {200};
static int CALDAV_LOCK_OK_SIZE = sizeof(CALDAV_LOCK_OK)/sizeof(int);

static int CALDAV_OPTIONS_OK[] = {200};
static int CALDAV_OPTIONS_OK_SIZE =
sizeof(CALDAV_PROPFIND_OK)/sizeof(int);

static int CALDAV_PROPFIND_OK[] = {200, 201, 204};
static int CALDAV_PROPFIND_OK_SIZE =
sizeof(CALDAV_PROPFIND_OK)/sizeof(int);

static int CALDAV_PUT_OK[] = {200, 201, 204};
static int CALDAV_PUT_OK_SIZE = sizeof(CALDAV_PUT_OK)/sizeof(int);

static int CALDAV_REPORT_OK[] = {200};
static int CALDAV_REPORT_OK_SIZE = sizeof(CALDAV_REPORT_OK)/sizeof(int);

static int CALDAV_UNLOCK_OK[] = {200};
static int CALDAV_UNLOCK_OK_SIZE = sizeof(CALDAV_UNLOCK_OK)/sizeof(int);

For each CALDAV_x_OK there should be a list of all the theoretically
possible return status codes indicating that the request was
[partially] fulfilled so that you would know that any other return
code indicates an error state.

Is such a list available somewhere?

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plaugher)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100911/ae0c05c0/attachment.pgp>
-------------- next part --------------

On Sat, 2010-09-11 at 14:14 +0200, Michael Rasmussen wrote:
> Hi Andrew,
>
> On Sat, 11 Sep 2010 23:53:37 +1200
> Andrew McMillan <andrew at morphoss.com> wrote:
>
> >
> > The number seems to increase all the time, but only from the standard
> > list in inc/always.php for the ones that DAViCal might theoretically
> > return at some point, but not a huge number are used.
> >
> I know it is a moving target at the moment:-) What I would really like
> to have is something like this:
>
> static int CALDAV_DELETE_OK[] = {200, 202, 204};
> static int CALDAV_DELETE_OK_SIZE = sizeof(CALDAV_DELETE_OK)/sizeof(int);
>
> static int CALDAV_GET_OK[] = {200};
> static int CALDAV_GET_OK_SIZE = sizeof(CALDAV_GET_OK)/sizeof(int);
>
> static int CALDAV_LOCK_OK[] = {200};
> static int CALDAV_LOCK_OK_SIZE = sizeof(CALDAV_LOCK_OK)/sizeof(int);
>
> static int CALDAV_OPTIONS_OK[] = {200};
> static int CALDAV_OPTIONS_OK_SIZE =
> sizeof(CALDAV_PROPFIND_OK)/sizeof(int);
>
> static int CALDAV_PROPFIND_OK[] = {200, 201, 204};
> static int CALDAV_PROPFIND_OK_SIZE =
> sizeof(CALDAV_PROPFIND_OK)/sizeof(int);

I think the only OK response for PROPFIND or REPORT is 207. If you get
200 then something has screwed up somewhere...

There has been a common installation problem for DAViCal in the past
where for some reason output starts before it should - in particular for
configuration errors. This causes PHP to start output early and it
sends a 200 code, which is a symptom of that issue. Hopefully that's
mitigated in the coming release by wrapping the configuration loading in
an output buffer and logging any output from it.


> static int CALDAV_PUT_OK[] = {200, 201, 204};
> static int CALDAV_PUT_OK_SIZE = sizeof(CALDAV_PUT_OK)/sizeof(int);
>
> static int CALDAV_REPORT_OK[] = {200};
> static int CALDAV_REPORT_OK_SIZE = sizeof(CALDAV_REPORT_OK)/sizeof(int);
>
> static int CALDAV_UNLOCK_OK[] = {200};
> static int CALDAV_UNLOCK_OK_SIZE = sizeof(CALDAV_UNLOCK_OK)/sizeof(int);
>
> For each CALDAV_x_OK there should be a list of all the theoretically
> possible return status codes indicating that the request was
> [partially] fulfilled so that you would know that any other return
> code indicates an error state.

I doubt it. I'm not convinced of it's value, really, but you know what
the code is that you're trying to do this for, I guess.

One of the problems with HTTP response codes is that they are usually
transmitted at the *start* of the communication, so if the server has a
problem later on it can't go back and revisit that decision.
Consequently receiving a '200 OK' response code doesn't actually mean
everything was OK. You may even have only half a response if the
network stopped working partway through.

Cheers,
Andrew.

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Paranoia is simply an optimistic outlook on life.
------------------------------------------------------------------------