Open Bug 327933 Opened 18 years ago Updated 2 years ago

Publishing event returns error:"Status code: 412: Precondition Failed"

Categories

(Calendar :: Internal Components, defect)

Product:
Calendar
Component:
Internal Components
Type:
defect

Tracking

(Not tracked)

People

(Reporter: pedro.madeira, Unassigned)

References

Details

Attachments

(5 files, 1 obsolete file)

Full Sunbird HTTP Conversation with IIS
23.37 KB, application/pdf
Details
disable webdav etag check
1.87 KB, patch
dmosedale
: first-review+
Details | Diff | Splinter Review
alternative patch [checked in]
3.29 KB, patch
dmosedale
: first-review+
Details | Diff | Splinter Review
work in progress to fix principal issues; v1
5.58 KB, patch
Details | Diff | Splinter Review
HTTP log of a failed session.
15.14 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060129 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060216 Mozilla Sunbird/0.3a1+

I have 3 published calendars in a windows server.
With clients 0.3 alpha 1 release, users can load the calendars and publish events into them.

With nightly build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060216 Mozilla Sunbird/0.3a1+ I can open the calendars but I can't publish events or tasks. I get the following error:

There has been an error reading data for calendar: afina2005. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss.  You may change this setting by choosing 'Edit Calendar'.

Error Number: 0x0
Description: Publishing the calendar file failed
Status code: 412: Precondition Failed

This is happening with all nightly builds for some time  now.

Reproducible: Always

Steps to Reproduce:
1.Download a Sunbird nightly build
2.Subscribe to a remote calendar
3.Try to publish an event

Actual Results:  
There has been an error reading data for calendar: afina2005. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss.  You may change this setting by choosing 'Edit Calendar'.

Error Number: 0x0
Description: Publishing the calendar file failed
Status code: 412: Precondition Failed

Expected Results:  
The event should get published.
Can try to find the last nightly build where it works and the first nightly build where it fails to narrow down the regression window?
This is probably not a regression at all, but merely Sunbird noticing a case where there would have been dataloss and aborting the upload.  In the past, Sunbird would have silently written the file anyway, and data would have been lost.  What this error indicates is that between the time the user last read the file and the time they started the upload, the file on the server changed.  I believe there are bugs in the calendaring code that can trigger this, probably stuff related to the queueing the ICS provider, as I've seen it when doing a bunch of changes in quick succession from the same Lightning instance.
Status: UNCONFIRMED → NEW
Ever confirmed: true
When I try to create a calendar file with the latest nightly trunk build I get the following error:

Error Number: 0x804a100
Description: [Exception... "Component returned failure code: 0x804a0100 [calIICSService.parseICS]"  nsresult: "0x804a0100 (<unknown>)"  location: "JS frame :: file:///usr/local/sunbird/components/calICSCalendar.js :: anonymous :: line 212"  data: no]
If I start Sunbird from a command line shell and when I enter an event I observe a line stating "false". I don't know if this is normal or not.

/usr/local/sunbird/sunbird
error creating table cal_calendars -- probably already exists
error creating table cal_calendars_prefs -- probably already exists
Starting calendar alarm service
observer added
false ("This appears when I try to publish the event")
observer removed

Do you need a more detailed dump? How do I generate one?
Note that the bug do not appear when using WebDAV/FTP protocol. I only get it with HTTP/WebDAV protocol. The config on which the bug is appeared is written below :

Sunbird build : 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060423 Mozilla Sunbird/0.3a1+
[tested with most nightly builds since Apr 10th]

WEBdav Server : Microsoft IIS v5
Protocol : HTTP or HTTPS (WebDAV)

Error obtained when changing/adding/removing any event on the remote calendars
<<<
There has been an error reading data for calendar: xxxx. It has been placed in read-only mode, since changes to this calendar will likely result in data-loss.  You may change this setting by choosing 'Edit Calendar'.
Error Number : 0x0
Description : Publishing the calendar file failed
Status code: 412: Precondition Failed
<<<
Workaround:
1. If you publish first event, Sunbird will return the specified error.
2. Edit the calendar's properties and remove the read-only check set by Sunbird when the error ocurred.
3. Now republish the same event and no error will ocurr.
4. You can now publish all events for the same calendar with no errors until you close and open Sunbird again.
Does this bug still happen with recent nightly builds? The workaround described in comment 5 was for a bug that should be fixed now.
Yes, bug described in comment 5 still happen with 2006/04/23 nightly build (last night).

In return, the bug do not happen with Sunbird release 0.3a1 (regression ?)
Creating a new remote calendar works fine for me (using webdav and apache)

status 412 means that the server thinks the file was changed on the server after the last publish. Either the server is broken, or sunbird uses the wrong combination of headers. An http log might help here, but i'm not sure what the easiest way to create one is.
You can find below the dump of the HTTP conversation between MS-IIS server and Sunbird when trying to republish a remote calendar (just before Sunbird shows the error message)

PUT /[...].ics HTTP/1.1
Host: [...]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060424 Mozilla Sunbird/0.3a1+
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If: (["f0dec28db367c61:968"])
Content-Length: 2749
Content-Type: text/calendar

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
[...]
END:VCALENDAR


HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.1
Date: Mon, 24 Apr 2006 18:28:56 GMT

HTTP/1.1 412 Precondition Failed
Server: Microsoft-IIS/5.1
Date: Mon, 24 Apr 2006 18:28:56 GMT
Connection: close
Content-Type: text/html
Content-Length: 4449

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html dir=ltr>
<head>
<META NAME="ROBOTS" CONTENT="NOINDEX">
<title>Impossible d'afficher la page</title>
<META HTTP-EQUIV="Content-Type" Content="text-html; charset=Windows-1252">
</head>
[...]
</html>
Can you also get a http dump from right after starting sunbird? That should contain an etag, that later get used in the put-request, the request that fails.
Two different ETag are passed by the webserver
one in GET answer, here : "f0dec28db367c61:968"
one in PROPFIND answer, here : "f0dec28db367c61:1188"

Seems like IIS is waiting for the second one because on the first attempt to publish the calendar, Sunbird send the first one and IIS return error 412.
When unchecking "read-only" like in comment 6, Sunbird send the second one and there is no more error returned.
[See attached PDF file to get full HTTP conversation]

What make Sunbird decide between one or other ETag ? Does apache also give two different ETag ?


I can confirm the described behaviour with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060501 Mozilla Sunbird/0.3a2 and remote calendars on Apache WebDAV 2.0.54. 

The error.log of the Apache servers says:
   (2)No such file or directory: The precondition(s) specified by the 
   "If:" header did not match this resource. At least one failure is 
   because: an entity-tag was specified, but the resource's actual ETag 
   does not match.  [412, #0]

In contrast to comment #6, I can publish only one event after having unchecked the "read-only" option for the calendar. The error reoccurs for the second event.

In addition, publishing an event causes two messages in the JavaScript Console:
1. Security Error: Content at 
   moz-nullprincipal:{6c0d1020-8a98-4f26-b782-2783c66adeb2} may not load or 
   link to http://remote_address_of_calendar.
2. Security Error: Content at 
   moz-nullprincipal:{38f600bc-ccde-4f31-ba71-9f01f611a275} may not load or 
   link to about:blank.

Publishing events on a test calendar on www.icalx.com works fine but also leads to the first message in the JavaScript Console. The second one does not appear. 
Server Software : IIS 5.1
Client Software (1) : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 Mozilla Sunbird/0.3a1+
Client Software (2) : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060501 Mozilla Sunbird/0.3a2
(tested with both client softwares, behaviors described below are the same)


** CONCERNING PUBLISHING ERROR (Webserver error 412) **
I tested again with latest nighly builds mentionned above and Webdav/HTTP protocol. The behavior is now slighly different :
1) when I first try to publish a change to a remote calendar, I still get exactly the same error message as mentionned in comment #5
2) applying the workaround from comment #6 no longer works : I get the following error message
<<<
There has been an error reading data for calendar: xxxx
Error number: 0x0
Description: Publishing the calendar file failed
Status code: 412: Precondition Failed
<<<
(notice that the error message is shorter but details are the same)
So now, I can't do any change to a remote calendar (not even one as described in comment #14 for apache)


** CONCERNING JAVASCRIPT ERRORS MENTIONNED IN COMMENT #14 **
I tested using remote calendars with following protocols :

WebDav/HTTP protocol:
Both Javascript security errors occurs. Note that the ID given between brackets changes each time you try to publish the calendar.

"WebDav"/FTP protocol:
No Javascript errors are logged in the console.


Additional Note: "OS" should be changed to "All" by users who have sufficient privilege to do so.
(In reply to comment #15)
> [...]
> So now, I can't do any change to a remote calendar (not even one as described
> in comment #14 for apache)
> [...]

The same behaviour for me with newest Gecko/20060503 Mozilla Sunbird/0.3a2. I now realized that it is a reload of the remote calendar (and of course unchecking "read only") that enables publishing one more event.

Since IIS and Apache are pretty popular http/webdav servers I suggest to change severity from normal to major or even to critical because it is no more possible to work with remote calendars.

Are you sure that there isn't something external changing the remote calendar files? (like another instance of sunbird, maybe on some other computer, or some other app)
The error you get means that the file was modified since the last reload, and so can't be published anymore. Publising would mean overwriting the remote changes, something that's not wanted.
(In reply to comment #17)
> Are you sure that there isn't something external changing the remote calendar
> files? (like another instance of sunbird, maybe on some other computer, or some
> other app)

I can publish (change) one event and immediatly after this a second change fails. Since I am the only one who has access to this remote calendar I am quite sure that it wasn't changed in the meantime (some seconds).

> The error you get means that the file was modified since the last reload, and
> so can't be published anymore. Publising would mean overwriting the remote
> changes, something that's not wanted.

If I have well understood the functionality of remote calendars than it is the intention that another user can change the calendar. If I make a change, the actual version on the server is locked, reloaded, changed and published. Isn't that the way sunbird works on remote calendars?
Attached patch disable webdav etag check — — Splinter Review 
This patch disables etag checks using webdav again, based on the idea that bug 332840 caused the bug here.
It makes my webdav based calendar work again.
Assignee: base → mvl
Status: NEW → ASSIGNED
Attachment #220809 - Flags: first-review?(dmose)
Comment on attachment 220809 [details] [diff] [review]
disable webdav etag check

r=dmose.  I would suggest that we should try and get a hold of bz, however, and work through the real bug.  Assuming the real fix isn't too scary, I'd suggest that we should be willing to take it for 0.3a2, if we have the opportunity to land it.
Attachment #220809 - Flags: first-review?(dmose) → first-review+
Attached patch alternative patch [checked in] — — Splinter Review 
This patch only disables the etag check on trunk, because it should still work on branch. But I couldn't test that, because i don't have a branch build.
Attachment #220835 - Flags: first-review?(dmose)
Comment on attachment 220835 [details] [diff] [review]
alternative patch [checked in]

r=dmose
Attachment #220835 - Flags: first-review?(dmose) → first-review+
Both patches (attachment 220809 [details] [diff] [review] and attachment 220835 [details] [diff] [review]) work for me with Gecko/20060504 Mozilla Sunbird/0.3a2. Thanks!
Comment on attachment 220835 [details] [diff] [review]
alternative patch [checked in]

Patch checked in. Leaving bug open to track re-enabling the etag check once webdav works again.
Attachment #220835 - Attachment description: alternative patch → alternative patch [checked in]
OS: Linux → All
Hardware: PC → All
This patch makes one of the principal errors that we were seeing on the system console go away.  Unfortunately, it doesn't actually fix the problem.  We're still seeing messages like this:

Security Error: Content at moz-nullprincipal:{77721a70-dd99-41ab-a547-d5735bee2868} may not load or link to about:blank.

bz: any thoughts here?
How about we check whether the null principal thing is a problem or just console spew?  If you comment out the null principal stuff at http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#906 and http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#1274 does that fix things for you?
Client Software :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060507 Mozilla Sunbird/0.3a2

Server Software :
Microsoft IIS 5.1

I tested again with the latest release (build identifier mentionned above).

** CONCERNING PUBLISHING ERROR (Webserver error 412) **
The error 412 is still happening when I try to publish the first change to a remote WebDAV calendar on an IIS webserver. The workaround in comment #6 can make publishing to work.

** CONCERNING JAVASCRIPT ERRORS MENTIONNED IN COMMENT #14 **
There are no more javascript security error logged into the console

Bug 332840 has been fixed. Should the patch (attachment 220835 [details] [diff] [review]) be backed out again?
Just a thought: I recall the conversation between client and server when writing an event involved first reloading the calendar and directly after writing the event. Has this been changed? If I look at server logs this seems to be happening.
I am currently having this problem with Lightning (2007021403), is there a reason why the two fixes were never added to the release? This bug seems pretty serious to me, and I'm just wondering why its not been resolved in all this time...

The fix in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=327933#c6">comment #6</a> does work but not if someone else using the calendar makes a change...which is the whole point.
The reason to me is obvious, no one is actively working in solving this issue.
Blocks: 287612
Adding relnote status to this bug to get it back in the land of the living.  I just encountered it when testing multi-user edits to a shared WebDav calendar.  Can anyone else illustrate the remaining issues here succinctly for the 0.5 relnotes?
Keywords: relnote
afaik, this was a trunk-only bug. Do you see it on the branch now? What do you see on branch?
(In reply to comment #34)
> afaik, this was a trunk-only bug. Do you see it on the branch now? What do you
> see on branch?
> 
Yes we started seeing this on the branch when testing with two users updating a WebDav calendar simultaneously.This happened on the May 15 2007.


(In reply to comment #35)
> Yes we started seeing this on the branch when testing with two users updating a
> WebDav calendar simultaneously.This happened on the May 15 2007.

So two clients are trying to modify the same file at the same time? Then this is not a bug, but a feature! :) Sunbird tries to prevent you from overwriting the changes the other person made. That's why the message shows up. You are right, there should be syncing etc. But this bug was about this message showing when there really was only one person accessing the calendar file.
The issue of multiple users should be handled in a different bug. 
(In reply to comment #36)
> So two clients are trying to modify the same file at the same time? Then this
> is not a bug, but a feature! :) Sunbird tries to prevent you from overwriting
> the changes the other person made. That's why the message shows up. You are
> right, there should be syncing etc. But this bug was about this message showing
> when there really was only one person accessing the calendar file.
> The issue of multiple users should be handled in a different bug. 
> 
And we already have that bug filed: bug 329570
Keywords: relnote
Is someone still working on this. It seems quite important to me.
No longer blocks: 287612
Blocks: 287612
I still get this using Sunbird 2007061405 and 2007091107.

Client XP Pro Swedish, server OpenBSD 3.9 running Apache 1.3.29 (standard included in OBSD dist) with moddav 1.0.3p1.

Single user accessing webdav calendar, first attempt to write calendar will generate message "precondition failed", calendar has been placed in read-only mode. Server log says:

The precondition(s) specified by the "If:" header did not match this resource. At least one failure is because: an entity-tag was specified, but the resource's actual ETag does not match.  [412, #0]

Unchecking readonly flag of calendar makes updates work until Sunbird is restarted.

Attaching http log of typical session (http_header_log.zip).
Attached file HTTP headers of failed session (obsolete) — 

    
    

    
  
The log has the ETags replaced by some dummy value. Could you please re-create the logs, and don't change them? The etags are what matter here.
Also, there is no need to zip the files. Please upload as plain text. Much easier to read.

    
    

    
  
ctalbert asked me to update here about my patch.  Unfortunately, that patch was something of a stab in the dark, so I don't have a ton of advice to offer.  Comments 19-27 are the interesting ones w.r.t. the principal stuff, at least.  Someone needs to take that patch, work out the error message problem, probably starting with bz's comment 27, and after that's worked out, have a discussion with somebody who understands security principals better than I do and convince themselves that the final patch is doing something reasonable from a security standpoint.

        Attachment #280515 -
        Attachment is obsolete: true

    
  
Flags: blocking-calendar0.8?

    
    

    
  
(In reply to comment #19)
> This patch disables etag checks using webdav again, based on the idea that bug
> 332840 caused the bug here.
Just for reference: It looks like bug 324601 has been the causer.


    
    

    
  
Any progress? Thanks.
Bug still occurs with Lightning 0.7.

Here are the scenarios that show the bug:

Mozilla Thunderbird version 2.0.0.9 (20071031)
Lightning 0.7 (build 2007102304)
box.net DAV

-- First event on New DAV ical calender --
OK

-- Subsequent New Event on DAV ical calendar --

There has been an error reading data for calendar: TestTimes.

Error number:	0x0
Description: 	Publishing the calendar file failed
		Status code: 412: Precondition Failed

-- Publish local ical for first time --
OK
(but dialog doesn't really indicate success - blue scrolling bar just disappears, success confirmed by reload)

-- Publist local  ical for subsequent times --
OK 
(but dialog doesn't really indicate success - blue scrolling bar just disappears, success confirmed by reload)

    
    

    
  
We're not going to block 0.8 for this bug, but we'll of course accept patches.
Flags: blocking-calendar0.8? → blocking-calendar0.8-
Flags: blocking-calendar0.8- → wanted-calendar0.9?
Flags: wanted-calendar0.9? → wanted-calendar0.9+

    
    

    
  
Running TCPdump to watch the HTTP transaction while reproducing this bug shows that on an OpenBSD 4.2 server, apache-httpd-2.2.4 and mod_dav-1.0.3p4 DO NOT share ETag formats.


The ETag from the HTTP GET response header in one case was "e152753644833e3ca950b18f30c74751d2cb8f9d"

The DAV:getetag from the HTTP PROPFIND response [at the same time] was "201fa1-285-48121c40"


When Thunderbird sends its HTTP PUT request with the first (strong) ETag from GET, Apache rejects it with the 412 error code. Thunderbird then gets the second ETag from the DAV:getetage propset. Now the next time Thunderbird sends its PUT request, it will send that second ETag, and Apache likes it!

I was unable to force Thunderbird to initially get the DAV:getetag property, which would obviously fix this whole issue once and for all (see attachment 219652 [details] where this same series of events occurs also with IIS), because I do not know where to begin. I had a look through Lightning's /js/calICSCalendar.js file but could not make it perform the necessary PROPFIND before the PUT, and I don't know where else to place a patch.

One work-around would be solving the format discrepancy on the server-side, but many people (especially IIS users who experience the problem) cannot make those changes.

    
    

    
  
A small update: It is not Apache 2 that I am using, but the default Apache 1.3 that is part of OpenBSD Base. It contains a modification to the generation of ETags which is the reason for the SHA1 hash that it returns. I have no idea if the Apache 2 port has a similar modification.

It would be nice to see a work around here on the client side, but for now I will just recompile mod_dav using the same SHA1 ETag generation.

    
    

    
  
mvl, are you still working on this one? What's the status?
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: blocking-calendar1.0?

    
    

    
  
I'm still having this problem with today's nightly build, using Apache 2.2.9 on RedHat 5.2.  This is what appears in the apache logs when trying to update a calendar.

==> access_log <==
1.2.3.4 - - [22/Dec/2008:13:23:51 +1100] "GET /calendars/Merricks.ics HTTP/1.1" 200 2157 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081221 Calendar/1.0pre"
1.2.3.4 - pza [22/Dec/2008:13:23:52 +1100] "PUT /calendars/Merricks.ics HTTP/1.1" 412 344 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081221 Calendar/1.0pre"
1.2.3.4 - - [22/Dec/2008:13:23:53 +1100] "GET /calendars/Merricks.ics HTTP/1.1" 200 2157 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081221 Calendar/1.0pre"

==> error_log <==
[Mon Dec 22 13:23:52 2008] [error] [client 1.2.3.4] (11)Resource temporarily unavailable: The precondition(s) specified by the "If:" header did not match this resource. At least one failure is because: an entity-tag was specified, but the resource's actual ETag does not match.  [412, #0]

    
    

    
  
mvl, I hope you don't mind if I reset this bug to NEW and assigned to nobody@m.o.
Assignee: mvl → nobody
Status: ASSIGNED → NEW

    
    

    
  
Hello,
Same problem with Sunbird. I found out that the origin was in the Apache 2 compression : mod_deflate modify etags in some way which is not compatible with the use of Sunbird and Webdav. I planning to create special rule for ics and mod_deflate.
Flags: blocking-calendar1.0?

    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: