Closed Bug 379498 Opened 14 years ago Closed 13 years ago

WebDAV publish not publishing every time.

Categories

(Calendar :: Provider: ICS/WebDAV, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 387559

People

(Reporter: kelv, Unassigned)

Details

(Whiteboard: [0.5 publish fails])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Thunderbird version 2.0.0.0 (20070326) + Lightning nightly build for 2nd May 2007

The error log shows this.

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Thunderbird/Profiles/tzqnsmqq.testing/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calICSCalendar.js :: anonymous :: line 378"  data: no]
Source File: file:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Thunderbird/Profiles/tzqnsmqq.testing/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calICSCalendar.js
Line: 378

Reproducible: Always

Steps to Reproduce:
1. Start Thunderbird.
2. Go to month view and modify the time on an event by a few minutes.

I can't get it to do this every time though. Sometimes it does publish.

Actual Results:  
You don't get asked if you want to publish, which is normal after TB knows the login information, but then the published ics file on the WebDAV server does not reflect the changes. After closing Thunderbird the process continues to run even though no windows are open, as demonstrated by looking in Task manager.

Expected Results:  
I changed an event start time from 7pm to 6.45pm and it didn't change.
I am having the same issue here with both Lightning and Sunbird.  I am connecting to an Apache 1.3.33 server with DAV 1.0.3.

Apache side I see an attempt to PUT the calendar after change with a 401 error, and then nothing else.  There is no further attempt to contact the web server for reload, modify, etc.

Error on Sunbird/Lightning is identical except for the jsFrame and the line number:
Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///Applications/Sunbird.app/Contents/MacOS/components/calICSCalendar.js :: anonymous :: line 378"  data: no]
Source File: file:///Applications/Sunbird.app/Contents/MacOS/components/calICSCalendar.js
Line: 378
I am having the same issues with Sunbird 0.5 final.  Here is my Error Console message:

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Sunbird/components/calICSCalendar.js :: anonymous :: line 383" data: no]
Source File: file:///C:/Program%20Files/Mozilla%20Sunbird/components/calICSCalendar.js
Line: 383 

I tried everything I could think of to get this to work including deleting my default profile, uninstalling and reinstalling Sunbird.  It still has the same issue.

I had to delete my Sunbird profile and install 0.3.1 to get this to be able to publish events again.
Reporter, could you provide detailed steps to reproduce the issue starting with a clean profile. For example what preferences do you change, what type of calendars you create, what is type and version of the server you use etc.

If your are using Apache also check out the last point on [http://www.mozilla.org/projects/calendar/releases/common0.5.html].
Yes, this is related to bug 380291 [https://bugzilla.mozilla.org/show_bug.cgi?id=380291] (the last point on Other issues in Lightning & Sunbird 0.5).

I really hope there is a fix in the works for this as it would be crippling to have to have an insecure WebDAV calendar system in order to use Sunbird/Lightning 0.5, which I don't think people would do.

I know for a fact our maintainer of the WebDAV calendars will not just allow free access to everyone's calendars, so we can't use Sunbird/Lightning 0.5.(In reply to comment #3)

> Reporter, could you provide detailed steps to reproduce the issue starting with
> a clean profile. For example what preferences do you change, what type of
> calendars you create, what is type and version of the server you use etc.
> 
> If your are using Apache also check out the last point on
> [http://www.mozilla.org/projects/calendar/releases/common0.5.html].
> 

I have modified my httpd.conf as recommended in the release notes (added PROPFIND to the LimitExcept list).  Now I now longer have my calendar events disappear after a modify, however I still get the error.  Here's is my current settings for my /dav directory:

DAVLockDB /Library/WebServer/davlocks/DAVLockDB
DAVMinTimeout 600

<Location /dav/>
    DAV On
    AuthType Basic
    AuthName "WebDAV Restricted"
    AuthUserFile "/etc/httpd/passwords/webdav.access"
    <LimitExcept GET HEAD OPTIONS PROPFIND>
        Require user webdav
    </LimitExcept>
</Location>

The calendar I created was as follows:
New... --> On the Network --> iCalendar(ICS) --> Location: http://www.secretlair.net:8888/dav/Events.ics --> Name: Events

Error text is the same as above. Access logs still show 401 return code on a PUT, then nothing.

I added PUT to the LimitExcept list and it worked like a charm, but obviously that will not be a long term solution (especially now that the URL is here :) )

Whiteboard: [0.5 publish fails]
During QA chat we decided to follow up this issue with Bug 387559 that has clear STR and information on the regression range.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 387559
Bug 387559 is fixed now. I'd like you to retest with a Sunbird or Lightning 0.7pre (20070912) or newer build if your issue is entirely fixed now.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.