Re: [PATCH] Bug 2680: ** helper errors after -k rotate
tor 2009-07-16 klockan 11:13 +1000 skrev Robert Collins: Note that with NTLM this is realistic - there's no need for multiple helpers as a single helper can serve many concurrent requests. No longer the case as we no longer do challenge reuses and the concurrent protocol is not implemented for stateful helpers, but for basic, digest and url rewriters it is.. Regards Henrik
Re: [PATCH] Bug 2680: ** helper errors after -k rotate
tor 2009-07-16 klockan 14:47 +1200 skrev Amos Jeffries: And the sad reality in squid-3 with _one_ helper: squid-*--1-helper---* winbindd [state1, state2] \---crash: all 2 of 1 helpers all RS pending state. You can't run NTLM with just one helper, not until both the following are true: 1. We implement the current request protocol for stateful helpers 2. Samba implements the same in ntlm_auth (iirc this has been done in Samab4) The reason to this is because the challenge is unique for each client (required by NTLMv2) and the default NTLM helper protocol only supports one challenge at a time. But Squid should not crash horribly only because you do, only complain about helper queue overload... Regards Henrik
Re: [PATCH] Bug 2680: ** helper errors after -k rotate
On Thu, 2009-07-16 at 08:42 +0200, Henrik Nordstrom wrote: tor 2009-07-16 klockan 14:47 +1200 skrev Amos Jeffries: And the sad reality in squid-3 with _one_ helper: squid-*--1-helper---* winbindd [state1, state2] \---crash: all 2 of 1 helpers all RS pending state. You can't run NTLM with just one helper, not until both the following are true: 1. We implement the current request protocol for stateful helpers I thought we put a unique id on the stateful helper protocol _way_ back. Sigh :( 2. Samba implements the same in ntlm_auth (iirc this has been done in Samab4) We'd need to ask, I can do that if we think it hasn't been done. As samba supplies the auth helpers there shouldn't be a compatibility issue in changing it. -Rob signature.asc Description: This is a digitally signed message part
Re: [PATCH] Bug 2680: ** helper errors after -k rotate
tor 2009-07-16 klockan 16:54 +1000 skrev Robert Collins: I thought we put a unique id on the stateful helper protocol _way_ back. Sigh :( No, I couldn't when I implemented the concurent request protocol so it only got done for stateless helpers. iirc I got stuck in trying to unwind some of the dependencies in the reservation code used by the challenge reuse layer (which is thrown out these days..). Regards Henrik
Re: Hello from Mozilla
ons 2009-07-15 klockan 04:26 + skrev Ian Hickson: On Tue, 14 Jul 2009, Alex Rousskov wrote: WebSocket made the handshake bytes look like something Squid thinks it understands. That is the whole point of the argument. You are sending an HTTP-looking message that is not really an HTTP message. I think this is a recipe for trouble, even though it might solve some problem in some environments. Could you elaborate on what bytes Squid thinks it should change in the WebSocket handshake? As already mentioned HTTP specs says it MUST add a Via header element. Regards Henrik
Re: Hello from Mozilla
ons 2009-07-15 klockan 07:34 + skrev Ian Hickson: On Wed, 15 Jul 2009, Mark Nottingham wrote: Upgrade is hop-by-hop, so it's pretty limiting. Do man-in-the-middle proxies count as a hop for the purposes of HTTP? When used as a surrogate it does. The transparently interceping case is outside of any specifications. As far as I can tell from the HTTP spec, the client is supposed to know whether it is speaking to a proxy or not, so man-in-the-middle proxies don't affect the hop-by-hop semantics... but it's not entirely clear. Yes, just as IP addresses are supposed to be unique and not shared or modified in transit (NAT)... Sure, but that's why we have the TLS-over-port-443 option. In the cases where there is uncooperative network infrastructure, the client can just switch to that, and then there's no way the connection can be affected. You think There is a funny technique implemented at many places today which unwinds TLS on port 443 and proxies the HTTP traffic which is supposed to be within. Used for policy enforcement and inspection in networks where end-to-end encrypted communication is forbidden by policy. Not doing so is unacceptably insecure for this use case, IMHO. We can't run the risk of Web pages hitting SMTP servers and sending spam, or poking at intranet servers, or who knows what else. You still haven¨t explained how running a proper HTTP Upgrade sequence may risk this. I just don't see it. Regards Henrik
Re: Hello from Mozilla
tor 2009-07-16 klockan 01:44 + skrev Ian Hickson: So Squid when used as a man-in-the-middle proxy will allow arbitrary traffic through port 80 if it isn't HTTP traffic? No, but support for tunneling WebSockets can be added, but not when it looks and feels like a HTTP message. This advice contradicts other advice we've gotten to the effect that if we send any content over port 80, it absolutely must be HTTP-compatible. And what we are saying is that if you make something that looks like HTTP and runs on port 80 it should be HTTP, not just something that looks like HTTP but isn't compatible with HTTP and which will break if processed as if it was HTTP. The point Amos tried to make is that if it isn't HTTP (just resembles HTTP but isn't compatible with HTTP) then it should not look like HTTP. For us as a proxy it's easier to deal with something that is easily identified as not-HTTP and switch stack entirely than to try to tweak the HTTP processing to not break looks-like-HTTP-but-isn't-HTTP applications. Could you elaborate on this? Why would a transparent proxy meddle with bytes after it has seen a successful Upgrade? Doesn't this contradict the requirements on transparent proxies in the HTTP spec? It won't. But it will touch the HTTP upgrade request, and possibly even the 101 response status description. If it at all supports Upgrade, but that is a different topic. For all intents and purposes, it _is_ an HTTP request. It's an Upgrade request. It seems that man-in-the-middle proxies would break all Upgrades, the way you've described them. The only part of your spec we talk about here is the binary coded looks-like-HTTP-Upgrade sequence. What happens after the looks-like-HTTP-101-response we don't care about. Right down to the HTTP/1.1 reserved protocol label (do get that changed please). If we're faking HTTP, then it has to look like HTTP. And our point is DO NOT FAKE HTTP. Use HTTP. To make the point explicit we already see one wire protocol (icecast, used by shoutcast streaming) which uses a similar fake HTTP mechanism like you. In this protocol the clients sends a quite well formed HTTP request, but the response is in a slightly different protocol. When this gets processed by an HTTP intermediary (proxy or frontend) things do break in subtle way because the application isn't expecting the transforms required by HTTP. For a long time noone noticed as Squid did not conform to a specific part the HTTP specifications, but when Squid was modified to follow HTTP specifications this application broke. I'm getting very mixed messages here. Is there a reliable way to open a bidirectional non-HTTP TCP/IP connection through a Squid man-in-the-middle proxy over port 80 to a remote server that normally acts like an HTTP server? If so, what is the sequence of bytes that will act in this way? Both yes and no. There is experimental support available for transparent interception operation to switch to tunnel mode when seeing non-HTTP traffic, but this is not yet part of the official distribution (needs a bit more work first). The use case for this is environments using transparent interception for caching reasons but which accepts that there may be non-HTTP applications also using port 80. At some point we will also support switching to tunnel mode after seeing a successful HTTP Upgrade sequence but we are not quite there yet. This discussion is to make sure WebSockets do not break when processed via a future Squid which do support HTTP Upgrade. The use case for this is both transparently interception in the client network and frontend intermediary setups in the web server network. In a normal forward proxy environment the supported method is CONNECT, but default policy (configuration) restricts this to port 443 and a few other well-known SSL ports blocking port 80. Related note to others following this discussion: Upgrade is hop-by-hop not end-to-end. Regards Henrik
Re: Hello from Mozilla
ons 2009-07-15 klockan 07:18 + skrev Ian Hickson: The reason we have a very strict handshake is because we don't want it to be possible to trick a non-WebSocket-aware server into accepting a connection (or similarly, having the client be tricked by the script into accepting a connection to a non-WebSocket-aware server). This is especially important for WebSockets because once there's a connection established, any data might be sent. Doesn't need to be octet-level strict for that. If you get a 101 response you know it's been accepted. If you get anything else you need to deal with that, as required by HTTP. Until the end of the 101 response it's all HTTP, per the rules of HTTP. HTTP is getting similar restrictions, by the way, in the form of the CORS mechanism. Without CORS, scripts can't ever read data back from cross-site HTTP requests they initiate. CORS allows the server to opt in to sending data back to a third-party script. Which is fine, as the HTTP part of CORS is a simple HTTP extension within the framework defined by HTTP. And I wouldn't call it that HTTP gets restrictions. In the case of CORS HTTP is extended to give client scripts authorization to access the servers data where such scripts before could not due to access restrictions implemented in the user-agent. For others following this thread: http://www.w3.org/TR/access-control/ http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ Regards Henrik
Re: Hello from Mozilla
ons 2009-07-15 klockan 18:39 +1200 skrev Amos Jeffries: Byte 5 through to the first of: two CRLF or one NULL byte. Specified as step 1 through 11 by the looks of it. Correctly operating: * MUST remove the Upgrade: WebSocket\r\n bytes. Yes/No depending on the context. If a normal forward proxy sees such request then yes, but that's outside WebSocket specification as CONNECT is used in such case. In a surrogate intermediary situation it's essentially up to us how we deal with the upgrade. The operations of surrogate-origin is outside of HTTP specifications. Specifications only cover client-surrogate in such setups. In a transparent intercepting proxy it's our responsibility to deal with the Upgrade as appropriate. i.e. switch to tunnel mode, or declare it not supported by removing the header. Transparent interception mode is outside of HTTP specifications. * MUST add Via: 1.1 followed by an arbitrary length and content string. Yes. * SHOULD add a Date: header (position optional, suggested to be between GET and Host:). No. The Date requirement is only on responses, not requests. Conditionally: * Depending on the local network topology _sometimes_ proxies required to alter the section labeled the path in order for the request to even happen. Changing it from ( / path ) to ( http://; hostname / path ) Yes, but it will get changed back to the simple /path form before the requests hits an actual origin server. ** The http://hostname part MAY be removed again before passing to Server. Usually not. It MUST be removed per HTTP specifications (but servers MUST accept it if sent). Future HTTP specifications MAY be relaxed to allow absolute-URI form to be sent in requests as well but that's future when HTTP/1.0 servers is confirmed gone from the globe. To raise the extreme end of the problem: In HTTP a proxy MAY go so far as to sort the headers alphabetically and expect things to still work well. Yes. The solutions you need to be looking at are: * using HTTP Upgrade as per the HTTP spec, with full flexibility. * using ports other than 80. * sending requests as pure binary and dropping the HTTP look-alike bits Yes. Regards Henrik
[PATCH] Bug 2680: ** helper errors after -k rotate
Amos Jeffries wrote:
Robert Collins wrote:
On Wed, 2009-07-15 at 00:52 +0200, Henrik Nordstrom wrote:
Or 4, go back to don't strictly enforce the number of helpers?
+1
I don't know what this strictly-enforce thing is, but it sounds unneeded
as we used to fire up the right number of helpers anyway.
I stopped Squid saying:
running: 200 of 100 XXX helpers
A Henrik said,
people with large memory-hog helpers have issues when Squid allocates
more than N bunches of their carefully tuned available memory to its
helpers. This is also important in low-memory systems requiring auth.
It's a simple 'start N' call now checks the number of running helpers
before blindly starting new ones. Making Squid actually follow its
numerous children=N settings.
I'm fine with reverting it in 3.1. But this is a nasty mix of sync and
async operations that does need cleaning up in 3.2. It's semi-hiding
about 4 bugs in a helpers and auth.
Right, following up on that I had a hunch and discovered that n_active
is already performing this duty. The bug is therefore in my earlier fix
using n_running as a base instead of n_active.
How does this new attached patch look to you two?
It performs the calculation re-base and documents the relevant counters.
Amos
=== modified file 'src/helper.cc'
--- src/helper.cc 2009-06-14 12:35:17 +
+++ src/helper.cc 2009-07-16 10:53:22 +
@@ -103,7 +103,7 @@
shortname = xstrdup(progname);
/* dont ever start more than hlp-n_to_start processes. */
-int need_new = hlp-n_to_start - hlp-n_running;
+int need_new = hlp-n_to_start - hlp-n_active;
debugs(84, 1, helperOpenServers: Starting need_new / hlp-n_to_start ' shortname ' processes);
@@ -209,7 +209,8 @@
shortname = xstrdup(progname);
/* dont ever start more than hlp-n_to_start processes. */
-int need_new = hlp-n_to_start - hlp-n_running;
+/* n_active are the helpers which have not been shut down. */
+int need_new = hlp-n_to_start - hlp-n_active;
debugs(84, 1, helperOpenServers: Starting need_new / hlp-n_to_start ' shortname ' processes);
@@ -545,8 +546,8 @@
storeAppendPrintf(sentry, program: %s\n,
hlp-cmdline-key);
-storeAppendPrintf(sentry, number running: %d of %d\n,
- hlp-n_running, hlp-n_to_start);
+storeAppendPrintf(sentry, number active: %d of %d (%d shutting down)\n,
+ hlp-n_active, hlp-n_to_start, (hlp-n_running - hlp-n_active) );
storeAppendPrintf(sentry, requests sent: %d\n,
hlp-stats.requests);
storeAppendPrintf(sentry, replies received: %d\n,
@@ -587,7 +588,7 @@
storeAppendPrintf(sentry,B = BUSY\n);
storeAppendPrintf(sentry,W = WRITING\n);
storeAppendPrintf(sentry,C = CLOSING\n);
-storeAppendPrintf(sentry,S = SHUTDOWN\n);
+storeAppendPrintf(sentry,S = SHUTDOWN PENDING\n);
}
void
@@ -598,8 +599,8 @@
storeAppendPrintf(sentry, program: %s\n,
hlp-cmdline-key);
-storeAppendPrintf(sentry, number running: %d of %d\n,
- hlp-n_running, hlp-n_to_start);
+storeAppendPrintf(sentry, number active: %d of %d (%d shutting down)\n,
+ hlp-n_active, hlp-n_to_start, (hlp-n_running - hlp-n_active) );
storeAppendPrintf(sentry, requests sent: %d\n,
hlp-stats.requests);
storeAppendPrintf(sentry, replies received: %d\n,
@@ -644,7 +645,7 @@
storeAppendPrintf(sentry,B = BUSY\n);
storeAppendPrintf(sentry,C = CLOSING\n);
storeAppendPrintf(sentry,R = RESERVED or DEFERRED\n);
-storeAppendPrintf(sentry,S = SHUTDOWN\n);
+storeAppendPrintf(sentry,S = SHUTDOWN PENDING\n);
storeAppendPrintf(sentry,P = PLACEHOLDER\n);
}
@@ -671,7 +672,6 @@
hlp-n_active--;
assert(hlp-n_active = 0);
-
srv-flags.shutdown = 1; /* request it to shut itself down */
if (srv-flags.closing) {
=== modified file 'src/helper.h'
--- src/helper.h 2009-04-07 13:16:59 +
+++ src/helper.h 2009-07-16 10:51:42 +
@@ -58,9 +58,9 @@
dlink_list servers;
dlink_list queue;
const char *id_name;
-int n_to_start;
-int n_running;
-int n_active;
+int n_to_start; /// Configuration setting of how many helper children should be running
+int n_running;/// Total helper children objects currently existing
+int n_active; /// Count of helper children active (not shutting down)
int ipc_type;
IpAddress addr;
unsigned int concurrency;
@@ -80,9 +80,9 @@
dlink_list servers;
dlink_list queue;
const char *id_name;
-int n_to_start;
-int n_running;
-int n_active;
+int n_to_start; /// Configuration setting of how many helper children should be running
+int n_running;/// Total helper children objects currently
Re: Hello from Mozilla
tor 2009-07-16 klockan 23:11 +1200 skrev Amos Jeffries: The faux-request begins with: GET /path-bytes HTTP/1.1 It also contains Connection: Upgrade. Only when not talking to a proxy. If a proxy is configured CONNECT is used for setting up a tunnel first. See 3.1 Handshake, step 3. For peers we already have the tricky case where admin may not set 'originserver' on web server links to trigger the un-map. Apache et al are compliant enough for this not to break the HTTP, but will completely break the WebSocket faux-HTTP byte-wise spec. True, but my point is that such setups is NOT HTTP/1.1 compliant. In HTTP/1.1 requests to origin server MUST be sent without the scheme://[u...@]host:port part, and servers MUST accept both forms. Regards Henrik
Re: disable-loadable-modules
Alex Rousskov wrote:
On 07/09/2009 01:40 AM, Amos Jeffries wrote:
Amos Jeffries wrote:
Well, I've found a possible reason to disable them by default.
The Debian Lenny/Ubuntu Jaunty libtool 2.2 appears broken with its
handling of the libtool convenience library. Giving build failures
unless they are configured to off.
Since I made the change to testbed distcheck I've been fighting with
them. Something inside distcheck seems to be running configure with
the defaults regardless of what the master test is run with. Probably
the dist configure --silent packaging or a sub-test of the package
it makes.
If anyone is able to help I'd be very grateful. If we can't find a
solution to that one I think we are going to have to disable loadable
modules unless adaptation needs them.
Amos
Confirmed:
c_install_base=`CDPATH=${ZSH_VERSION+.}: cd squid-3.HEAD-BZR/_inst
pwd | sed -e 's,^[^:\\/]:[\\/],/,'` \
dc_destdir=${TMPDIR-/tmp}/am-dc-$$/ \
cd squid-3.HEAD-BZR/_build \
../configure --srcdir=.. --prefix=$dc_install_base \
\
make \
make dvi \
make check \
make install \
make installcheck \
make uninstall \
...
make dist \
rm -rf squid-3.HEAD-BZR.tar.gz squid-3.HEAD-BZR.tar.bz2 \
make distcleancheck
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
...
checking whether to use loadable modules... yes, implicitly
Will setting DISTCHECK_CONFIGURE_FLAGS in top Makefile.am help with this?
Alex.
That worked for the distcheck breakage.
Now only to fix the libtool bug that brought it to attention.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
Current Beta Squid 3.1.0.9
Re: [PATCH] Bug 2680: ** helper errors after -k rotate
tor 2009-07-16 klockan 23:15 +1200 skrev Amos Jeffries: Right, following up on that I had a hunch and discovered that n_active is already performing this duty. The bug is therefore in my earlier fix using n_running as a base instead of n_active. How does this new attached patch look to you two? Looks fine to me, assuming rotate still starts a new set of helpers (wasn't clear to me). Will fix the too many helpers have crashed, need to start new ones case, and leave the rotate reconfigure case alone. With this we can also start new helpers more or less immediately (at some seconds delay just in case) when seeing them crash... Regards Henrik
Re: [PATCH] Bug 2680: ** helper errors after -k rotate
On Thu, 2009-07-16 at 09:11 +0200, Henrik Nordstrom wrote: tor 2009-07-16 klockan 16:54 +1000 skrev Robert Collins: I thought we put a unique id on the stateful helper protocol _way_ back. Sigh :( No, I couldn't when I implemented the concurent request protocol so it only got done for stateless helpers. iirc I got stuck in trying to unwind some of the dependencies in the reservation code used by the challenge reuse layer (which is thrown out these days..). Well thats hopeful, sounds like it would be easier now :) That reuse stuff was such a hack. -Rob signature.asc Description: This is a digitally signed message part
Re: Hello from Mozilla
Realise that server-side infrastructure often includes things like CDNs (even when the content is uncacheable), reverse proxies and L7 load balancers -- all of which can make the changes we're talking about. While it's true that these things are under control of the people who own the server, changing them is *much* harder than deploying an Apache module. Cheers, On 17/07/2009, at 9:53 AM, Ian Hickson wrote: The point is, there may be a whole lot of stuff going on with HTTP implementations that you're not aware of. Sure, but with the except of man-in-the-middle proxies, this isn't a big deal -- the people implementing the server side are in control of what the HTTP implementation is doing. -- Mark Nottingham m...@yahoo-inc.com
Re: Hello from Mozilla
Yep. Just think it's worth pointing out in the draft, since you go to such efforts to make this possible. Cheers, On 17/07/2009, at 10:28 AM, Ian Hickson wrote: On Fri, 17 Jul 2009, Mark Nottingham wrote: Realise that server-side infrastructure often includes things like CDNs (even when the content is uncacheable), reverse proxies and L7 load balancers -- all of which can make the changes we're talking about. While it's true that these things are under control of the people who own the server, changing them is *much* harder than deploying an Apache module. People with that level of complexity can easily just not share the port. -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.' -- Mark Nottingham m...@yahoo-inc.com
Re: [PATCH] Bug 2680: ** helper errors after -k rotate
Henrik Nordstrom wrote: tor 2009-07-16 klockan 23:15 +1200 skrev Amos Jeffries: Right, following up on that I had a hunch and discovered that n_active is already performing this duty. The bug is therefore in my earlier fix using n_running as a base instead of n_active. How does this new attached patch look to you two? Looks fine to me, assuming rotate still starts a new set of helpers (wasn't clear to me). Yes, no longer touching mainRotate() at all with these. Will fix the too many helpers have crashed, need to start new ones case, and leave the rotate reconfigure case alone. With this we can also start new helpers more or less immediately (at some seconds delay just in case) when seeing them crash... Ah, good point. :) Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16 Current Beta Squid 3.1.0.9
Re: Hello from Mozilla
On Fri, 17 Jul 2009, Mark Nottingham wrote: On 17/07/2009, at 10:28 AM, Ian Hickson wrote: On Fri, 17 Jul 2009, Mark Nottingham wrote: Realise that server-side infrastructure often includes things like CDNs (even when the content is uncacheable), reverse proxies and L7 load balancers -- all of which can make the changes we're talking about. While it's true that these things are under control of the people who own the server, changing them is *much* harder than deploying an Apache module. People with that level of complexity can easily just not share the port. Yep. Just think it's worth pointing out in the draft, since you go to such efforts to make this possible. Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Hello from Mozilla
2009/7/17 Ian Hickson i...@hixie.ch: That way you are still speaking HTTP right until the protocol change occurs, so any and all HTTP compatible changes in the path(s) will occur. As mentioned earlier, we need the handshake to be very precisely defined because otherwise people could trick unsuspecting servers into opting in, or rather appearing to opt in, and could then send all kinds of commands down to those servers. Would you please provide an example of where an unsuspecting server is tricked into doing something? Ian, don't you see and understand the semantic difference between speaking HTTP and speaking a magic bytecode that is intended to look HTTP-enough to fool a bunch of things until the upgrade process occurs ? Don't you understand that the possible set of things that can go wrong here is quite unbounded ? Don't you understand the whole reason for known ports and protocol descriptions in the first place? Apparently not. Ok. Look at this. The byte sequence GET / HTTP/1.0\r\nHost: foo\r\nConnection: close\r\n\r\n is not byte equivalent to the sequence GET / HTTP/1.0\r\nConnection: close\r\nHost: foo\r\n\r\n The same byte sequence interpreted as a HTTP protocol exchange is equivalent. There's a mostly-expected understanding that what happens over port 80 is HTTP. The few cases where that has broken (specifically Shoutcast, but I do see other crap on port 80 from time to time..) has been by people who have implemented a mostly HTTP looking protocol, tested that it mostly works via a few gateways/firewalls/proxies, and then deployed it. My suggestion is to completely toss the whole pretend to be HTTP thing out of the window and look at extending or adding a new HTTP mechanism for negotiating proper tunneling on port 80. If this involves making CONNECT work on port 80 then so be it. Redesigning HTTP is really much more work than I intend to take on here. HTTP already has an Upgrade mechanism, reusing it seems the right thing to do. What you intend to take on here and what should be taken on here is very relevant. You're intending to do stuff over tcp/80 which looks like HTTP but isn't HTTP. Everyone who implements anything HTTP gateway related (be it a transparent proxy, a firewall, a HTTP router, etc) suddenly may have to implement your websockets stuff as well. So all of a sudden your attempt to not extend HTTP ends up extending HTTP. The point is, there may be a whole lot of stuff going on with HTTP implementations that you're not aware of. Sure, but with the except of man-in-the-middle proxies, this isn't a big deal -- the people implementing the server side are in control of what the HTTP implementation is doing. That may be your understanding of how the world works, but out here in the rest of the world, the people who deploy the edge and the people who deploy the core may not be the same people. There may be a dozen layers of red tape, equipment lifecycle, security features, etc, that need to be handled before websockets happy stuff can be deployed everywhere it needs to. Please don't discount man-in-the-middle -anything- as being easy to deal with. In all cases except a man-in-the-middle proxy, this seems to be what we do. I'm not sure how we can do anything in the case of such a proxy, since by definition the client doesn't know it is present. .. so you're still not speaking HTTP? Ian, are you absolutely certain that everywhere you use the internet, there is no man in the middle between you and the server you're speaking to? Haven't you ever worked at any form of corporate or enterprise environment? What about existing captive portal deployments like wifi hotspots, some of which still use squid-2.5 (eww!) as their http firewall/proxy to control access to the internet? That stuff is going to need upgrading sure, but I'd rather see the upgrade happen once to a well thought out and reasonably well designed protocol, versus having lots of little upgrades need to occur because your HTTP but not quite HTTP exchange on port 80 isn't thought out enough. Adrian
