httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 29744] - CONNECT does not work over existing SSL connection
Date Mon, 20 Mar 2006 22:24:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29744>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=29744


wrowe@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED




------- Additional Comments From wrowe@apache.org  2006-03-20 22:24 -------
"Connecting via SSL to a proxy and issuing a CONNECT command is not specified 
in any RFC and thus it is no bug."

I can concur this is an enhancment request, but please cite where RFC 2818
cites POST or GET?  Should these be unsupported as well?  Suggestion to all
on this issue thread; stop making it personal.  The request is legitimate,
for example, to proxy through the DMZ to a private subnet using http: - the
request would not be encrypted (the backend only honoring http:) and should
therefore be carried with HTTP/1.1 CONNECT over ssl through the public net.

That said, there are two concerns;

1. Memory growth; there are already potential issues of unbounded memory
growth from bucket/brigade reallocations which have been reported by folks
attempting to serve or proxy streaming feeds such as audio/video.  Whatever
issues occur there, will also be evidenced here in this use case.  Not only
does the underlying bug need to be addressed but the 

2. Double-encryption; carrying an https: connection over a proxy CONNECT
tunnel would result in the client performing double SSL encryption, which
would be sub-optimal.  The client to proxy stream would reencrypt the client
to backend server encrypted channel.  This means it's especially important
for the client to backend server to employ any deflation of the stream first,
because no compression of the client to proxy connection is possible with
encrypted data.

There is no benefit to the double-encryption example cited above.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message