Closed
Bug 363085
Opened 18 years ago
Closed 15 years ago
Not possible to enter a webdav share that requires SSLVerifyClient
Categories
(Calendar :: Provider: ICS/WebDAV, defect)
Calendar
Provider: ICS/WebDAV
Tracking
(Not tracked)
RESOLVED
FIXED
1.0b1
People
(Reporter: sebo.moz, Assigned: timeless)
Details
Attachments
(1 file)
1.12 KB,
patch
|
Fallen
:
review+
|
Details | Diff | Splinter Review |
As I understand the issue, this is not supported by mozilla. however, firefox gives an error dialog whereas sunbird silently failes (with a javascript error: Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.requestSucceeded]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: chrome://calendar/content/publish.js :: anonymous :: line 265" data: no] Source File: chrome://calendar/content/publish.js Line: 265 STR: 1. configure your apache WebDAV share to require SSLVerifyClient 2. try to access it (subscribe to it) results: silent failure + javascript error
Comment 1•17 years ago
|
||
Does this help? http://forums.mozillazine.org/viewtopic.php?t=511815 Also, did you use an url like: https://user@server.com/calendar.ics (so with the user in the url)
Comment 2•16 years ago
|
||
Sebo, if SSLVerifyClient is not supported by mozilla (really? I use certs to login to cacert.org, isn't that example use of SSLVerifyClient?), please add a dependant bug from the core/network component. For the lazy (like me), please also add the needed steps to set this up in apache, including where to put the client certificate in what format :-)
Assignee: nobody → timeless
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #327501 -
Flags: review?
Comment 4•16 years ago
|
||
Comment on attachment 327501 [details] [diff] [review] ch isn't a defined variable and this code was always somewhat broken >Index: mozilla/calendar/resources/content/publish.js So this bug was in the publish code only? I recently set up a SSLVerifyClient host and didn't encounter any problems. > try { > channel = request.QueryInterface(Components.interfaces.nsIHttpChannel); >- dump(ch.requestSucceeded+"\n"); >+ var requestSucceeded = channel.requestSucceeded; I'd prefer to have define requestSucceeded; outside of the try block. Although js vars have function scope, I think its easier to read. r=philipp for the code, this fix is obviously needed, but I haven't had a chance to test if it actually fixes the bug (does it?)
Attachment #327501 -
Flags: review? → review+
Updated•16 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 5•15 years ago
|
||
Fallen: timeless has long since declared patch bankruptcy, so if you want this to land, you'll need to land it. Personally, I'd ask myself wtf that dump() is doing - requestSucceeded is a boolean, so it's just going to dump false\n with absolutely no context, isn't it?
Whiteboard: [new patch? just land?]
Comment 6•15 years ago
|
||
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/d527cea45fc5> -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Comment 7•15 years ago
|
||
If the original issue still shows up, please reopen.
Whiteboard: [new patch? just land?]
Comment 8•13 years ago
|
||
These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".
Target Milestone: 1.0 → 1.0b1
You need to log in
before you can comment on or make changes to this bug.
Description
•