Not possible to enter a webdav share that requires SSLVerifyClient

RESOLVED FIXED in 1.0b1

Status

defect
RESOLVED FIXED
13 years ago
8 years ago

People

(Reporter: sebo.moz, Assigned: timeless)

Tracking

Trunk
1.0b1

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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

12 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)
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)

Comment 3

11 years ago
Assignee: nobody → timeless
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #327501 - Flags: review?
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+
OS: Windows XP → All
Hardware: PC → All
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?]
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/d527cea45fc5>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0
If the original issue still shows up, please reopen.
Whiteboard: [new patch? just land?]
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.