-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/09/2014 2:48 a.m., Amos Jeffries wrote:
> On 19/08/2014 10:12 p.m., Amos Jeffries wrote:
>> Updated patch. I believe this covers everything so far,
>> including the 16-bit alignment and segmented TCP packet issues.
>
>> Amos
>
>
> If there are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/08/2014 10:12 p.m., Amos Jeffries wrote:
> Updated patch. I believe this covers everything so far, including
> the 16-bit alignment and segmented TCP packet issues.
>
> Amos
>
If there are no objections I will apply this soon.
Amos
-BEGI
Updated patch. I believe this covers everything so far, including the
16-bit alignment and segmented TCP packet issues.
Amos
=== modified file 'doc/release-notes/release-3.5.sgml'
--- doc/release-notes/release-3.5.sgml 2014-08-11 16:09:06 +
+++ doc/release-notes/release-3.5.sgml 2014-08-12
On 08/12/2014 06:18 PM, Alex Rousskov wrote:
> On 08/12/2014 10:17 AM, Amos Jeffries wrote:
>> On 11/08/2014 4:32 p.m., Alex Rousskov wrote:
>>> On 08/05/2014 08:31 PM, Amos Jeffries wrote:
+const char *clen = in.buf.rawContent() + Proxy2p0magic.length() + 2;
+const uint16_t len =
On 08/12/2014 10:17 AM, Amos Jeffries wrote:
> On 11/08/2014 4:32 p.m., Alex Rousskov wrote:
>> On 08/05/2014 08:31 PM, Amos Jeffries wrote:
>>> +tok.skip(Proxy1p0magic);
>>
>> We already know the magic is there. If you want to optimize this, then
>> skip() in ConnStateData::parseProxyProtocolH
On 11/08/2014 4:32 p.m., Alex Rousskov wrote:
> On 08/05/2014 08:31 PM, Amos Jeffries wrote:
>
>> I am adding proxy_protocol_access as the first access control, reverting
>> follow_x_forwarded_for for the second.
>
> Great. I think this is a much simpler/cleaner design.
>
>
>> +} else if (
On 08/05/2014 08:31 PM, Amos Jeffries wrote:
> I am adding proxy_protocol_access as the first access control, reverting
> follow_x_forwarded_for for the second.
Great. I think this is a much simpler/cleaner design.
> +} else if (strcmp(token, "require-proxy-header") == 0) {
> +s->f
On 5/08/2014 2:47 a.m., Alex Rousskov wrote:
> On 07/30/2014 09:02 AM, Amos Jeffries wrote:
>
>> +NAME: proxy_forwarded_access follow_x_forwarded_for
>
>> Requests may pass through a chain of several other proxies
>> +before reaching us. The original source details may by sent in:
>> +
On 07/30/2014 09:02 AM, Amos Jeffries wrote:
> +NAME: proxy_forwarded_access follow_x_forwarded_for
> Requests may pass through a chain of several other proxies
> + before reaching us. The original source details may by sent in:
> + * HTTP message Forwarded header, or
> +
On 27/07/2014 6:18 a.m., Alex Rousskov wrote:
> On 07/25/2014 08:27 PM, Amos Jeffries wrote:
>
>> +// detect and parse PROXY protocol version 1 header
>> +if (in.buf.length() > Proxy10magic.length() &&
>> in.buf.startsWith(Proxy10magic)) {
>> + return parseProxy10();
>> +
>> +
On 07/25/2014 08:27 PM, Amos Jeffries wrote:
> +// detect and parse PROXY protocol version 1 header
> +if (in.buf.length() > Proxy10magic.length() &&
> in.buf.startsWith(Proxy10magic)) {
> + return parseProxy10();
> +
> +// detect and parse PROXY protocol version 2 header
On 22/06/2014 5:15 p.m., Amos Jeffries wrote:
> Support receiving PROXY protocol version 1 and 2.
>
> PROXY protocol has been developed by Willy Tarreau of HAProxy for
> communicating original src and dst IP:port details between proxies and
> load balancers in a protocol-agnostic way.
>
> stunnel
On 15/07/2014 4:25 a.m., Alex Rousskov wrote:
> On 07/12/2014 10:45 PM, Amos Jeffries wrote:
>
>> +bool
>> +ConnStateData::findProxyProtocolMagic()
>> +{
>> +// http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
>> +
>> +// detect and parse PROXY protocol version 1 header
>> +i
On 07/12/2014 10:45 PM, Amos Jeffries wrote:
> +bool
> +ConnStateData::findProxyProtocolMagic()
> +{
> +// http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
> +
> +// detect and parse PROXY protocol version 1 header
> +if (in.buf.length() > Proxy10magic.length() &&
> in.buf.s
On 07/13/2014 02:38 PM, Kinkie wrote:
>> In all seriousness "haproxy-protocol" is probably the most correct
>> descriptive right now. But I am trying hard to avoid naming a competitor
>> in our most visible documentations.
>
> How so? We are not a commercial product; I have no issues with naming
>
> In all seriousness "haproxy-protocol" is probably the most correct
> descriptive right now. But I am trying hard to avoid naming a competitor
> in our most visible documentations.
How so? We are not a commercial product; I have no issues with naming
a competitor.
Attaced patch contains all updated except the config option renaming,
which remains to be sorted out.
On 26/06/2014 7:41 a.m., Alex Rousskov wrote:
> On 06/21/2014 11:15 PM, Amos Jeffries wrote:
>> Support receiving PROXY protocol version 1 and 2.
>
>
>> + proxy-surrogate
>> +
On 12/07/2014 3:04 a.m., Alex Rousskov wrote:
> On 07/11/2014 02:27 AM, Amos Jeffries wrote:
>> - supports non-TCP protocols.
>> - security section says it could be full of lies. So the A[ctually] is
>> incorrect.
>
> IMHO, you are being too literate with the words in the protocol name
> while
On 07/11/2014 02:27 AM, Amos Jeffries wrote:
> - supports non-TCP protocols.
> - security section says it could be full of lies. So the A[ctually] is
> incorrect.
IMHO, you are being too literate with the words in the protocol name
while being very permissive with the protocol specs. Most of th
> I was thinking you had something funny along the lines of:
>
> * Traffic Envelope Annex protocol (TEA p'ot)
>
> We could also reply with HTTP 418 and close the connection on protocol
> failures.
iLike.
Willy, what do you think?
Kinkie
cc'ing Willy so he can get in on this.
On 11/07/2014 5:03 p.m., Alex Rousskov wrote:
> On 06/25/2014 01:41 PM, Alex Rousskov wrote:
>> On 06/21/2014 11:15 PM, Amos Jeffries wrote:
Support receiving PROXY protocol version 1 and 2.
>
>> sounds like nothing-on-top-of-nothing to me in Squid cont
On 06/25/2014 01:41 PM, Alex Rousskov wrote:
> On 06/21/2014 11:15 PM, Amos Jeffries wrote:
>> > Support receiving PROXY protocol version 1 and 2.
> sounds like nothing-on-top-of-nothing to me in Squid context? The
> terrible name for the PROXY protocol itself is clearly not your fault
Per Amos
On 26/06/2014 4:53 a.m., Eliezer Croitoru wrote:
> I was not expecting this patch due to old emails about the proxy
> protocol implementation.
> I understand from the email that after this patch we can use STUNNEL and
> HAPROXY in-front of squid. right?
Right. stunnel, HAProxy and any other gatewa
On 06/21/2014 11:15 PM, Amos Jeffries wrote:
> Support receiving PROXY protocol version 1 and 2.
> +proxy-surrogate
> + Support for PROXY protocol version 1 or 2 connections.
> + The proxy_forwarded_access is required to whitelist
> +
I was not expecting this patch due to old emails about the proxy
protocol implementation.
I understand from the email that after this patch we can use STUNNEL and
HAPROXY in-front of squid. right?
+1 (for the idea and looked a bit at the code itself)
Eliezer
On 06/22/2014 08:15 AM, Amos Jeffri
Support receiving PROXY protocol version 1 and 2.
PROXY protocol has been developed by Willy Tarreau of HAProxy for
communicating original src and dst IP:port details between proxies and
load balancers in a protocol-agnostic way.
stunnel, HAProxy and some other HTTP proxying software are already
26 matches
Mail list logo
