CSCG / shellinabox

Automatically exported from code.google.com/p/shellinabox
Other
0 stars 0 forks source link

Fails with certain combinations of proxies/firewalls and browsers. #8

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Fails with IE6 but not Firefox
2. Fails through the proxy but not direct
3. Only combination of proxy and IE6 fails...

What is the expected output? What do you see instead?

Hangs for a long time waiting with progress bar as if network slow

What version of the product are you using? On what operating system?

SVN tip

Please provide any additional information below.

Hmmm... It fails only IE6 though the corporate proxy direct to
shellinaboxd.  If I use Firefox, it works.  If I put the machine on my lan
and don't go through the corporate proxy, it works.  If I put Apache
mod-proxy in front of shellinabox, it works.  SO:

Firefox=>Corp proxy=>SIB works
IE=>Corp proxy=>my Apache proxy=>SIB works
IE=>SIB works
IE=>Corp proxy=>SIB hangs fails locks.

From looking at the cookies, I think the proxy is make by BCSI "Blue Coat
Systems Incorporated" http://www.bluecoat.com.

This cannot be a POST caching issue, it has to be a connection open close
kind of thing, the proxy doesn't know beans about posts within an HTTPS
session.  It just knows CONNECT etc., I think?  Certainly the outbound
corporate proxy can't look into HTTPS and even SEE the POST...

Weird that it is only the one combination, and that there is a way to
change either side to make it work.

Note, in the test where I put the machine directly on the LAN and went
direct IE=>SIB, I confirmed that there are not IE6 issues per-se without
the proxy in between.

Any ideas?  If it really is some HTTPS connection kind of issue, it is more
likely to be fixable on the server side (making the server do differently
whatever Apache does in its HTTPS handling when I put mod-proxy on the
server side) than in the client side (making IE do whatever Firefox does
that works) as probably JS/client can't control IEs behaviour there- but
certainly the server has control and could change it's behaviour.

Should I do something like a wireshark dump of the server side in both cases?

Original issue reported on code.google.com by TomOeh...@gmail.com on 21 Mar 2009 at 4:59

GoogleCodeExporter commented 9 years ago
This looks like a genuine IE6 bug. Implemented a work-around in SVN. 
Unfortunately, 
this entails a noticeable performance penalty for IE6 users, when connecting 
through SSL. We have to close the TCP connection after each transaction.

Original comment by zod...@gmail.com on 21 Mar 2009 at 7:10

GoogleCodeExporter commented 9 years ago
Confirmed fixed. What was IE doing? Do you understand why it wouldn't happen 
unless
though the outbound corporate proxy, but also wouldn't happen if additionally 
through
the inbound Apache mod_proxy?  Anyway, fixed and working!

Original comment by TomOeh...@gmail.com on 21 Mar 2009 at 8:36