Bug 1255140 - HTTP 412 errors when accepting some google calendar events
HTTP 412 errors when accepting some google calendar events
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Milan Crha
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-19 14:05 EDT by Peter Robinson
Modified: 2015-09-02 12:41 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-02 12:41:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output from: CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w (5.87 KB, text/plain)
2015-09-02 03:27 EDT, Nate Guerin
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 754480 None None None Never

  None (edit)
Description Peter Robinson 2015-08-19 14:05:27 EDT
On a number of regular occasions when accepting Google calendar requests I get the following error that I have no idea what it means. It might be valid or I might be doing something wrong but in that case evolution should present this as a useful error message to the user.

Unable to send item to calendar 'perobins@redhat.com'. Cannot receive calendar objects: Unexpected HTTP status code 412 returned (Precondition Failed) for URI: (private google calendar URL)

evolution-3.17.4-2.fc23.x86_64
evolution-ews-3.17.4-1.fc23.x86_64
evolution-data-server-3.17.4-1.fc23.x86_64
gnome-online-accounts-3.17.2-2.fc23.x86_64
Comment 1 Milan Crha 2015-08-20 11:11:08 EDT
Thanks for a bug report. That might be something with the meeting, maybe you are not listed as a direct attendee? Though even that case worked for me when I just tried.

If you've any reproducer event, could you close evolution, then run on console:
    $ CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
then run evolution and repeat the issue, please? Ideally click to accept/tentative/decline when the output on the console will settle, to easily distinguish between the old and the new output there. I'm interested only in that new output. Also maybe uncheck to send notice to the organizer, to not bother him/her with the tests (it seems the Google server sends the response anyway, somehow).

As a background, the error is due to some WebDAV failure, the Google server didn't provide more information in the header, thus this is what you get in the UI. I suppose they claim more detailed information in the response body, but that is HTML, which is not usable for the evolution UI in its raw form.
Comment 2 Nate Guerin 2015-09-01 07:46:15 EDT
I have reproduced this event and as requested.  The file with the output, though, contains all of my calendar events.  Is there anything in particular that you're looking for, that I could extract from the file so that not everything is included?
Comment 3 Milan Crha 2015-09-02 02:30:18 EDT
The main interesting part is just before the error, what was sent and what was received (received was the error, but I'm interested in whole server response, in case the body contains any more detailed information). From the preceding request sent to the server the event itself is not interesting, definitely not its private details, like email addresses, host names and such. On the other hand, UID, RECURRENCE-ID, RRULE and similar properties good to know about (SUMMARY, DESCRIPTION, LOCATION, ORGANIZER, ATTENDEE are those properties with private values, which you can safely remove/replace).
Comment 4 Nate Guerin 2015-09-02 03:26:10 EDT
Reproduction Steps:

1) Use two google calendar accounts
2) Set up a meeting on one of your accounts, inviting the other account as an attendee
3) Accept the meeting from account 2 as an attendee
4) From account 1, update the time of the meeting.  Send updates to the attendees.
5) Account 2 receives another meeting update.  Accept the update.  This is when the error mentioned above occurs.

@Milan, I've posted the output from the calendar-factory as you asked, from a bit before the error to after the error occurs.  I don't see too much information in it, but perhaps you'll see something different.
Comment 5 Nate Guerin 2015-09-02 03:27:06 EDT
Created attachment 1069277 [details]
output from: CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w

This is the output a bit before the error to after the error occurs from 

CALDAV_DEBUG=all /usr/libexec/evolution-calendar-factory -w
Comment 6 Milan Crha 2015-09-02 11:41:20 EDT
Thanks for the update. The log shows an interesting error:
> HTTP/1.1 2 Error resolving 'apidata.googleusercontent.com': No address associated with hostname

It's not the 412 error code, but looks quite serious. There can be multiple reasons for this error, being a temporary DNS issue, a proxy being involved, an /etc/hosts entry redirecting the address to a different place, and so on. Interestingly the request works and the server returns data despite the error.

I though to get part of the log before that 412 HTTP error and with it, but no problem, I'll try your steps here and let you know. I'm afraid it is related to the hostname issue though.
Comment 7 Milan Crha 2015-09-02 12:01:52 EDT
Okay, I am able to reproduce the error too. The related part of the log is:

> PUT /calendar/dav/user%40gmail.com/events/1od311fjm8obi0p1ojs0nr6n98%40google.com.ics HTTP/1.1
> Soup-Debug-Timestamp: 1441209312
> Soup-Debug: SoupSessionSync 1 (0x18e4e50), SoupMessage 20 (0x7f3558006740), SoupSocket 21 (0x1d251f0)
> Host: www.google.com
> User-Agent: Evolution/3.17.92
> If-Match: "63576892052"
> Content-Type: text/calendar; charset=utf-8
> Connection: close
>
> BEGIN:VCALENDAR
> ...
> END:VCALENDAR

with a response:

< HTTP/1.1 412 Precondition Failed
< Soup-Debug-Timestamp: 1441209312
< Soup-Debug: SoupMessage 20 (0x7f3558006740)
< Vary: X-Origin
< Content-Type: text/xml; charset=UTF-8
< Date: Wed, 02 Sep 2015 15:55:00 GMT
< Expires: Wed, 02 Sep 2015 15:55:00 GMT
< Cache-Control: private, max-age=0
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< Server: GSE
< Alternate-Protocol: 443:quic,p=1
< Alt-Svc: quic=":443"; p="1"; ma=604800
< Accept-Ranges: none
< Vary: Origin,Accept-Encoding
< Connection: close
< 
< <?xml version="1.0" encoding="UTF-8"?>
< <D:error xmlns:D="DAV:"/>

The precondion it is talking about is, in my case:
> If-Match: "63576892052"

I'm investigating further. I'd guess that the event changed on the server, but the local CalDAV has an old version of the event, with a different ETag. That's when the server updates the event automatically, on the email with the time update receive. That's only an idea, though.
Comment 8 Milan Crha 2015-09-02 12:41:47 EDT
(In reply to Milan Crha from comment #7)
> I'd guess that the event changed on the server, but the local CalDAV has an
> old version of the event, with a different ETag.

Yes, it is. So this is a write conflict, evolution tries to rewrite an event which changed on the server, with possibly old data. There is currently no way to deal with this. It will require user interaction, to decide what to do on the write conflict. I can semi-easily force the write, as it can be done when you Refresh the calendar first, and only then Accept the change of the time of the event, but it's not good to do automatically in general.

I moved this upstream as [1]. Please see [1] for any further updates. As a current workaround update the calendar on any conflicts, then repeat the acceptance.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=754480

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