View Issue Details

IDProjectCategoryView StatusLast Update
0001528SOGoBackend Calendarpublic2011-12-07 14:26
Reportergazda Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionno change required 
Product Version1.3.9 
Summary0001528: GET on existing calendar returns HTTP 501 while advertised in the allowed methods with OPTIONS
Description

As discussed in https://sourceforge.net/projects/ical4j/forums/forum/368291/topic/4855559
ical4j 1.0.1 library tests the existence of a collection with a GET request. Because ical4j understands the 501 response as a negative result of the test, it is effectivelly impossible to access any SOGo calendars using ical4j built-in API.

As a matter of fact, the RFC does not seem to stipulate how the existence of a collection should be tested. However there came an advice from the ietf-caldav mailing list to use PROPFIND for that purpose. ical4j will probably be patched accordingly.

Anyway, SOGO should not reply GET requests to existing calendars with 501. It either should not advertise its support for GET in OPTIONS or it should reply with 20x.

Just for completeness: the requests for non-existing calendars are as expected: SOGo returns 404 for all of PROPFIND, OPTIONS and GET.

Steps to reproduce:

(1) OPTIONS request for an existing calendar
curl -X OPTIONS -u sogo:sogo -v http://sogo.example.com/SOGo/dav/sogo/Calendar/personal/
< HTTP/1.1 200 Ok
< Date: Wed, 07 Dec 2011 04:15:36 GMT
< content-length: 0
< content-type: text/plain; charset=UTF-8
< dav: 1, 2, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-proxy, calendar-access, calendar-auto-schedule
< allow: GET, HEAD, POST, OPTIONS, MKCOL, MKCALENDAR, DELETE, PUT, LOCK, UNLOCK, COPY, MOVE, PROPFIND, SEARCH
< Via: 1.1 sogo.example.com
< Vary: Accept-Encoding

(2) GET for an existing calendar
curl -X GET -u sogo:sogo -v http://sogo.example.com/SOGo/dav/sogo/Calendar/personal/

< HTTP/1.1 501 Request failed
< Date: Wed, 07 Dec 2011 04:17:39 GMT
< content-length: 191
< content-type: text/html; charset="iso-8859-1"
< Via: 1.1 sogo.example.com
< Vary: Accept-Encoding
< Connection: close
<
<?xml version="1.0" encoding="ISO-8859-1"?>
<html xmlns="http://www.w3.org/1999/xhtml&quot;>
<body><h3>An error occurred during object publishing</h3><p>no WebDAV GET support?!</p></body>
</html>

TagsNo tags attached.

Activities

wsourdeau

wsourdeau

2011-12-07 14:17

viewer   ~0003130

This is not a bug. DAV does not specify anything with regards to "GET" on collections. The bug is in your client library. OPTIONS and PROPFIND are indeed good method to use to test for the validity of a collection. 501 seems to be a good response code for that case, even though 405 might be a better one.

wsourdeau

wsourdeau

2011-12-07 14:21

viewer   ~0003131

I am going to modify the title of this bug report as it should indeed not return "GET" in the "OPTIONS" response.

gazda

gazda

2011-12-07 14:26

reporter   ~0003132

OK

Issue History

Date Modified Username Field Change
2011-12-07 08:26 gazda New Issue
2011-12-07 14:17 wsourdeau Note Added: 0003130
2011-12-07 14:17 wsourdeau Status new => closed
2011-12-07 14:17 wsourdeau Resolution open => no change required
2011-12-07 14:21 wsourdeau Note Added: 0003131
2011-12-07 14:21 wsourdeau Status closed => new
2011-12-07 14:21 wsourdeau Summary GET on existing calendar returns HTTP 501 => GET on existing calendar returns HTTP 501 while advertised in the allowed methods with OPTIONS
2011-12-07 14:26 gazda Note Added: 0003132