Re: rep_mime_type bugfix

Because :]

With unknown length entities (which includes entities that have server side content process (such as transfer encoding) as well as
dynamically generated entities) we will not be able to test the second part of that logic. So we end up a) testing for no
content-length only, and that is a bad thing in my book; or b) repeating the test after we start recieving body data in client_side
|| buffering past the headers in client side just to test this.

I'm open to suggestions (perhaps a max_response_size acl?)

Rob

----- Original Message -----
From: "Henrik Nordstrom" <hno@hem.passagen.se>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Wednesday, February 14, 2001 8:49 AM
Subject: Re: rep_mime_type bugfix

> Looked OK and is now committed to HEAD.
>
> But why are you looking at the status code instead of for the fact that
> there is no content-type header and no entity?
>
> /Henrik
>
> Robert Collins wrote:
> >
> > Henrik/Duane/Adrian,
> > I found a bug with the rep_mime_type acl check in client_side that I submitted to the list and went into HEAD recently. The
> > attached patch (also available by diffing to the acl_work branch, but I don't guarantee that I won't start on the proper
description
> > I describe in the comments in the patch ) provides a reasonable workaround to the bug. Could one of you please review the patch
and
> > apply to HEAD?
> >
> > I have read the patch, tried to indent (grrr gotta organise indent 1.9.1). build and run-tested on my site.
> >
> > The bug is really more of an unexpected feature: when testing for content-type on reply mime headers, messages with no entitie
will
> > never match a mime type, so restrictive access configurations will not let them though. The bad thing is that 304 responses
(along
> > with 1xx & 204) will never have a content-type header. Therefore they never match and IMS responses to the client always fail.
And
> > at the moment there is no acl for the status line, so we cannot let the user decide...
> >
> > I have a long term solution sketched out based on a status line acl (see the description in the source)... any feedback from the
> > list on that approach?
> >
> > Rob
>
Received on Tue Feb 13 2001 - 15:29:48 MST