Closed
Bug 29646
Opened 25 years ago
Closed 24 years ago
nsIChannel should declare if it is a secure/encrypt channel
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
M15
People
(Reporter: dougt, Assigned: dougt)
Details
(Keywords: verifyme)
I would like the ablity to test if a channel is secure without having to QI it. adding: attribute boolean secure; to the nsIChannel.idl would work for me. The implementers of the this interface could either advertise that the channel is secure, as in the case for https, or return false for most other channels.
Comment 1•25 years ago
|
||
Doug, is this related to our discussion re: passing a context through the load process? I take it that option won't work?
Assignee | ||
Comment 2•25 years ago
|
||
I think this solution is more generic.
Comment 3•25 years ago
|
||
But Doug, as we discussed last night, knowing that the channel is secure just begs the question: what are you going to do with that information. At that point you need some way to get at the underlying socket so that you can play 20 questions with cartman. I think it would be better to have: readonly attribute nsISecurityInfo securityInfo; (although this may require some restructuring or trickery with cartman) or perhaps just: readonly attribute PRFileDesc securitySocket; either of which could return null for non-secure channels.
Comment 4•25 years ago
|
||
It may be more generic, but I'm not sure we want that??? We explictly are trying to keep fd's hidden from the user. There are times when channel's are layered (FTP proxies for example); I'm not sure we can guarantee that there's a 1-to-1 relationship between the URI the channel caches and the underlying connection fd. The whole idea is to keep the consumer away from the underlying transport.
Comment 5•25 years ago
|
||
I still think this should be done using the context parameter.
Comment 7•25 years ago
|
||
Doug's handling this with his securityInfo attribute.
Assignee: warren → dougt
Assignee | ||
Comment 8•24 years ago
|
||
Fixes checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•