[squid-dev] [PATCH] Temporary fix to restore compatibility with Amazon

[Marcus Kool]

On 06/24/2015 05:24 PM, Kinkie wrote:
> My 2c: I vote for reality; possibly with a shaming announce message; I
> wouldn't even recommend logging the violation: there is nothing the
> average admin can do about it. I would consider adding a shaming
> comment in the release notes.

more cents:

correct.

A standard can be considered a strong guideline but if important sites
violate the standard (i.e. users/admins complain) then Squid
should be able to cope with it or it risks getting abandoned because
Squid cannot cope with traffic of sites that otherwise work without Squid.

For an admin it is irrelevant if the problem is caused by Squid or by
a website.  And the admin who dares to say to its users "only visit
sites that comply with the standards" probably gets fired.


> On Wed, Jun 24, 2015 at 10:12 PM, Alex Rousskov
> <rousskov at measurement-factory.com> wrote:
>> On 06/24/2015 05:26 AM, Amos Jeffries wrote:
>>
>>> On 24/06/2015 5:55 p.m., Alex Rousskov wrote:
>>>>      This temporary trunk fix adds support for request URIs containing
>>>> '|' characters. Such URIs are used by popular Amazon product (and
>>>> probably other) sites: /images/I/ID1._RC|ID2.js,ID3.js,ID4.js_.js
>>>>
>>>> Without this fix, all requests for affected URIs timeout while Squid
>>>> waits for the end of request headers it has already received(*).
>>
>>
>>> This is not right. Squid should be identifying the message as
>>> non-HTTP/1.x (which it isn't due to the URI syntax violation) and
>>> treating it as such.
>>
>> I agree that Amazon violates URI syntax. On the other hand, the message
>> can be interpreted as HTTP/1.x for all practical purposes AFAICT. If you
>> want to implement a different fix, please do so. Meanwhile, folks
>> suffering from this serious regression can try the temporary fix I posted.
>>
>>
>>>> The proper long-term fix is to allow any character in URI as long as we
>>>> can reliably parse the request line (and, later, URI components). There
>>>> is no point in hurting users by rejecting requests while slowly
>>>> accumulating the list of benign characters used by web sites but
>>>> prohibited by some RFC.
>>
>>> The *proper* long term fix is to obey the standards in regard to message
>>> syntax so applications stop using these invalid (when un-encoded)
>>> characters and claiming HTTP/1.1 support.
>>
>> We had "standards vs reality" and "policing traffic" discussions several
>> times in the past, with no signs of convergence towards a single
>> approach, so I am not going to revisit that discussion now. We continue
>> to disagree [while Squid users continue to suffer].
>>
>>
>> Thank you,
>>
>> Alex.
>>
>> _______________________________________________
>> squid-dev mailing list
>> squid-dev at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-dev
>
>
>