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.
Doug, is this related to our discussion re: passing a context through the load process? I take it that option won't work?
I think this solution is more generic.
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.
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.
I still think this should be done using the context parameter.
Target Milestone: M15
Doug's handling this with his securityInfo attribute.
Assignee: warren → dougt
Fixes checked in.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Adding verifyme keyword
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.