[ 
https://issues.apache.org/jira/browse/TS-4733?focusedWorklogId=26562&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26562
 ]

ASF GitHub Bot logged work on TS-4733:
--------------------------------------

                Author: ASF GitHub Bot
            Created on: 18/Aug/16 02:49
            Start Date: 18/Aug/16 02:49
    Worklog Time Spent: 10m 
      Work Description: Github user zwoop commented on the issue:

    https://github.com/apache/trafficserver/pull/871
  
    Does this replace the previous commits from TS-3828? The last comment is a 
little confusing, in that it sounds this would replace the previous commits?


Issue Time Tracking
-------------------

    Worklog Id:     (was: 26562)
    Time Spent: 20m  (was: 10m)

> Cache writes fail when client requests IMS and server replies 200
> -----------------------------------------------------------------
>
>                 Key: TS-4733
>                 URL: https://issues.apache.org/jira/browse/TS-4733
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 6.2.0
>            Reporter: Shrihari
>             Fix For: 7.0.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> I think this issue happens because of a fix applied in issue TS-3828.
> Imagine a case where the client requests 'IMS' and the cache doesn't have the 
> URL. In that case, we remove the IMS and send the request to origin server. 
> On receiving the response back, we send 304 to client and THEN write to cache.
> However, when we build 304 response to client, we set 
> s->hdr_info.response_content_length = 0.
> Since this call to build_response happens before we setup a tunnel to write 
> the data from 'http_server' to 'cache' we lose this information.
> While setting up this tunnel, we rely on the above field to get the size to 
> write. However, since we have already zeroed it out we don't write anything 
> to the cache.
> I verified that if I use length from the server_response instead of using the 
> pre-computed one, it solves the problem. Though, I am not sure if that should 
> be the solution. I am still looking into the code to see what is the right 
> thing to do.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to