nsIChannel should declare if it is a secure/encrypt channel

VERIFIED FIXED in M15

Status

()

Core
Networking
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: dougt, Assigned: dougt)

Tracking

({verifyme})

Trunk
All
Mac System 8.5
verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

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

18 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

18 years ago
I think this solution is more generic.

Comment 3

18 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

18 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

18 years ago
I still think this should be done using the context parameter.

Comment 6

18 years ago
=> M15
Target Milestone: M15

Comment 7

18 years ago
Doug's handling this with his securityInfo attribute.
Assignee: warren → dougt

Updated

18 years ago
Blocks: 31982
(Assignee)

Updated

18 years ago
Blocks: 13785
(Assignee)

Comment 8

18 years ago
Fixes checked in.  
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
(Assignee)

Updated

18 years ago
No longer blocks: 31982

Updated

18 years ago
No longer blocks: 13785

Comment 9

18 years ago
Adding verifyme keyword
Keywords: verifyme

Comment 10

18 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.