* William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
<snip>
http://www.ietf.org/rfc/rfc2817.txt
spells out methods that the server can -insist- that an upgraded connection is used, and the client can instigate an upgraded connection as well even if the server doesn't require it.
But under no conditions is https:// valid for an upgraded
connection. The connection never left port 80. The scheme
http:// describes a connection to (default) port 80 started as clear text, while the https:// scheme describes an explicit SSL connection to (default) port 443. Upgrade is an addendum
to the http:// scheme.
What fools are sitting there in the IETF ?! Couldn't they just define a new protocol (probably running on its own port) which allows specifying additional headers *before* SSL handshake starts or another SSL version, which allows passing additional info from client->server before certs are exchanged/checked ? Life could be so easy this way - probably too easy ...
Well, that were the same folks who invented IPSEC, which is not NAT'able.
It seems its the "we have enough IP addresses"-sickness ...
... its time to completely redesign HTTP ...
There's a well-known solution to this issue: STARTTLS. When you've written the RFCs and persuaded everyone to adopt them, let us know.
-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
