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

Kinkie gkinkie at gmail.com
Wed Jun 24 20:24:51 UTC 2015


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.

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



-- 
    Francesco


More information about the squid-dev mailing list