Bug 581008 removed general.useragent.extra.* support therefore we should remove our preference from default preferences. We should investigate if CalDAV server developers still require information about the used Lightning version. If yes we need to find a new solution for this.
Yes we do :) I think lightning should merge its user agent information to the "default" useragent before any requests sent as described here: https://developer.mozilla.org/en/Setting_HTTP_request_headers -> calling setRequestHeader("User-Agent","Lightning/...", with aMerge set to true I think it is important that we keep on using the User-Agent header because on the server side, the User-Agent Header is used a lot, for example in the default Apache access logs where it can be used to identify issues with different lightning versions.
I agree, I was hoping that core would reconsider in specific cases, but it seems there's no easy way to allow selective access to such prefs. I'd vote for a method in calProviderUtils.jsm that does the adding, which needs to be called in the caldav provider and any other providers that send http requests. Simon, if you agree, could you whip up a patch?
We should take this for the beta, in order to not lose the possibility to do statistical data. Maybe we can hook in even more aggressive, so all http-requests get the Calendar UA extension. This will allow pages like the Thunderbird Whats New tab to be shown correctly. This should be possible using an nsIObserverService notification, I believe it was http-on-something-request.
Whiteboard: [needed beta][no l10n impact]
This patch should take care
Assignee: nomisvai → philipp
Attachment #522090 - Flags: review?(nomisvai)
Comment on attachment 522090 [details] [diff] [review] Fix - v1 I'll take anyone's review :-)
Whiteboard: [needed beta][no l10n impact] → [needed beta][no l10n impact][needs review]
Comment on attachment 522090 [details] [diff] [review] Fix - v1 Looks good, r=nomisvai, just a little note: Typo in + classDescription: "Calendar webcal(s) protocal handler",
Attachment #522090 - Flags: review?(nomisvai) → review+
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/2e0ce8604475> -> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Backported to comm-miramar <http://hg.mozilla.org/releases/comm-miramar/rev/835f14e2c3ac>
Target Milestone: Trunk → 1.0b4
Whiteboard: [needed beta][no l10n impact][needs review] → [needed beta][no l10n impact]
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110601 Firefox/7.0a1 SeaMonkey/2.2a1pre ID:20110601003002 with Lightning 1.1a1pre nightly dated 2011-06-01 The Lightning version had already disappeared from the UA string as mentioned in comment #0. Now general.useragent.extra.lightning has been renamed calendar.useragent.extra in about:config. => VERIFIED.
Status: RESOLVED → VERIFIED
Sorry I missed that in my first review: When calling setRequestHeader, the "merge" flag seem to work for the User-Agent header (it's just a big string, not a multi-valued header.), I think it is important we preserve the Thunderbird version as well, maybe we could try calling getRequestHeader() and appending the lightning name/version to the new value. Reopening.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This is already followed up in Bug 660522.
Another candidate to go into comm-aurora and comm-beta too?
Marking fixed again, see bug 660522. I believe the initial patch was landed before the aurora branching.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.