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

[Alex Rousskov]

On 06/24/2015 02:24 PM, Kinkie wrote:
> My 2c: I vote for reality; possibly with a shaming announce message;

I would recommend against shaming any particular company unless somebody
can personally vouch that that specific company is the one to blame. I
cannot (without a lot more triage work which I have no time for).

The benefits of shaming in this case are tiny, but the danger of hurting
an innocent person (or even company) is always there.


> I wouldn't even recommend logging the violation: there is nothing the
> average admin can do about it.


An admin has reminded me privately that Squid already has a mechanism
that can be used here if somebody wants to enforce strict parsing [and
wants to see violations]:


> NAME: relaxed_header_parser
>     In the default "on" setting Squid accepts certain forms
>     of non-compliant HTTP messages where it is unambiguous
>     what the sending application intended

>     If set to "warn" then a warning will be emitted in cache.log
>     each time such HTTP error is encountered.

>     If set to "off" then such HTTP errors will cause the request
>     or response to be rejected.

The temporary fix can be enhanced to include all "unwise" URI characters
if (and only if) relaxed_header_parser is "on", and also to warn about
those characters when relaxed_header_parser is "warn".


HTH,

Alex.



> 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
> 
> 
>