Closed Bug 1792101 Opened 2 months ago Closed 2 months ago

CardDav fails to save changes to google, if name is not set on the card

Categories

(Thunderbird :: Address Book, defect)

Product:
Thunderbird
Component:
Address Book
Type:
defect

Tracking

(thunderbird_esr102 fixed, thunderbird106 fixed)

Status:
RESOLVED FIXED
Milestone:
107 Branch
Tracking Flags:
Tracking Status
thunderbird_esr102 --- fixed
thunderbird106 --- fixed

People

(Reporter: phil, Assigned: darktrojan)

Details

Attachments

(1 file)

Bug 1792101 - Ensure vCards have an `N` property when sending to Google. r=#thunderbird-reviewers
48 bytes, text/x-phabricator-request
wsmwk
: approval-comm-beta+
wsmwk
: approval-comm-esr102+
Details | Review

Steps to reproduce:

When setting up a new CardDav address book, changes fail to save back to the server due to 400 Bad Request.

This is on Thunderbird 102.1.2.

Here's an example from the error console:

PUT
https://www.googleapis.com/carddav/v1/principals/phil@ipom.com/lists/default/363986d2-6b5a-468f-8010-d5f9d0603b99.vcf
[HTTP/2 400 Bad Request 90ms]

	
PUT
	https://www.googleapis.com/carddav/v1/principals/phil@ipom.com/lists/default/363986d2-6b5a-468f-8010-d5f9d0603b99.vcf
Status
400
Bad Request
VersionHTTP/2
Transferred630 B (127 B size)

    	
    alt-svc
    	h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
    cache-control
    	private
    content-encoding
    	gzip
    content-length
    	129
    content-type
    	application/json; charset=UTF-8
    date
    	Thu, 22 Sep 2022 22:12:04 GMT
    server
    	ESF
    vary
    	Origin
    vary
    	X-Origin
    vary
    	Referer
    x-content-type-options
    	nosniff
    X-Firefox-Spdy
    	h2
    x-frame-options
    	SAMEORIGIN
    x-xss-protection
    	0
    	
    Accept
    	*/*
    Accept-Encoding
    	gzip, deflate, br
    Accept-Language
    	en-US,en;q=0.5
    Authorization
    	Bearer XXXXX
    Connection
    	keep-alive
    Content-Length
    	131
    Content-Type
    	text/vcard
    Host
    	www.googleapis.com
    Origin
    	https://www.googleapis.com
    Sec-Fetch-Dest
    	empty
    Sec-Fetch-Mode
    	no-cors
    Sec-Fetch-Site
    	same-origin
    TE
    	trailers
    User-Agent
    	Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2

Here's another example:

PUThttps://www.googleapis.com/carddav/v1/principals/phil@ipom.com/lists/default/0037b4e4-f4e3-4e4a-9a88-b8543dc4aa50.vcf
[HTTP/2 400 Bad Request 87ms]

	
PUT
	https://www.googleapis.com/carddav/v1/principals/phil@ipom.com/lists/default/0037b4e4-f4e3-4e4a-9a88-b8543dc4aa50.vcf
Status
400
Bad Request
VersionHTTP/2
Transferred630 B (127 B size)

    	
    alt-svc
    	h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
    cache-control
    	private
    content-encoding
    	gzip
    content-length
    	129
    content-type
    	application/json; charset=UTF-8
    date
    	Thu, 22 Sep 2022 22:12:04 GMT
    server
    	ESF
    vary
    	Origin
    vary
    	X-Origin
    vary
    	Referer
    x-content-type-options
    	nosniff
    X-Firefox-Spdy
    	h2
    x-frame-options
    	SAMEORIGIN
    x-xss-protection
    	0
    	
    Accept
    	*/*
    Accept-Encoding
    	gzip, deflate, br
    Accept-Language
    	en-US,en;q=0.5
    Authorization
    	Bearer XXXX
    Connection
    	keep-alive
    Content-Length
    	139
    Content-Type
    	text/vcard
    Host
    	www.googleapis.com
    Origin
    	https://www.googleapis.com
    Sec-Fetch-Dest
    	empty
    Sec-Fetch-Mode
    	no-cors
    Sec-Fetch-Site
    	same-origin
    TE
    	trailers
    User-Agent
    	Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2

There's also this error after the bad requests:

[Exception... "Sending card to the server failed, response was 400 Bad Request"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource:///modules/CardDAVDirectory.jsm :: _sendCardToServer :: line 400"  data: no] 4 CardDAVDirectory.jsm:400:24
    _sendCardToServer resource:///modules/CardDAVDirectory.jsm:400
    InterpretGeneratorResume self-hosted:1422
    AsyncFunctionNext self-hosted:632

Actual results:

400, bad request, see above.

Expected results:

200, and a saved card.

I can't reproduce this. Adding cards to a Google address book seems to work for me. However we've had a lot of reports about problems with Google calendars which make me suspect something is up with the Google servers, and maybe this is related.

Could you open the Developer Toolbox (under Tools > Developer Tools), go to the Network tab, then reproduce the problem? I'd like to see the card you're sending and the complete response from the server, which probably looks a bit like this:

<?xml version="1.0" encoding="UTF-8"?>
<D:error xmlns:D="DAV:">
 <D:valid-sync-token/>
</D:error>
Flags: needinfo?(phil)

I can't reproduce it making a random card. But I can if I save 3 address from an email, which then go into the "local" address book, and then I drag them to the Google address book. I'll try to also get that debug for you.

Flags: needinfo?(phil)

OK I repro'd, two cards were sent, both got 400s.

The request was definitely not in

BEGIN:VCARD
VERSION:4.0
FN:<firstname> <last name>
EMAIL;PREF=1:<lasntame>@<domain>com
UID:ebaf8806-a83c-44a8-9e00-420ce20408f1
END:VCARD

Response:

{
	"error": {
		"code": 400,
		"message": "Request contains an invalid argument.",
		"status": "INVALID_ARGUMENT"
	}
}

Oh wow, that's weird. I reproduced the issue, and it seems to be the lack of a name (N, not FN) that Google doesn't like.

status-thunderbird_esr102: --- → affected
Version: 6 Branch → unspecified

RFC2426 (vCard 3, which Google uses) specifies that the N property is required but RFC6350 (vCard 4) does not. It appears that Google enforces this.

This can't be fixed just by making the vCard serialiser add an N property to all version 3 cards, because sending a version 4 card to Google is a reasonable thing to do and it works otherwise.

Assignee: nobody → geoff
Status: NEW → ASSIGNED

Oh thanks @darktrojan! That gives me a nice easy work around - just set FN and LN (which seems to cause N to get set) and now those three cards sync properly.

Summary: CardDav fails to save changes → CardDav fails to save changes to google, if name is not set on the card

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/2e6bea815277
Ensure vCards have an N property when sending to Google. r=aleca

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch

Comment on attachment 9296283 [details]
Bug 1792101 - Ensure vCards have an N property when sending to Google. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): probably never worked
User impact if declined: contacts fail to save to CardDAV server
Testing completed (on c-c, etc.): landed this week
Risk to taking this patch (and alternatives if risky): low

Attachment #9296283 - Flags: approval-comm-beta?

Comment on attachment 9296283 [details]
Bug 1792101 - Ensure vCards have an N property when sending to Google. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Attachment #9296283 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9296283 [details]
Bug 1792101 - Ensure vCards have an N property when sending to Google. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): probably never worked
User impact if declined: contacts fail to save to CardDAV server
Testing completed (on c-c, etc.): in beta 4
Risk to taking this patch (and alternatives if risky): low

Attachment #9296283 - Flags: approval-comm-esr102?

Comment on attachment 9296283 [details]
Bug 1792101 - Ensure vCards have an N property when sending to Google. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr102

Attachment #9296283 - Flags: approval-comm-esr102? → approval-comm-esr102+
You need to log in before you can comment on or make changes to this bug.