From users-return-238-apmail-trafficserver-users-archive=trafficserver.apache.org@trafficserver.apache.org Mon Jul 12 20:06:45 2010 Return-Path: Delivered-To: apmail-trafficserver-users-archive@www.apache.org Received: (qmail 15277 invoked from network); 12 Jul 2010 20:06:44 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 12 Jul 2010 20:06:44 -0000 Received: (qmail 25470 invoked by uid 500); 12 Jul 2010 20:06:44 -0000 Delivered-To: apmail-trafficserver-users-archive@trafficserver.apache.org Received: (qmail 25393 invoked by uid 500); 12 Jul 2010 20:06:44 -0000 Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@trafficserver.apache.org Delivered-To: mailing list users@trafficserver.apache.org Received: (qmail 25385 invoked by uid 99); 12 Jul 2010 20:06:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jul 2010 20:06:44 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [71.6.165.248] (HELO kramer.ogre.com) (71.6.165.248) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jul 2010 20:06:34 +0000 Received: from loki.ogre.com (homey.ogre.com [24.56.189.145]) (authenticated bits=0) by kramer.ogre.com (8.14.3/8.14.3) with ESMTP id o6CK2uIR005503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Jul 2010 13:03:00 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 kramer.ogre.com o6CK2uIR005503 Message-ID: <4C3B74EF.70303@apache.org> Date: Mon, 12 Jul 2010 14:02:55 -0600 From: Leif Hedstrom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: users@trafficserver.apache.org CC: Patrick McManus , Szymon Francuzik Subject: Re: Cache problems References: <4C36E8AA.5050309@cs.put.poznan.pl> <4C370889.6030201@cs.put.poznan.pl> <4C373273.2060801@cs.put.poznan.pl> <4C373433.7030306@apache.org> <4C3B110E.3030008@op.pl> <4C3B2370.1010206@apache.org> <1278958163.2156.534.camel@tng> In-Reply-To: <1278958163.2156.534.camel@tng> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 07/12/2010 12:09 PM, Patrick McManus wrote: > On Mon, 2010-07-12 at 08:15 -0600, Leif Hedstrom wrote: > >> I'd expect Apache to turn a response with no CL: header >> into a TE: chunked response, no? Without either of these headers, what >> type of transfer encoding is Apache returning? >> > presumably it is relying on connection close, which is what you would > expect of a dynamic response to a 1.0 request. Perhaps TS is configured > to send 1.0? > The default is to send HTTP/1.1, but that is a good question. Do you see anything via either the -T tracing option, or tcpdump'ing? The setting for this is CONFIG proxy.config.http.send_http11_requests INT 1 However, the original email showed a response from the Apache HTTPD with an HTTP/1.1 response, without a "Connection: close", right? > > I can certainly see TS not wanting to cache a response without a better > delimiter though - it is impossible to know if there was a server error > or not. > I'm *think* that is the case, but I can't figure out how to get my Apache HTTPD to send responses without a TE: chunked, Content-Length: or Connection:close header. It seems to magically do the "right thing" for the different requests I'm testing. -- Leif