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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo
