On 30.11.14 07:40, Amos Jeffries wrote:
Just to followup, there will not be a permanent change made to Squid
because:
That's fair enough - my initial diagnosis was basically "the server's
broken", but I thought it was worth having a debate about the merits of
modifying the contents of a bump
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/11/2014 11:51 p.m., Steve Hill wrote:
> On 17/11/14 22:05, Amos Jeffries wrote:
>
>> Would you mind running an experiment for me?
>>
>> To see what happens if Squid delivers either of these Via
>> headers instead of its current output:
>>
>> V
On 17/11/14 22:05, Amos Jeffries wrote:
> Would you mind running an experiment for me?
>
> To see what happens if Squid delivers either of these Via headers
> instead of its current output:
>
> Via: HTTPS/1.1 iceni2.opendium.net (squid/3.4.9)
The HTTPS/1.1 one appears to work correctly.
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/11/2014 11:25 p.m., Steve Hill wrote:
> On 04/11/14 13:59, Amos Jeffries wrote:
>
>>> I've just come across a web server that throws its toys out of
>>> the pram when it sees a Via header in an HTTPS request, and
>>> unfortunately it's quite a
On 04/11/14 13:59, Amos Jeffries wrote:
>> I've just come across a web server that throws its toys out of the
>> pram when it sees a Via header in an HTTPS request, and
>> unfortunately it's quite a big one - Yahoo. See this request:
>
>> - GET /news/degrees-lead-best-paid-careers-141513989.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/11/2014 11:17 p.m., Steve Hill wrote:
>
> Squid (correctly) inserts Via and X-Forwarded-For headers into
> requests that it is proxying. However, in the case of encrypted
> traffic, the server and client are expecting the traffic to reach
> the
Squid (correctly) inserts Via and X-Forwarded-For headers into requests
that it is proxying. However, in the case of encrypted traffic, the
server and client are expecting the traffic to reach the other end
as-is, since usually this could not be intercepted. With SSL bumped
requests this is no l
