trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <>
Subject Re: Antw: Re: HTTP/1.0 with TS 2.1.3?
Date Fri, 29 Oct 2010 02:58:21 GMT
  On 10/28/2010 06:15 PM, Leif Hedstrom wrote:
>  On 10/28/2010 05:57 PM, Leif Hedstrom wrote:
>> Now, I'm thinking that our defensiveness here might be a little bit 
>> overzealous, so what do you devs say about maybe adding a config 
>> option that tells ATS to trust the Content-Length header? Or perhaps 
>> relax the rules around when we don't trust the CL ?
> I should point out that there is an API that sets the internal flag 
> for "trusting" the response CL header, but I have't tested it:

Also, the code below is the primary "culprit" where do decide not to 
trust the CL header. I'd like to suggest we make that check, at least, 
configurable to turn on or off (probably off by default?). Looking at a 
header from, it has

     Content-Length: 2895802\r\n
     Connection: close\r\n

I have no idea why they do connection close.

-- leif

     // this is the case that the origin server sent       //
     // us content length. Experience says that many       //
     // origin servers that do not support keep-alive      //
     // lie about the content length. to avoid truncation  //
     // of docuemnts from such server, if the server is    //
     // not keep-alive, we set to read until the server    //
     // closes the connection. We sent the maybe bogus     //
     // content length to the browser, and we will correct //
     // the cache if it turnrd out that the servers lied.  //
     if (incoming_response->presence(MIME_PRESENCE_CONTENT_LENGTH)) {
       if (s->current.server->keep_alive == HTTP_NO_KEEPALIVE) {
         printf("2: It is %d, setting to false\n", s->hdr_info.trust_response_cl);
         s->hdr_info.trust_response_cl = false;
         s->hdr_info.response_content_length = HTTP_UNDEFINED_CL;

View raw message