1723415 - Public webcal calendars with bad Content-Type headers can't be added

Status: RESOLVED FIXED

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

Description

[michael]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

• Click on "New calendar"
• …In Network
• Enter URL to a calendar that does not need credentials
• Check the field "This calendar does not need credentials"
• click Find calendars

Actual results:

• I am asked for a password
• If I click "sign in" without entering a password, the prompt is shown again. If I click cancle, I get the message that logging in was not possible

Expected results:

• No password prompt, just add the calendar.

Note: the same URL worked with Thunderbird 78.12 – so it is a regession.

Comment 1

[Geoff Lankow (:darktrojan)]

Please post the URL of a calendar you can't add. Also if you're not using the latest 91 beta (5), please update.

Comment 2

[mw]

Since the latest 91 (but possibly longer, I was using some 7x branch before yesterday), adding ical calendars will fail if the server's content-type is sent as text/html and not text/calendar. Already added calendars will still work if text/html is sent, though. Related?

There seems to have been some changes in auto-detection and the error messages are not helpful.

Comment 3

[mw]

Test case for adding calendars with different content-type:
https://magnuswedberg.com/docs/thunderbirdical.php?html
https://magnuswedberg.com/docs/thunderbirdical.php?ical

Result:
The first URL will produce the error "Could not find calendars at this location. Please check your settings."
The second URL will work.
Content is the same (static, as a test), the only difference is the header.

Comment 4

[Lasana Murray]

Why do we want to add calendars serving the wrong content type header? Edit: rather, why add content that is telling us it is not calendar data?

Comment 5

[Lasana Murray]

Attachment: Bug 1723415 - Allow other content types when detecting remote calendars. r=darktrojan

Comment 6

[Magnus Melin [:mkmelin]]

(In reply to Lasana Murray from comment #4)

Why do we want to add calendars serving the wrong content type header? Edit: rather, why add content that is telling us it is not calendar data?

Postel's law: be conservative in what you send, be liberal in what you accept
From the end user perspective, they want to use the calendar, and they could, so we should let them.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/184fe018707a
Allow other content types when detecting remote calendars. r=darktrojan

Comment 8

[Rob Lemley [:rjl]]

Comment on attachment 9240921 [details]
Bug 1723415 - Allow other content types when detecting remote calendars. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): yes
User impact if declined: ical calendars where the server sends wrong mime-type (text/html) wont be added
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky):
Small change, would be good to get this into 91.2.0

Comment 9

[Wayne Mery (:wsmwk)]

Comment on attachment 9240921 [details]
Bug 1723415 - Allow other content types when detecting remote calendars. r=darktrojan

[Triage Comment]
Approved for beta

Comment 10

[Rob Lemley [:rjl]]

Thunderbird 93.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/cc493699361c

Comment 11

[Magnus Melin [:mkmelin]]

Comment on attachment 9240921 [details]
Bug 1723415 - Allow other content types when detecting remote calendars. r=darktrojan

[Approval Request Comment]
Regression caused by (bug #): 91 cycle caldav rework(?)
User impact if declined: per bug summary
Testing completed (on c-c, etc.): c-c and beta
Risk to taking this patch (and alternatives if risky): not risky

Comment 12

[Wayne Mery (:wsmwk)]

Comment on attachment 9240921 [details]
Bug 1723415 - Allow other content types when detecting remote calendars. r=darktrojan

[Triage Comment]
Approved for ers91

Comment 13

[Rob Lemley [:rjl]]

Thunderbird 91.2.1:
https://hg.mozilla.org/releases/comm-esr91/rev/9c8982599ed7